From fujiwara@jprs.co.jp Fri Mar 2 03:21:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119BB21F8BE1 for ; Fri, 2 Mar 2012 03:21:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fShVUyushoo for ; Fri, 2 Mar 2012 03:21:35 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 48ECF21F8BAF for ; Fri, 2 Mar 2012 03:21:27 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id q22BLQaC009282 for ; Fri, 2 Mar 2012 20:21:26 +0900 X-AuditID: ac120820-b7f346d000007d33-84-4f50ad350933 Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 2F.59.32051.53DA05F4; Fri, 2 Mar 2012 20:21:25 +0900 (JST) Date: Fri, 02 Mar 2012 20:21:25 +0900 (JST) Message-Id: <20120302.202125.48495135.fujiwara@jprs.co.jp> To: homenet@ietf.org From: fujiwara@jprs.co.jp In-Reply-To: <7355.1327954105@marajade.sandelman.ca> References: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> <7355.1327954105@marajade.sandelman.ca> X-Mailer: Mew version 6.3.50 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsWyRoiFT9d0bYC/QcdSa4v3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoEr4/S//awFD3krnn06y9jA+I+ri5GTQ0LARKJzagMbhC0mceHe eiCbg0NI4CSjxAVVkDCLgLbE4mXNzCA2r4CVxOtp59hBSkQERCSap4eCmMICKhKX3yiCVLAJ SEps/twKVs0JNPz7qRvsILaQQKbEzY2LWCEW2UmceL6CFaSVV0BQ4u8OYZAws4CWRM+Mx+wQ trzE9rdzmCcw8s1CqJqFpGoWkqoFjMyrGGXy09J0i1PzUopz0w0M9Uoq8/WyCoqK9ZJB9CZG cFBxKOxgnHHK4BCjAAejEg/vn6n+/kKsiWXFlbmHGCU5mJREeVcsD/AX4kvKT6nMSCzOiC8q zUktPsQowcGsJML7QhAox5uSWFmVWpQPk5LmYFES5z1+doefkEB6YklqdmpqQWoRTFaGg0NJ gjdxDVCjYFFqempFWmZOCUKaiYMTZDgP0PBSkBre4oLE3OLMdIj8KUZJKXHeIJCEAEgiozQP rvcVozjQC8K8diBZHmCCgOt6BTSQCWjg4st+IANLEhFSUg2MF/OdZjDmpefF9pd9LV+9YtrC hZY+ximya6u7O69KiBaclv6x8sLhaz5uLzMnO/64GbX4Z1PCwW0ttczZh9/tDc1ivGfifcYk 8/3yUy9LXGMWTUzpX8WUzr7g5AIHl7k/uHf4fPse9n73RMW7HPxmM87OCFksdDptw6ejv55K GF5/UvC7VaTZRImlOCPRUIu5qDgRADSK+6XNAgAA Subject: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 11:21:36 -0000 Hello, I have an idea of home DNS server written in section 3.4.9 of homenet-arch-01. Home gateways (CPE) have a DNS proxy function, and all nodes in the network usually send DNS queries via the DNS proxy. My idea is to add authoritative DNS server function of local zone to home gateways. A home gateway serves one forward local zone and local reverse zones which the home gateway manage/offer by RA or DHCP. The authoritative DNS server function accepts DNS dynamic updates whose owner name is within the forward local zone and whose IP adress is within the IP addresses which the home gateway manages. When An end node starts, It gets IP/IPv6 address and DNS server information, DNS domain name prefix information from the home gateway. (option domain-name-servers and option domain-name in ISC dhcpd) option domain-name can be used to provide the local forward zone name. If the end node wants to register its name into home DNS server, it sends DNS dynamic update to the DNS servers which it got by DHCP. Clients can access the registered hostname using normal DNS lookup via the DNS proxy. There are many points to be cleared. But the idea may work well and it does not require new protocol and rewriting clients. It requires new home gateway (DNS proxy) and new dynamic update program used by home servers. If there are multiple subnets and multiple home gateways, DNS protocol has enough functions (relaying dynamic updates, zone transfers,...). I think the idea works for both IPv4 with NAT and IPv6. Does the idea work for homenet WG? Or already discussed ? If the idea is valuable, I will write a draft and sample DNS server. Regards, -- Kazunori Fujiwara, JPRS From mark@townsley.net Fri Mar 2 22:55:24 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A10F21E803B for ; Fri, 2 Mar 2012 22:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.75 X-Spam-Level: X-Spam-Status: No, score=-6.75 tagged_above=-999 required=5 tests=[AWL=3.849, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 HCj+foIWpnsg for ; Fri, 2 Mar 2012 22:55:23 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 63E8921E8061 for ; Fri, 2 Mar 2012 22:55:23 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwHALW/UU+Q/khL/2dsb2JhbAA5CoMHsTeBB4IWASUCbH1Jh2SZHoEnAY0skSSKCoMpgj9jBJsfjRU X-IronPort-AV: E=Sophos;i="4.73,524,1325462400"; d="scan'208";a="131224922" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2012 06:55:22 +0000 Received: from [10.55.23.163] (ams-townsley-8912.cisco.com [10.55.23.163]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q236tM0t026508 for ; Sat, 3 Mar 2012 06:55:22 GMT Mime-Version: 1.0 (Apple Message framework v753.1) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: homenet@ietf.org From: Mark Townsley Date: Sat, 3 Mar 2012 07:56:33 +0100 X-Mailer: Apple Mail (2.753.1) Subject: [homenet] Getting ready for Paris X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 06:55:24 -0000 Paris is coming soon, and we want to use the time effectively. Ray and I have asked the homearch document design team to identify areas in the homenet architecture document that need discussion time to finish up by end of next week. My personal thoughts are that two of the most important items we need to finish off by the end of this next meeting include boundary detection and what routing protocol we are going to use. Without these, we are going to have a hard time moving forward at all. Post your thoughts on the list, and if you want specific agenda time to talk about these or other pertinent topics, get your requests into us (including your ID reference if you have one, and which of the 5 chartered topic-areas your request most closely aligns with). It's time to dive back in. - Mark From dave.taht@gmail.com Sat Mar 3 10:50:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15AA521F85FD for ; Sat, 3 Mar 2012 10:50:19 -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 pGlcXmbRCy6N for ; Sat, 3 Mar 2012 10:50:18 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF25421F85CF for ; Sat, 3 Mar 2012 10:50:17 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so1703388wgb.13 for ; Sat, 03 Mar 2012 10:50:17 -0800 (PST) Received-SPF: pass (google.com: domain of dave.taht@gmail.com designates 10.216.134.39 as permitted sender) client-ip=10.216.134.39; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dave.taht@gmail.com designates 10.216.134.39 as permitted sender) smtp.mail=dave.taht@gmail.com; dkim=pass header.i=dave.taht@gmail.com Received: from mr.google.com ([10.216.134.39]) by 10.216.134.39 with SMTP id r39mr3557715wei.26.1330800617149 (num_hops = 1); Sat, 03 Mar 2012 10:50:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z8jJpGCgF2iwhIBOOlcsJ6TiTMpG2awVWyySapvSQH8=; b=qlYLnTpxAUgGWBEAUp3pk/LQ9jpbMgncY0LjgbJ4Y6Dvgb0Ph961zXkAak/N1lUOa9 0TIcvpkqzVArroOQYYX6uZvzGTfxFVb5G3RFfXG0x6mXhxKbv6qj1XicfJwFB9sAqJf+ 0lzlOps73BmQmgGfaQYxJ1KlrIEZajSAfTsw4lhmrQwm+H599tErVpYAPHtFycLnVMSI Dqj7JkxleJ9jx1KLQsWm1fjIl+BTjktUreOtuges7Rp4x3Qk+Zk4/O2NwU2wzi2RBUKW zho/KhLluVdv73MztMyb6EoODlOCsFJfgCWSX8k9CXRU5d9y5YTFAv7csH4eRf6p9X7q cmcw== MIME-Version: 1.0 Received: by 10.216.134.39 with SMTP id r39mr2862147wei.26.1330800616648; Sat, 03 Mar 2012 10:50:16 -0800 (PST) Received: by 10.223.151.8 with HTTP; Sat, 3 Mar 2012 10:50:16 -0800 (PST) In-Reply-To: References: Date: Sat, 3 Mar 2012 10:50:16 -0800 Message-ID: From: Dave Taht To: Mark Townsley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: Re: [homenet] Getting ready for Paris X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 18:50:19 -0000 On Fri, Mar 2, 2012 at 10:56 PM, Mark Townsley wrote: > > Paris is coming soon, and we want to use the time effectively. Ray and I > have asked the homearch document design team to identify areas in the > homenet architecture document that need discussion time to finish up by e= nd > of next week. My personal thoughts are that two of the most important ite= ms > we need to finish off by the end of this next meeting include boundary > detection and what routing protocol we are going to use. Without these, w= e > are going to have a hard time moving forward at all. > > Post your thoughts on the list, and if you want specific agenda time to t= alk > about these or other pertinent topics, get your requests into us (includi= ng > your ID reference if you have one, and which of the 5 chartered topic-are= as > your request most closely aligns with). I've been working on 'running code' and not on 'consensus' all that much. I'm mostly focused on fixing bufferbloat and basic ipv6 stuff and am tracking the linux 3.3 effort (which has vastly improved AQM support) closely within the context of the cerowrt project. Builds for that are presently available here: http://huchra.bufferbloat.net/~cero1/3.3/ I'm happy to report that the babel protocol has landed in the quagga-RE tre= e giving two mostly interoperable implementations (the original and quagga itself), as well as some rdnss support has been added, potentially obsoleting radvd. Being able to use quagga on home gateways rather than other daemons finally opens up the possibility of even trying the oft-proposed-here Xospf alternative, = once I figure out the proper firewall rules. And in other news dibbler 0.8.2 has more or less working dhcpv6-PD support in it, although some problems remain. > > It's time to dive back in. > > - Mark > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net From brian.e.carpenter@gmail.com Sat Mar 3 13:15:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69121F8722 for ; Sat, 3 Mar 2012 13:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.491 X-Spam-Level: X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 dzbaJqNY+zRc for ; Sat, 3 Mar 2012 13:15:17 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E26B21F871C for ; Sat, 3 Mar 2012 13:15:17 -0800 (PST) Received: by eaaq11 with SMTP id q11so947735eaa.31 for ; Sat, 03 Mar 2012 13:15:16 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.25.65 as permitted sender) client-ip=10.213.25.65; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.25.65 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.213.25.65]) by 10.213.25.65 with SMTP id y1mr2016124ebb.132.1330809316759 (num_hops = 1); Sat, 03 Mar 2012 13:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=deHXqidyy5+vKTTXm82W3z8bGz9t/ZgYyxsIIfZODhM=; b=Aq53rDBxKpItU7Kg61tE02ZCQyRtkp5apdQb1R3TC3qdCHWS3aHkxNvqG5gEbIbwse NS15Fof25zAAKVqk/g2IO95wcPIGB+5DfZvq+Njht1+NcfAc/cC7DsI7AlA9OSolQppH 83nDBQWJl81vscf78IB/39ADusPbMUPPHGQ4904QX9OWWMxrJ3HgOR6V2/LfBVEgO0LB JAz1O2p2q3AY/0vC3tK0asd5GMPVG6B/s5ycw7kk2+eOaCOIV0oLTTdKIhIRTms1XvlE nrmyw0dCUJkisvKAfDx2DzFM85HIGkWRp9OWgL7Zz2TN9+iagX28a2Fa2JYNB3yAiqtL s1pw== Received: by 10.213.25.65 with SMTP id y1mr1536161ebb.132.1330809316635; Sat, 03 Mar 2012 13:15:16 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id o49sm38974325eeb.7.2012.03.03.13.15.13 (version=SSLv3 cipher=OTHER); Sat, 03 Mar 2012 13:15:15 -0800 (PST) Message-ID: <4F5289DC.3030101@gmail.com> Date: Sun, 04 Mar 2012 10:15:08 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Mark Townsley References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Getting ready for Paris X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 21:15:18 -0000 On 2012-03-03 19:56, Mark Townsley wrote: > > Paris is coming soon, and we want to use the time effectively. Ray and I > have asked the homearch document design team to identify areas in the > homenet architecture document that need discussion time to finish up by > end of next week. I noticed that there is no section discussing operations and management as a topic on its own. It seems to me that this is needed, even if what it says is that the architecture must ensure that manual operations and management are either not needed at all, or are absolutely minimal, or are remotely accessible to specialists. A couple of days ago I had no IP connectivity at home. The conversation with the ISP help desk responder included her asking me which model of D-Link I have, and talking me through its menus. Of course I'd done all that before I called, but it struck me as ridiculous that any help desk would ask a domestic customer to do that. It will only be worse for real homenets. Brian > My personal thoughts are that two of the most > important items we need to finish off by the end of this next meeting > include boundary detection and what routing protocol we are going to > use. Without these, we are going to have a hard time moving forward at all. > > Post your thoughts on the list, and if you want specific agenda time to > talk about these or other pertinent topics, get your requests into us > (including your ID reference if you have one, and which of the 5 > chartered topic-areas your request most closely aligns with). > > It's time to dive back in. > > - Mark > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From sm@resistor.net Sat Mar 3 20:28:25 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79DA21F8453 for ; Sat, 3 Mar 2012 20:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.645 X-Spam-Level: X-Spam-Status: No, score=-102.645 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Z6C46B8NH1r1 for ; Sat, 3 Mar 2012 20:28:23 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F25E21F8450 for ; Sat, 3 Mar 2012 20:28:23 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q244SFnQ004030; Sat, 3 Mar 2012 20:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330835300; i=@resistor.net; bh=WYnrLQGUaNKdPP8Rxm1Nqz8ju2aM2CpZ5+f+TnQgHyk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=qqMniJh8EGGKUdb48nBGSBnkmOIwHlhWaRLm44hsPPKE4EY4EU574Lc8ZUf4aDGtF LTVs7NhR4yBIq1fMTptxv+lV8F2TrS3c2X1KtDC7H4YiwSMtERZAFyujzKRkfSOiUH ewgQlGJZaShPhi6Q//8viyNj8nXjLiSZrZaikGCk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1330835300; i=@resistor.net; bh=WYnrLQGUaNKdPP8Rxm1Nqz8ju2aM2CpZ5+f+TnQgHyk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=vUgttfm/2db37XOVUuY+oILbolPjw3av5wQNaeE/sAN2GQ27MmlHQYB088T17zGeA PIGSvivRlEMgSq+PMJ+MeEpH6TsZvOyez4AxpO2DwgqAp7w/Il5Y3MIxJA9QD6AKjg uYE0p6w71RD8bNkX6Wveh1cXFTbB7zb8pbGHE6uc= Message-Id: <6.2.5.6.2.20120303195751.065ddc38@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 03 Mar 2012 20:15:09 -0800 To: Brian E Carpenter From: SM In-Reply-To: <4F5289DC.3030101@gmail.com> References: <4F5289DC.3030101@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: homenet@ietf.org Subject: Re: [homenet] Getting ready for Paris (off-topic) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 04:28:25 -0000 Hi Brian, At 13:15 03-03-2012, Brian E Carpenter wrote: >A couple of days ago I had no IP connectivity at home. The conversation >with the ISP help desk responder included her asking me which model >of D-Link I have, and talking me through its menus. Of course I'd >done all that before I called, but it struck me as ridiculous that >any help desk would ask a domestic customer to do that. It will only >be worse for real homenets. The alternative is for the help desk to say that the D-Link faulty. The residential customer might be advised to get an ISP-approved device. "The customer may of course also choose to move to a new ISP". :-) I'll +1 a discussion about operations and management. Regards, -sm From ietfdbh@comcast.net Sat Mar 3 20:58:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5521121F85B8 for ; Sat, 3 Mar 2012 20:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.252 X-Spam-Level: X-Spam-Status: No, score=-102.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 bs7hlIsD999C for ; Sat, 3 Mar 2012 20:58:07 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id AB33A21F85AD for ; Sat, 3 Mar 2012 20:58:07 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta09.westchester.pa.mail.comcast.net with comcast id hGy81i0011YDfWL59Gy8uz; Sun, 04 Mar 2012 04:58:08 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta20.westchester.pa.mail.comcast.net with comcast id hGy71i00N3Ecudz3gGy7MT; Sun, 04 Mar 2012 04:58:08 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 03 Mar 2012 23:58:04 -0500 From: David Harrington To: SM , Brian E Carpenter Message-ID: Thread-Topic: [homenet] Getting ready for Paris (off-topic) In-Reply-To: <6.2.5.6.2.20120303195751.065ddc38@resistor.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Getting ready for Paris (off-topic) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 04:58:08 -0000 +1 -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/3/12 11:15 PM, "SM" wrote: >Hi Brian, >At 13:15 03-03-2012, Brian E Carpenter wrote: >>A couple of days ago I had no IP connectivity at home. The conversation >>with the ISP help desk responder included her asking me which model >>of D-Link I have, and talking me through its menus. Of course I'd >>done all that before I called, but it struck me as ridiculous that >>any help desk would ask a domestic customer to do that. It will only >>be worse for real homenets. > >The alternative is for the help desk to say that the D-Link >faulty. The residential customer might be advised to get an >ISP-approved device. "The customer may of course also choose to move >to a new ISP". :-) > >I'll +1 a discussion about operations and management. > >Regards, >-sm > > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From victor.kuarsingh@gmail.com Sun Mar 4 11:41:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E74321F8600 for ; Sun, 4 Mar 2012 11:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.262 X-Spam-Level: X-Spam-Status: No, score=-3.262 tagged_above=-999 required=5 tests=[AWL=0.337, 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 TqkTClsCOkQG for ; Sun, 4 Mar 2012 11:41:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99BCC21F85EE for ; Sun, 4 Mar 2012 11:41:26 -0800 (PST) Received: by iazz13 with SMTP id z13so5424195iaz.31 for ; Sun, 04 Mar 2012 11:41:26 -0800 (PST) Received-SPF: pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.50.212.40 as permitted sender) client-ip=10.50.212.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.50.212.40 as permitted sender) smtp.mail=victor.kuarsingh@gmail.com; dkim=pass header.i=victor.kuarsingh@gmail.com Received: from mr.google.com ([10.50.212.40]) by 10.50.212.40 with SMTP id nh8mr4581516igc.39.1330890086368 (num_hops = 1); Sun, 04 Mar 2012 11:41:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=zWL3QDUMqUK+ExDHF8jN85NYnAOpMGeFBb8gpV9wkcs=; b=u4mkhD5ltpM+IMEp5wkT5V1iY3mnjdlBasVzGyswQmatISkDbZheNHcahniaokCRNl hQDVp92cW6K2GrGQrVYZoc9dW7eUDBXACZKVwngKJ072Q+4bC2fW+chFJeeh6t0siYWa i/BCOutCU7d0z5V2Nc39TssDIiQdv09PqfLJSS+mn4A100ZCijWJA9Sjfbq+o1700Ms5 Zuynj8DpoBfJY7D6oJpO7JPvuPzcLFpr014d8DpYyqR36ASbSfNKXfaqb3KLLwXqmdFc W/Mzet4SxU1KX0fjQTdkXfUW0oZQheBIYAmZTnmPAE66PaUxVvTNOISBwUO0/eR5bnVl 3PNw== Received: by 10.50.212.40 with SMTP id nh8mr3819400igc.39.1330890086329; Sun, 04 Mar 2012 11:41:26 -0800 (PST) Received: from [192.168.100.89] ([67.224.83.162]) by mx.google.com with ESMTPS id cu4sm9080100igc.15.2012.03.04.11.41.23 (version=SSLv3 cipher=OTHER); Sun, 04 Mar 2012 11:41:25 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 04 Mar 2012 14:41:20 -0500 From: Victor Kuarsingh To: Brian E Carpenter , Mark Townsley Message-ID: Thread-Topic: [homenet] Getting ready for Paris In-Reply-To: <4F5289DC.3030101@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Getting ready for Paris X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 19:41:27 -0000 On 12-03-03 4:15 PM, "Brian E Carpenter" wrote: > >I noticed that there is no section discussing operations and management >as a topic on its own. It seems to me that this is needed, even if what >it says is that the architecture must ensure that manual operations and >management are either not needed at all, or are absolutely minimal, >or are remotely accessible to specialists. I would fully agree with Brian's comments here. This is topic often left out but is important for real network deployments. > >A couple of days ago I had no IP connectivity at home. The conversation >with the ISP help desk responder included her asking me which model >of D-Link I have, and talking me through its menus. Of course I'd >done all that before I called, but it struck me as ridiculous that >any help desk would ask a domestic customer to do that. It will only >be worse for real homenets. This is a real issue today and mechanisms to deal with this in a more effective matter is important. Having CS reps walk people through config menus/pages is problematic (since reps will not be able to learn and/or keep with all the device variants). Brian's comments do exemplify an issue which will become extremely problematic in the future when Home Net complexity increases. Just adding in IPv6 (to IPv4) connectivity to this mix has highlighted challenges in traditional troubleshooting methods. Part of this was due to the added complexity of IPv6 (since few customers/support reps had experience in this area) and the other was that troubleshooting tools for IPv6 were not as readily availble. My comment was not to focus on IPv6 specifically- but that of new functionality. I think a discussion (at minimum) would be warranted here to see what opportunities we have to address this (soon to be) issue. Regards, Victor K > > Brian > From shemant@cisco.com Sun Mar 4 16:27:48 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B08321F8657 for ; Sun, 4 Mar 2012 16:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.195 X-Spam-Level: X-Spam-Status: No, score=-9.195 tagged_above=-999 required=5 tests=[AWL=1.404, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 fNXhj53AybvD for ; Sun, 4 Mar 2012 16:27:47 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 55E2E21F8655 for ; Sun, 4 Mar 2012 16:27:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=795; q=dns/txt; s=iport; t=1330907267; x=1332116867; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RvnUzvhAII4BGmzaadxgrF2kHuioejmuZ8XPoeH01R4=; b=NHTVR51yn2nRIhTcUXNT2UDTUbSkcIN/z15P5iUn9vZ9M7kspNyQVv3E /RLLNtoBgCG8XiEX1rB99Bat1XquhSH8FiJaFBpYSEcWK25ruGDXK/PAN 6wJMXPln90hbJbPP8S+xRH5pM9vYqYe+OJbLqEs+E8lDYYCceEW5AuddI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACEIVE+tJV2Z/2dsb2JhbABDtEGBB4F9AQEBBBIBHQo/DAQCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodlmX4BjSyQUI96YwSIUJ0AgwI X-IronPort-AV: E=Sophos;i="4.73,531,1325462400"; d="scan'208";a="63688227" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 05 Mar 2012 00:27:47 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q250RkYg023274; Mon, 5 Mar 2012 00:27:46 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 4 Mar 2012 18:27:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Mar 2012 18:27:45 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3041C015B@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] Getting ready for Paris Thread-Index: Acz6PsxwflhC/ygCTIGKdpnNsbtVkgAJ6LCw References: <4F5289DC.3030101@gmail.com> From: "Hemant Singh (shemant)" To: "Victor Kuarsingh" , "Brian E Carpenter" , "Mark Townsley" X-OriginalArrivalTime: 05 Mar 2012 00:27:46.0828 (UTC) FILETIME=[C9ED44C0:01CCFA66] Cc: homenet@ietf.org Subject: Re: [homenet] Getting ready for Paris X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 00:27:48 -0000 -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf Of Victor Kuarsingh Sent: Sunday, March 04, 2012 2:41 PM To: Brian E Carpenter; Mark Townsley Cc: homenet@ietf.org Subject: Re: [homenet] Getting ready for Paris >I would fully agree with Brian's comments here. This is topic often left >out but is important for real network deployments. Agreed. However, note management interfaces already exist for a CPE router in a standard such as the DSL TR-064 exists. Thus the arch folks should check with such standards bodies and see what is missing and work jointly to create a uniform management interface for the CPE router. For now, the arch document may reference some already existing documents. Regards, Hemant From Ray.Bellis@nominet.org.uk Mon Mar 5 01:25:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1609921F8703 for ; Mon, 5 Mar 2012 01:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.081 X-Spam-Level: X-Spam-Status: No, score=-10.081 tagged_above=-999 required=5 tests=[AWL=0.518, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 1-Znkw91Lfq1 for ; Mon, 5 Mar 2012 01:25:33 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id CE2C521F86EA for ; Mon, 5 Mar 2012 01:25:32 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=I4wgzFDNuHgacx1KY1/b08t0T5DH0LDg8dW54Sr6vYyiywWAsPfw9bF/ tRr6OQfYk0Z35U362hxAc7KXi4laEAam/zXD49VOPGUZMOZTd/jkCEW7w SVCwGvD5FW9rQBW; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1330939533; x=1362475533; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Home=20DNS=20server=20for =20homenet|Date:=20Mon,=205=20Mar=202012=2009:25:30=20+00 00|Message-ID:=20<000118C4-3ABA-47D0-BDF6-69E59EF1C630@no minet.org.uk>|To:=20"=20=20"=20|CC:=20""=20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20<20120302.202125.48495135.fujiwara@jprs.c o.jp>|References:=20<20120130163845.2110.6281.idtracker@i etfa.amsl.com>=0D=0A=20<7355.1327954105@marajade.sandelma n.ca>=0D=0A=20<20120302.202125.48495135.fujiwara@jprs.co. jp>; bh=CI2V7EAj1og3JqPXJWYKx+vpLWUPt28IAYKqqjVf+t0=; b=DU+N0vj5VJcLbffKfIf+xoS0mgGCs8+Ay+KZWnmR6in9K7pXwju5Rmsk vxmCtG24AYcA3w9+P1cXK/ipza+UfIrcqWHGxo335C7tGcEHxr3rgEdTz EOfM8yCsTEqQgrb; X-IronPort-AV: E=Sophos;i="4.73,533,1325462400"; d="scan'208";a="38634252" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 05 Mar 2012 09:25:31 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 5 Mar 2012 09:25:31 +0000 From: Ray Bellis To: " " Thread-Topic: [homenet] Home DNS server for homenet Thread-Index: AQHM+Gal82vqoPkQnEWjjIoakiagD5ZbcwMA Date: Mon, 5 Mar 2012 09:25:30 +0000 Message-ID: <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> References: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> In-Reply-To: <20120302.202125.48495135.fujiwara@jprs.co.jp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 09:25:38 -0000 On 2 Mar 2012, at 11:21, wrote: > I think the idea works for both IPv4 with NAT and IPv6. >=20 > Does the idea work for homenet WG? > Or already discussed ? >=20 > If the idea is valuable, I will write a draft and sample DNS server. Fujiwara-san Thanks for your note. The idea of running a local authoritative zone along= side a forwarding proxy or full recursive server has been seen already, for= example in the "dnsmasq" software used by many CPE vendors. It is also listed as requirement LAN.DNS.6 in the Broadband Forum's TR-124 = Issue 2. As such a draft describing this is probably unnecessary. Your DNS expertise would of course be much appreciated as we start to tackl= e the wider issues around naming in the Homenet, specifically: 1. naming updates and queries between subnets 2. integration (or otherwise) of unicast DNS and mDNS 3. DNSSEC validation kind regards, Ray From simon@thekelleys.org.uk Mon Mar 5 02:08:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5344D21F85D4 for ; Mon, 5 Mar 2012 02:08:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Syc+LRuhydIb for ; Mon, 5 Mar 2012 02:08:15 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id AC84021F85B5 for ; Mon, 5 Mar 2012 02:08:15 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:43279 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1S4Upy-0005sE-BT for homenet@ietf.org; Mon, 05 Mar 2012 10:08:14 +0000 Received: from guest-193-062-204-103.wtgc.org ([193.62.204.103]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1S4Upx-0004tu-RY for homenet@ietf.org; Mon, 05 Mar 2012 10:08:13 +0000 Message-ID: <4F549088.1060507@thekelleys.org.uk> Date: Mon, 05 Mar 2012 10:08:08 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: homenet@ietf.org References: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> In-Reply-To: <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 10:08:16 -0000 On 05/03/12 09:25, Ray Bellis wrote: > The idea of running a local authoritative zone alongside a forwarding > proxy or full recursive server has been seen already, for example in > the "dnsmasq" software used by many CPE vendors. I'm the principle author of dnsmasq, and on this list to try and make dnsmasq better in the Brave New World. I'm happy to get any suggestions on developments to dnsmasq that would further the Homenet remit, either on or off list. In the meantime I'll point out that the next release of dnsmasq, which features DHCPv6 and Router Advertisement support, is imminent. Cheers, Simon. From gettysjim@gmail.com Mon Mar 5 06:02:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0308A21F8551 for ; Mon, 5 Mar 2012 06:02:21 -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 U7kskFLYG6hP for ; Mon, 5 Mar 2012 06:02:20 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E24421F8539 for ; Mon, 5 Mar 2012 06:02:20 -0800 (PST) Received: by vbbez10 with SMTP id ez10so3897537vbb.31 for ; Mon, 05 Mar 2012 06:02:19 -0800 (PST) Received-SPF: pass (google.com: domain of gettysjim@gmail.com designates 10.52.36.242 as permitted sender) client-ip=10.52.36.242; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gettysjim@gmail.com designates 10.52.36.242 as permitted sender) smtp.mail=gettysjim@gmail.com; dkim=pass header.i=gettysjim@gmail.com Received: from mr.google.com ([10.52.36.242]) by 10.52.36.242 with SMTP id t18mr34578840vdj.7.1330956139807 (num_hops = 1); Mon, 05 Mar 2012 06:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6ME4Ab4TfTRIeK0Ki9JkgQHllGkMdIbGGzoOcLcgXfo=; b=k5jZi5jFpZ7WxAg44EzBKn067LWRkDhtB656+RA4vUu76v5h8vt+J9o/g9iU5PKhYq 70bCaIDb+PiHdK9pwyTOHIIqGB3zx/DhDumeVnxLw9Smn53pvJ4BCevirG1o5PniU6En ZM2p0oH0bdED+rmEaB3ABindYcs09wSjKi8k6rWkiRlKj3Mrbv72I255Cl8MIn7nd4lR V7/z+ssLriZdOuFI8vFWGS2S5SfWJqH2CakksbK0A6rxoqGRDF27YP0Vg9zF+V4m62of g/FWdLxjqs7uwMCRjkEqkhIHtqF3730ai85XbOZI8GylXlZyGEIN9fafMrvts3xpqExs qeAQ== Received: by 10.52.36.242 with SMTP id t18mr29645819vdj.7.1330956139708; Mon, 05 Mar 2012 06:02:19 -0800 (PST) Received: from [192.168.1.25] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id fd10sm25133605vdc.1.2012.03.05.06.02.18 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 06:02:18 -0800 (PST) Sender: Jim Gettys Message-ID: <4F54C768.5050300@freedesktop.org> Date: Mon, 05 Mar 2012 09:02:16 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: fujiwara@jprs.co.jp References: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> In-Reply-To: <20120302.202125.48495135.fujiwara@jprs.co.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:02:21 -0000 On 03/02/2012 06:21 AM, fujiwara@jprs.co.jp wrote: > Hello, > > I have an idea of home DNS server written in section 3.4.9 of > homenet-arch-01. > > Home gateways (CPE) have a DNS proxy function, > and all nodes in the network usually send DNS queries via the DNS proxy. > > My idea is to add authoritative DNS server function of local zone to > home gateways. > > A home gateway serves one forward local zone and local reverse zones > which the home gateway manage/offer by RA or DHCP. > > The authoritative DNS server function accepts DNS dynamic updates > whose owner name is within the forward local zone and whose IP adress > is within the IP addresses which the home gateway manages. > > When An end node starts, It gets IP/IPv6 address and DNS server > information, DNS domain name prefix information from the home gateway. > (option domain-name-servers and option domain-name in ISC dhcpd) > option domain-name can be used to provide the local forward zone name. > > If the end node wants to register its name into home DNS server, > it sends DNS dynamic update to the DNS servers which it got by DHCP. > > Clients can access the registered hostname using normal DNS lookup via > the DNS proxy. > > There are many points to be cleared. But the idea may work well and > it does not require new protocol and rewriting clients. > > It requires new home gateway (DNS proxy) and new dynamic update > program used by home servers. > > If there are multiple subnets and multiple home gateways, > DNS protocol has enough functions > (relaying dynamic updates, zone transfers,...). > > I think the idea works for both IPv4 with NAT and IPv6. > > Does the idea work for homenet WG? > Or already discussed ? > > If the idea is valuable, I will write a draft and sample DNS server. > > Note that CeroWrt (a derivative of OpenWrt in which we are doing our bufferbloat work) has a full Bind 9.9 implementation you can experiment with today, and that this has been our intent from the beginning, both to simplify naming for users, and to get a DNSSEC implementation. A dnsmasq implementation would be welcome, for a couple reasons: competition is good, and it would likely be a lot smaller than ISC Bind is. But code that exists and runs trumps code not yet ready for primetime.... We'd love to have some help to flesh this out properly; it needs scripting support to get fully implemented the way we've envisioned it. We don't currently use ISC DHCP, as it's currently (due to an implementation crock being worked on) too big; there is a dibbler implementation being shaken down. See http://www.bufferbloat.net/projects/cerowrt - Jim From simon.perreault@viagenie.ca Mon Mar 5 07:10:09 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D840121F8781 for ; Mon, 5 Mar 2012 07:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 5j1AXQ4ThB7e for ; Mon, 5 Mar 2012 07:10:09 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 682A021F8593 for ; Mon, 5 Mar 2012 07:10:09 -0800 (PST) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:8c46:de1b:764:c20]) by jazz.viagenie.ca (Postfix) with ESMTPSA id DF46720E7B for ; Mon, 5 Mar 2012 10:10:08 -0500 (EST) Message-ID: <4F54D750.6000203@viagenie.ca> Date: Mon, 05 Mar 2012 10:10:08 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> In-Reply-To: <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:10:10 -0000 On 2012-03-05 04:25, Ray Bellis wrote: > Thanks for your note. The idea of running a local authoritative zone alongside a forwarding proxy or full recursive server has been seen already, for example in the "dnsmasq" software used by many CPE vendors. > > It is also listed as requirement LAN.DNS.6 in the Broadband Forum's TR-124 Issue 2. As such a draft describing this is probably unnecessary. If I understand the original post correctly, it goes much further than just saying "home router MUST have an authoritative server". It specifies a new usage pattern of that server on the home net. That could mean new draft in this WG, wouldn't it? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From fujiwara@wide.ad.jp Mon Mar 5 07:15:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488F521F8792 for ; Mon, 5 Mar 2012 07:15:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcWnArzVsojM for ; Mon, 5 Mar 2012 07:15:39 -0800 (PST) Received: from sh.wide.ad.jp (sh.wide.ad.jp [IPv6:2001:200:0:1001::6]) by ietfa.amsl.com (Postfix) with ESMTP id E77ED21F878A for ; Mon, 5 Mar 2012 07:15:37 -0800 (PST) Received: from localhost (i114-186-100-136.s41.a013.ap.plala.or.jp [114.186.100.136]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.20) with ESMTP id q25FFXf9001794; Tue, 6 Mar 2012 00:15:35 +0900 (JST) Date: Tue, 06 Mar 2012 00:15:33 +0900 (JST) Message-Id: <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> To: Ray.Bellis@nominet.org.uk From: Kazunori Fujiwara In-Reply-To: <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, fujiwara@jprs.co.jp Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:15:40 -0000 Ray-san, Thanks for your comments. > From: Ray Bellis > Thanks for your note. The idea of running a local authoritative zone alongside a forwarding proxy or full recursive server has been seen already, for example in the "dnsmasq" software used by many CPE vendors. I see. DHCP has enough function. RFC 2132 defines DHCP client host name option, and RFC 4702 Section 3.2. "Client Desires to Update A RRs" defines the option to DNS RR. # I'm not aware that DHCPv6 has the same option. Using DHC client host name option is easier than implementing DNS Update client in each client. "dnsmasq" seems to have enough function (except multiple subnets, multiple upstreams). Or a combintion of isc-dhcpd and BIND 9 may achieve all of DNS related works. > It is also listed as requirement LAN.DNS.6 in the Broadband Forum's TR-124 Issue 2. As such a draft describing this is probably unnecessary. > > Your DNS expertise would of course be much appreciated as we start to tackle the wider issues around naming in the Homenet, specifically: > > 1. naming updates and queries between subnets One upstream, and multiple subnets case, it may be solved by using one DHCP server and multiple DHCP relay agents. Multiple upstream case, manual configuration is necessary. An end user setup one DNS server which serves local zone and multiple reverse zones. DHCP servers send updates to the DNS server. > 2. integration (or otherwise) of unicast DNS and mDNS It is same as now. Using different TLDs solves the problem. > 3. DNSSEC validation DNS proxy can forward global queries to DNSSEC validators. Local zones does not require DNSSEC validation, I think. I thought to write I-D, but now, DHCP has enough capability, I will consider the issure more. Regards, -- Kazunori Fujiwara, JPRS From Ray.Bellis@nominet.org.uk Mon Mar 5 07:20:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E0121F8690 for ; Mon, 5 Mar 2012 07:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.116 X-Spam-Level: X-Spam-Status: No, score=-10.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 wViKzMYoLI5Y for ; Mon, 5 Mar 2012 07:20:58 -0800 (PST) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4F03721F867F for ; Mon, 5 Mar 2012 07:20:58 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=zGMg5M2zRjIggfKGpmeCMbzrVvZYprT1WC9FfnseB3uEQ34gl2AvfmaD o9qyjAVp1G9w0n+mMg3gP7G/04y34oCPrJGSk67w2eyQmi6mkVOzFu34v bvhgbAJwC56g4ZJ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1330960858; x=1362496858; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Home=20DNS=20server=20for =20homenet|Date:=20Mon,=205=20Mar=202012=2015:20:55=20+00 00|Message-ID:=20<704D1B3F-9480-4554-8DAF-C25D84616BC9@no minet.org.uk>|To:=20Simon=20Perreault=20|CC:=20""=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quot ed-printable|Content-ID:=20<33dfc72a-310a-47f3-9c29-8774a cd74f3a>|In-Reply-To:=20<4F54D750.6000203@viagenie.ca> |References:=20<20120130163845.2110.6281.idtracker@ietfa. amsl.com>=0D=0A=20<7355.1327954105@marajade.sandelman.ca> =0D=0A=20<20120302.202125.48495135.fujiwara@jprs.co.jp> =0D=0A=20<000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.or g.uk>=0D=0A=20<4F54D750.6000203@viagenie.ca>; bh=LbHxRtTcKzqNeucRPfWr6RfpdKOd3tpdMmBCcKzQfVM=; b=u0apanRvMmZbZ1ft7p7NKoy+KXew8GT48iR/9V/PnlA/Kd8yc3Az4zlU cjkecb6ZCGvKAbZRBpsIrZ6L38KBsEiLtkbjKjglkU8LrC+yvgjjAFPaX rZXbAfmUuUOTMRY; X-IronPort-AV: E=Sophos;i="4.73,534,1325462400"; d="scan'208";a="38650465" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 05 Mar 2012 15:20:57 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 5 Mar 2012 15:20:56 +0000 From: Ray Bellis To: Simon Perreault Thread-Topic: [homenet] Home DNS server for homenet Thread-Index: AQHM+Gal82vqoPkQnEWjjIoakiagD5ZbcwMAgABgSgCAAAMDgA== Date: Mon, 5 Mar 2012 15:20:55 +0000 Message-ID: <704D1B3F-9480-4554-8DAF-C25D84616BC9@nominet.org.uk> References: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <4F54D750.6000203@viagenie.ca> In-Reply-To: <4F54D750.6000203@viagenie.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <33dfc72a-310a-47f3-9c29-8774acd74f3a> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:20:59 -0000 On 5 Mar 2012, at 15:10, Simon Perreault wrote: > That could mean new draft in this WG, wouldn't it? It _might_, but IMHO not until we've addressed those "bigger picture" issue= s I mentioned. In practise, all such CPE servers that I know of that implement the TR-124 = requirement do it using the same usage pattern as Fujiwara-san described. Ray From Ray.Bellis@nominet.org.uk Mon Mar 5 07:33:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC1221F8794 for ; Mon, 5 Mar 2012 07:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.146 X-Spam-Level: X-Spam-Status: No, score=-10.146 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 OXa88jmnkuFb for ; Mon, 5 Mar 2012 07:33:54 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id CC24521F878B for ; Mon, 5 Mar 2012 07:33:53 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=LUD4ZBkXQ9J4fYSFpCre5i6WmiuPFJ8m0RTmCp8GnmK0+G/ckwf1A2xc QyKevPzMVQwmhXmC68og+3RIrHRpUdxaTf8KQI1FR90P2q+eKzWOHyDk6 Gd/tviVkKbK1YRJ; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1330961634; x=1362497634; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Home=20DNS=20server=20for =20homenet|Date:=20Mon,=205=20Mar=202012=2015:33:51=20+00 00|Message-ID:=20<5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@no minet.org.uk>|To:=20Kazunori=20Fujiwara=20|CC:=20"homenet@ietf.org=20Group"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quot ed-printable|Content-ID:=20<65dfc696-83d9-47ef-bf8c-19238 a1493b5>|In-Reply-To:=20<20120306.001533.6530265257073483 79.fujiwara@wide.ad.jp>|References:=20<7355.1327954105@ma rajade.sandelman.ca>=0D=0A=20<20120302.202125.48495135.fu jiwara@jprs.co.jp>=0D=0A=20<000118C4-3ABA-47D0-BDF6-69E59 EF1C630@nominet.org.uk>=0D=0A=20<20120306.001533.65302652 5707348379.fujiwara@wide.ad.jp>; bh=M7I3r5TiZbv8JJL9WqEqsXn6alLINI6ogiC9q0VBO4o=; b=xRuc7i8v2chESvRdIumK7MyqCY4hweBWm6BbWis+02wzBzHmKX+9nm7O /qF8BPDa5Tx7yXmHS40iltAEq8RKKfsw1+4NTKr4FOP7neT5lX6kETB90 EGUpvpIcXsYV5Vo; X-IronPort-AV: E=Sophos;i="4.73,534,1325462400"; d="scan'208";a="31536868" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 05 Mar 2012 15:33:52 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 5 Mar 2012 15:33:52 +0000 From: Ray Bellis To: Kazunori Fujiwara Thread-Topic: [homenet] Home DNS server for homenet Thread-Index: AQHM+Gal82vqoPkQnEWjjIoakiagD5ZbcwMAgABhzYCAAAUdgA== Date: Mon, 5 Mar 2012 15:33:51 +0000 Message-ID: <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> In-Reply-To: <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <65dfc696-83d9-47ef-bf8c-19238a1493b5> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:33:55 -0000 On 5 Mar 2012, at 15:15, Kazunori Fujiwara wrote: > RI see. DHCP has enough function. RFC 2132 defines DHCP client host > name option, and RFC 4702 Section 3.2. "Client Desires to Update A > RRs" defines the option to DNS RR. >=20 > # I'm not aware that DHCPv6 has the same option. Me neither, although whether DHCPv6 actually gets used within the Homenet (= as opposed to standard Neighbor Discovery) remains to be seen. > Using DHC client host name option is easier than implementing DNS > Update client in each client. Agreed, and it removes the need for the TSIG key management normally requir= ed for DNS Dynamic Updates. >> 1. naming updates and queries between subnets >=20 > One upstream, and multiple subnets case, it may be solved by using one > DHCP server and multiple DHCP relay agents. I was more thinking about mDNS - there's no standardised mechanism (althoug= h drafts are forthcoming) for using "link-local mDNS" in multiple segments. The options would appear to be either a multicast relay agent running on in= ternal CPE, or an enhancement to mDNS to support "site-local" multicast. > Multiple upstream case, manual configuration is necessary. An end > user setup one DNS server which serves local zone and multiple > reverse zones. DHCP servers send updates to the DNS server. The unicast case is likely simpler, but we also need to beware the case whe= re the entire Homenet stops working because of the failure of a single "sup= er node". >> 2. integration (or otherwise) of unicast DNS and mDNS >=20 > It is same as now. > Using different TLDs solves the problem. It does, but without my co-chair hat on, I would prefer not to have differe= nt namespaces for unicast vs multicast naming and discovery mechanisms. >> 3. DNSSEC validation >=20 > DNS proxy can forward global queries to DNSSEC validators. There are a lot of people who think that DNSSEC validation should be done a= s close to the host as possible. I'm inclined to agree with them. The downside is that one then needs a way to bootstrap the root's DNSSEC ke= y, and also a way to replace it should the RFC 5011 automated trust anchor = update mechanism become unusable. > Local zones does not require DNSSEC validation, I think. I'm undecided on that. > I thought to write I-D, but now, DHCP has enough capability, > I will consider the issure more. Thank you - your input is much appreciated. Ray From fujiwara@wide.ad.jp Mon Mar 5 07:35:26 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5691B21F8796 for ; Mon, 5 Mar 2012 07:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] 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 weNnNsMxHw9J for ; Mon, 5 Mar 2012 07:35:26 -0800 (PST) Received: from sh.wide.ad.jp (sh.wide.ad.jp [IPv6:2001:200:0:1001::6]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBCD21F877E for ; Mon, 5 Mar 2012 07:35:17 -0800 (PST) Received: from localhost (i114-186-100-136.s41.a013.ap.plala.or.jp [114.186.100.136]) (authenticated (0 bits)) by mail.wide.ad.jp (8.14.1+3.5Wbeta/8.14.1/smtpfeed 1.20) with ESMTP id q25FZFD9024259; Tue, 6 Mar 2012 00:35:16 +0900 (JST) Date: Tue, 06 Mar 2012 00:35:15 +0900 (JST) Message-Id: <20120306.003515.75173118738921266.fujiwara@wide.ad.jp> To: simon.perreault@viagenie.ca From: Kazunori Fujiwara In-Reply-To: <4F54D750.6000203@viagenie.ca> References: <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <4F54D750.6000203@viagenie.ca> X-Mailer: Mew version 6.3.51 on Emacs 23.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 15:35:26 -0000 > From: Simon Perreault > On 2012-03-05 04:25, Ray Bellis wrote: >> Thanks for your note. The idea of running a local authoritative zone >> alongside a forwarding proxy or full recursive server has been seen >> already, for example in the "dnsmasq" software used by many CPE >> vendors. >> >> It is also listed as requirement LAN.DNS.6 in the Broadband Forum's >> TR-124 Issue 2. As such a draft describing this is probably >> unnecessary. > > If I understand the original post correctly, it goes much further than > just saying "home router MUST have an authoritative server". It > specifies a new usage pattern of that server on the home net. That > could mean new draft in this WG, wouldn't it? I think an BCP document or implementation guide is necessary. There are at least three points, I think. +-----------------------+-------+------------------+---------------------- | function ||mDNS | DHCP | +-----------------------+-------+------------------+---------------------- | resolving: || mDNS | normal DNS query via DNS proxy | holding zones: || mDNS | authoritative DNS server +-----------------------++------+------------------+--------------------- | declaring client name || mDNS | DHCP client name | DNS update (directly) +-----------------------++------+------------------+---------------------- |implementation || mDNS |dnsmasq or DHCPD+BIND | new +------------------------------------------------------------------------- mDNS requires special code to resolve the domain name. (Isn't it?) dnsmasq has an authoritative server function in it. -- Kazunori Fujiwara, JPRS From kerlyn2001@gmail.com Mon Mar 5 10:33:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB3A21F8834 for ; Mon, 5 Mar 2012 10:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.71 X-Spam-Level: X-Spam-Status: No, score=-102.71 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 X4nGcntUD4nw for ; Mon, 5 Mar 2012 10:33:15 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE25921F8827 for ; Mon, 5 Mar 2012 10:33:13 -0800 (PST) Received: by lagj5 with SMTP id j5so6122011lag.31 for ; Mon, 05 Mar 2012 10:33:12 -0800 (PST) Received-SPF: pass (google.com: domain of kerlyn2001@gmail.com designates 10.152.130.234 as permitted sender) client-ip=10.152.130.234; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kerlyn2001@gmail.com designates 10.152.130.234 as permitted sender) smtp.mail=kerlyn2001@gmail.com; dkim=pass header.i=kerlyn2001@gmail.com Received: from mr.google.com ([10.152.130.234]) by 10.152.130.234 with SMTP id oh10mr21402261lab.35.1330972392911 (num_hops = 1); Mon, 05 Mar 2012 10:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/C7KhS6wmqKB4CAEnw6cuIeDK/gp30aTQbNAss0Jap8=; b=wcyRthXUDjauhSf1XbfNDw3BKUs838RjVWAncOf8OJpm9YftA7AYwuFSRyMcWPyjxW KDsgscVF2VatdhQXAxT8M1jzrgtz7GJoUKgGLpuzonEZIaF5BdjY9di/yt6lAyDzrWC2 ZGgVOqwwfcawn2b5GfeZSxVRFs506xvpbkqZgKXE8d4wd8XDbbUddFzfLXES61ziNnA/ 1JySJafSJF6+8YUB83tnKIe+DRF48jI9ybuYCxR+PwUDEq2coKOClLBBEdbK5K2lLVxy eWfRFl7Dzlr/gzVRE8vv0XdfSmvy0uUTKbTD6WxTY2Cl4lua2ny5DqKwslowIjtgQoFk rhNA== MIME-Version: 1.0 Received: by 10.152.130.234 with SMTP id oh10mr17506352lab.35.1330972392793; Mon, 05 Mar 2012 10:33:12 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.112.86.196 with HTTP; Mon, 5 Mar 2012 10:33:12 -0800 (PST) In-Reply-To: <20120305180256.14054.83165.idtracker@ietfa.amsl.com> References: <20120305180256.14054.83165.idtracker@ietfa.amsl.com> Date: Mon, 5 Mar 2012 13:33:12 -0500 X-Google-Sender-Auth: tRQBD2pXOn8nUmTx81fmobkmbpc Message-ID: From: Kerry Lynn To: Ray Bellis Content-Type: multipart/alternative; boundary=f46d042c5ec7ada61a04ba83280b Cc: homenet@ietf.org Subject: [homenet] Fwd: New Version Notification for draft-lynn-homenet-site-mdns-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 18:33:15 -0000 --f46d042c5ec7ada61a04ba83280b Content-Type: text/plain; charset=ISO-8859-1 Ray, Can you please request that the Secretariat make this I-D the successor of draft-lynn-dnsext-site-mdns-01? Thanks, Kerry Lynn ---------- Forwarded message ---------- From: Date: Mon, Mar 5, 2012 at 1:02 PM Subject: New Version Notification for draft-lynn-homenet-site-mdns-00.txt To: kerlyn@ieee.org Cc: d.sturek@att.net A new version of I-D, draft-lynn-homenet-site-mdns-00.txt has been successfully submitted by Kerry Lynn and posted to the IETF repository. Filename: draft-lynn-homenet-site-mdns Revision: 00 Title: Extended Multicast DNS Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 12 Abstract: Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional unicast DNS server. Extended mDNS (xmDNS) extends the specification of mDNS to site-local scope in order to support multi-hop LANs that forward multicast packets but do not provide a unicast DNS service. Like mDNS, xmDNS designates a portion of the DNS namespace to apply to the site-local network and specifies rules for its use. The IETF Secretariat --f46d042c5ec7ada61a04ba83280b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ray,

Can you please request that the Secretar= iat make this I-D the successor
of=A0draft-lynn-dnsext-site-mdns-01?<= /font>




Thanks, Kerry Lynn



---------- Forw= arded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Mar 5, 2012 at 1:02 PM
Subject: New Version Notification for = draft-lynn-homenet-site-mdns-00.txt
To: kerlyn@ieee.org
Cc: d.sturek@att.net


A new version of I-D, draft-lynn-homenet-site-mdns-00.txt has been = successfully submitted by Kerry Lynn and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-lynn-homenet-site-mdns
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Extended Multicast DNS
Creation date: =A0 2012-03-05
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12

Abstract:
=A0 Multicast DNS (mDNS) provides the ability to perform DNS-like
=A0 operations on the local link in the absence of any conventional
=A0 unicast DNS server. =A0Extended mDNS (xmDNS) extends the specification=
=A0 of mDNS to site-local scope in order to support multi-hop LANs that =A0 forward multicast packets but do not provide a unicast DNS service.
=A0 Like mDNS, xmDNS designates a portion of the DNS namespace to apply =A0 to the site-local network and specifies rules for its use.




The IETF Secretariat

--f46d042c5ec7ada61a04ba83280b-- From mcr@sandelman.ca Mon Mar 5 11:25:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C9C21F88BF for ; Mon, 5 Mar 2012 11:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.144 X-Spam-Level: X-Spam-Status: No, score=-0.144 tagged_above=-999 required=5 tests=[AWL=-0.604, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 amtn4-Yn-bhq for ; Mon, 5 Mar 2012 11:25:03 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 91E7B21F88A2 for ; Mon, 5 Mar 2012 11:25:03 -0800 (PST) Received: from marajade.sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id 8B9E8344C2; Mon, 5 Mar 2012 14:22:32 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 13E9B98280; Mon, 5 Mar 2012 14:24:41 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 10DF69827F; Mon, 5 Mar 2012 14:24:41 -0500 (EST) From: Michael Richardson To: Mark Townsley In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 05 Mar 2012 14:24:41 -0500 Message-ID: <8796.1330975481@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] Getting ready for Paris X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:25:04 -0000 >>>>> "Mark" == Mark Townsley writes: Mark> Paris is coming soon, and we want to use the time Mark> effectively. Ray and I have asked the homearch document design Mark> team to identify areas in the homenet architecture document Mark> that need discussion time to finish up by end of next week. My Mark> personal thoughts are that two of the most important items we Mark> need to finish off by the end of this next meeting include Mark> boundary detection and what routing protocol we are going to Mark> use. Without these, we are going to have a hard time moving Mark> forward at all. And after that, how much security is necessary, vs how much is sufficient. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From rturner@amalfisystems.com Mon Mar 5 13:54:02 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE3321F8844 for ; Mon, 5 Mar 2012 13:54:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZz12yLEPibp for ; Mon, 5 Mar 2012 13:54:02 -0800 (PST) Received: from omr3.networksolutionsemail.com (omr3.networksolutionsemail.com [205.178.146.53]) by ietfa.amsl.com (Postfix) with ESMTP id BF6A521F882C for ; Mon, 5 Mar 2012 13:54:01 -0800 (PST) Received: from cm-omr7 (mail.networksolutionsemail.com [205.178.146.50]) by omr3.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q25Ls0ct028196 for ; Mon, 5 Mar 2012 16:54:00 -0500 Authentication-Results: cm-omr7 smtp.user=rturner@amalfisystems.com; auth=pass (CRAM-MD5) X-Authenticated-UID: rturner@amalfisystems.com Received: from [98.151.18.158] ([98.151.18.158:61503] helo=[192.168.1.114]) by cm-omr7 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES128-SHA) id AC/B9-29124-7F5355F4; Mon, 05 Mar 2012 16:54:00 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Randy Turner In-Reply-To: Date: Mon, 5 Mar 2012 13:54:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4BC06E0B-36FE-4DA5-A641-E301D9284BEF@amalfisystems.com> References: To: Mark Townsley X-Mailer: Apple Mail (2.1257) Cc: homenet@ietf.org Subject: Re: [homenet] Getting ready for Paris X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:54:02 -0000 I noticed there was a new homenet-related draft that talks about the = "minimum" physical layout required for homenet-related technology Have we defined a bounding box around the types of home networking = technology we are targeting, or a "maximally complicated" layout that = homenet will be able to address with solutions? Thanks! Randy On Mar 2, 2012, at 10:56 PM, Mark Townsley wrote: >=20 > Paris is coming soon, and we want to use the time effectively. Ray and = I have asked the homearch document design team to identify areas in the = homenet architecture document that need discussion time to finish up by = end of next week. My personal thoughts are that two of the most = important items we need to finish off by the end of this next meeting = include boundary detection and what routing protocol we are going to = use. Without these, we are going to have a hard time moving forward at = all. >=20 > Post your thoughts on the list, and if you want specific agenda time = to talk about these or other pertinent topics, get your requests into us = (including your ID reference if you have one, and which of the 5 = chartered topic-areas your request most closely aligns with). >=20 > It's time to dive back in. >=20 > - Mark > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 From Ray.Bellis@nominet.org.uk Mon Mar 5 13:57:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF5B21F87B0 for ; Mon, 5 Mar 2012 13:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.173 X-Spam-Level: X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Ods3MZAI-020 for ; Mon, 5 Mar 2012 13:57:07 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8CACB21F8797 for ; Mon, 5 Mar 2012 13:57:07 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-Transfer-Encoding:MIME-Version; b=KUbNqn9GnBe/77z/LHj1v4YAmsD/G00Pj272QZbELTuOGw4FMZBbxvt0 ChNCbUJmWa8oVKxvg0Nu2iYSKNIXz2Q18uyxdqWzLouphIH/cq3+p2cpJ QSJlarFClh0cTrN; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1330984627; x=1362520627; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Fwd:=20New=20Version=20Notification=20for=0D =0A=20draft-lynn-homenet-site-mdns-00.txt|Date:=20Mon,=20 5=20Mar=202012=2021:57:06=20+0000|Message-ID:=20<8B7F9724 37853B40865000D86857B1D118E71915@wds-exc1.okna.nominet.or g.uk>|To:=20"homenet@ietf.org"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=20quoted- printable; bh=R5jeuFj5VwEsF/sLOVYiDbfpzSyNDrOTh77B/6FLbjg=; b=A4m6YHNFi+e2RZBDIzFryCvGrG9qL4tdazfKBXyBP6gFC3lLUjFMosuj g5EEm2bcY4MzdhTT1yeD0rJKV4S4X5t6BfoqEiNzMJdHSDP3PCvJxPJF0 z3dvNsm7Gj2ZDq8; X-IronPort-AV: E=Sophos;i="4.73,536,1325462400"; d="scan'208";a="31538498" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 05 Mar 2012 21:57:06 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Mon, 5 Mar 2012 21:57:06 +0000 From: Ray Bellis To: "homenet@ietf.org" Thread-Topic: New Version Notification for draft-lynn-homenet-site-mdns-00.txt Thread-Index: Acz7Gueb2Z6WgFRfRD2QZ9b6UayZLA== Date: Mon, 5 Mar 2012 21:57:06 +0000 Message-ID: <8B7F972437853B40865000D86857B1D118E71915@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Fwd: New Version Notification for draft-lynn-homenet-site-mdns-00.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:57:08 -0000 A new version of I-D, draft-lynn-homenet-site-mdns-00.txt has been successf= ully submitted by Kerry Lynn and posted to the IETF repository.=0A= =0A= Filename: draft-lynn-homenet-site-mdns=0A= Revision: 00=0A= Title: Extended Multicast DNS=0A= Creation date: 2012-03-05=0A= WG ID: Individual Submission=0A= Number of pages: 12=0A= =0A= Abstract:=0A= Multicast DNS (mDNS) provides the ability to perform DNS-like=0A= operations on the local link in the absence of any conventional=0A= unicast DNS server. Extended mDNS (xmDNS) extends the specification=0A= of mDNS to site-local scope in order to support multi-hop LANs that=0A= forward multicast packets but do not provide a unicast DNS service.=0A= =0A= Like mDNS, xmDNS designates a portion of the DNS namespace to apply=0A= to the site-local network and specifies rules for its use.=0A= From mcr@sandelman.ca Mon Mar 5 14:05:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C40321F8871 for ; Mon, 5 Mar 2012 14:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 RPvpBGvgLP9e for ; Mon, 5 Mar 2012 14:05:39 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 67A2E21F8881 for ; Mon, 5 Mar 2012 14:05:38 -0800 (PST) Received: from marajade.sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id 490BE344CB for ; Mon, 5 Mar 2012 17:03:05 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id A9AAA98280; Mon, 5 Mar 2012 17:05:13 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id A50869827F for ; Mon, 5 Mar 2012 17:05:13 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 05 Mar 2012 17:05:13 -0500 Message-ID: <7796.1330985113@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:05:40 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable In the DNS space, I would like the WG to declare the name-based selection of DNS servers (what some want to do for walled gardens) should be ruled harmful. If some walled garden wants the name->AAAA mapping private, then=20 just restrict queries to source addresses within the walled garden. If necessary, add level of NS record.=20=20 (IPv4 thinking would lead you to think you do not want to pollute "public" DNS with RFC1918 A records, but IPv6 has no such problem) =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT1U4mYqHRg3pndX9AQIG+QP9EuwjgptvGSnC+hF+Fi5wR1cwZZtHO1tx rsUFljgeuaD9zfCefhMV8mfP3ASB/TVK7U6Dlhpx9rrNwrnVqpQQ6k2UbXPGKF/r 5eHl/G3QYLO1OmyIKuzBQY5SwL2cKqxVDSSFZUG7muFbWEeU2NRYCR5wgPzKGXMa hrVbXd0u3mA= =iC7G -----END PGP SIGNATURE----- --=-=-=-- From marka@isc.org Mon Mar 5 14:24:25 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D2821E8049 for ; Mon, 5 Mar 2012 14:24:25 -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=[AWL=0.000, BAYES_00=-2.599] 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 9QPwQjMi4+rh for ; Mon, 5 Mar 2012 14:24:24 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 66FDC21E8035 for ; Mon, 5 Mar 2012 14:24:24 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 05D0EC9425; Mon, 5 Mar 2012 22:24:12 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:254b:f761:ce8a:f684]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 789C0216C31; Mon, 5 Mar 2012 22:24:11 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 9B7761E120BC; Tue, 6 Mar 2012 09:24:00 +1100 (EST) To: Ray Bellis From: Mark Andrews References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> In-reply-to: Your message of "Mon, 05 Mar 2012 15:33:51 -0000." <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> Date: Tue, 06 Mar 2012 09:24:00 +1100 Message-Id: <20120305222400.9B7761E120BC@drugs.dv.isc.org> Cc: Kazunori Fujiwara , "homenet@ietf.org Group" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:24:25 -0000 In message <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk>, Ray Bellis wr ites: > > On 5 Mar 2012, at 15:15, Kazunori Fujiwara wrote: > > > RI see. DHCP has enough function. RFC 2132 defines DHCP client host > > name option, and RFC 4702 Section 3.2. "Client Desires to Update A > > RRs" defines the option to DNS RR. > > > > # I'm not aware that DHCPv6 has the same option. > > Me neither, although whether DHCPv6 actually gets used within the Homenet (as > opposed to standard Neighbor Discovery) remains to be seen. > > > Using DHC client host name option is easier than implementing DNS > > Update client in each client. > > Agreed, and it removes the need for the TSIG key management normally required > for DNS Dynamic Updates. A significant percentage of home machines will roam and those machines will need to be able to register their current address in the DNS. I do this today when my Mac roams. TSIG is unavoidable and cheap. UPDATE itself is relatively cheap. For PTR records TCP is a good enough authenticator for UPDATE. > >> 1. naming updates and queries between subnets > > > > One upstream, and multiple subnets case, it may be solved by using one > > DHCP server and multiple DHCP relay agents. > > I was more thinking about mDNS - there's no standardised mechanism (although > drafts are forthcoming) for using "link-local mDNS" in multiple segments. > > The options would appear to be either a multicast relay agent running on inte > rnal CPE, or an enhancement to mDNS to support "site-local" multicast. > > > Multiple upstream case, manual configuration is necessary. An end > > user setup one DNS server which serves local zone and multiple > > reverse zones. DHCP servers send updates to the DNS server. > > The unicast case is likely simpler, but we also need to beware the case where > the entire Homenet stops working because of the failure of a single "super n > ode". > > >> 2. integration (or otherwise) of unicast DNS and mDNS > > > > It is same as now. > > Using different TLDs solves the problem. > > It does, but without my co-chair hat on, I would prefer not to have different > namespaces for unicast vs multicast naming and discovery mechanisms. > > > >> 3. DNSSEC validation > > > > DNS proxy can forward global queries to DNSSEC validators. > > There are a lot of people who think that DNSSEC validation should be done as > close to the host as possible. I'm inclined to agree with them. > > The downside is that one then needs a way to bootstrap the root's DNSSEC key, > and also a way to replace it should the RFC 5011 automated trust anchor upda > te mechanism become unusable. > > > Local zones does not require DNSSEC validation, I think. > > I'm undecided on that. > > > I thought to write I-D, but now, DHCP has enough capability, > > I will consider the issure more. > > Thank you - your input is much appreciated. > > Ray > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From jari.arkko@piuha.net Tue Mar 6 03:02:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF58521F87F4 for ; Tue, 6 Mar 2012 03:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 YzNPPoPHQ1zO for ; Tue, 6 Mar 2012 03:02:05 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB1221F86DF for ; Tue, 6 Mar 2012 03:02:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AC1912DA0D; Tue, 6 Mar 2012 13:02:04 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVZMyeOO2TQh; Tue, 6 Mar 2012 13:02:02 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id C1B0F2CC3C; Tue, 6 Mar 2012 13:02:01 +0200 (EET) Message-ID: <4F55EEA9.5060607@piuha.net> Date: Tue, 06 Mar 2012 13:02:01 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "homenet@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Ari_Ker=E4nen?= Subject: [homenet] draft on physical configurations X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:02:06 -0000 We have been looking for some standards on home network physical configurations. Anybody that can point us to some existing standards, and do you have opinions on how good they are? We've been looking for a while, but while we've seen many white papers from local governments and ISPs as well as some related standards, but have yet to find one a comprehensive one that we really liked. See http://tools.ietf.org/html/draft-arkko-homenet-physical-standard-00 for a discussion of what we'd like to find and some proposed requirements. Basically we are looking for something that would say use cabling standards, reserve space, equip the space in , and use power, cabinet and rack standards. Comments appreciated. Jari From henk@uijterwaal.nl Tue Mar 6 03:43:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D3321F88D0 for ; Tue, 6 Mar 2012 03:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 n00kBla-QbnZ for ; Tue, 6 Mar 2012 03:43:54 -0800 (PST) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 279A321F886A for ; Tue, 6 Mar 2012 03:43:54 -0800 (PST) Received: from geir.local (thuis.uijterwaal.nl [82.95.178.49]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id q26BhLFc015110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 12:43:22 +0100 (CET) (envelope-from henk@uijterwaal.nl) Message-ID: <4F55F859.7000903@uijterwaal.nl> Date: Tue, 06 Mar 2012 12:43:21 +0100 From: Henk Uijterwaal User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <4F5289DC.3030101@gmail.com> In-Reply-To: <4F5289DC.3030101@gmail.com> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [homenet] Getting ready for Paris X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 11:43:55 -0000 On 03/03/2012 22:15, Brian E Carpenter wrote: > On 2012-03-03 19:56, Mark Townsley wrote: >> >> Paris is coming soon, and we want to use the time effectively. Ray and I >> have asked the homearch document design team to identify areas in the >> homenet architecture document that need discussion time to finish up by >> end of next week. > > I noticed that there is no section discussing operations and management > as a topic on its own. It seems to me that this is needed, even if what > it says is that the architecture must ensure that manual operations and > management are either not needed at all, or are absolutely minimal, Minimal looks like a problem to me. If the user gets the device, configures it and then has a problem X months later, he is likely to have forgotten that he had to change something in the settings in order to make it work. If he then tries to fix a problem with a "reset to factory defaults", the device will never work again. > or are remotely accessible to specialists. How can this be arranged? My CPE has remote access to the config i/f but I obviously don't want this to be open to the world, so I put a password on it and can fix things even if I'm away from home (assuming that there is basic connectivity). I wouldn't mind giving a password to my ISP in order to have them help me to support it but then the p/w should be unique. That creates a problem on their end, as they'd have to maintain a DB with password of all CPE's of their 1 million customers. One p/w for all devices isn't a good idea either. > A couple of days ago I had no IP connectivity at home. The conversation > with the ISP help desk responder included her asking me which model > of D-Link I have, and talking me through its menus. Of course I'd > done all that before I called, but it struck me as ridiculous that > any help desk would ask a domestic customer to do that. It will only > be worse for real homenets. I don't think the average user will actually check the configuration menus before calling the helpdesk. Besides that, if you have no connectivity, what else can one do but check the configuration over the phone? My experience with friends and family with computer problems is that they always claim that "they didn't touch a thing" but in practice, they often did, so checking the config of the device is an useful thing to do. Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 ------------------------------------------------------------------------------ There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) From mcr@sandelman.ca Tue Mar 6 07:13:50 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA8B21F885C for ; Tue, 6 Mar 2012 07:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 V4egypkfDRWd for ; Tue, 6 Mar 2012 07:13:49 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id C0A1521F87B3 for ; Tue, 6 Mar 2012 07:13:49 -0800 (PST) Received: from marajade.sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id 4D117344CF for ; Tue, 6 Mar 2012 10:11:18 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id D390998281; Tue, 6 Mar 2012 10:13:47 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C9B4B98280 for ; Tue, 6 Mar 2012 10:13:47 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <4F55F859.7000903@uijterwaal.nl> References: <4F5289DC.3030101@gmail.com> <4F55F859.7000903@uijterwaal.nl> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Tue, 06 Mar 2012 10:13:47 -0500 Message-ID: <18836.1331046827@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Getting ready for Paris X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:13:50 -0000 >>>>> "Henk" == Henk Uijterwaal writes: Henk> How can this be arranged? My CPE has remote access to the Henk> config i/f but I obviously don't want this to be open to the Henk> world, so I put a password on it and can fix things even if Henk> I'm away from home (assuming that there is basic Henk> connectivity). I wouldn't mind giving a password to my ISP in So, we need for the ISP to get read access to the configuration information and state. This seems like a job for SNMP read-only with community string "public". Some extra security might be that there is a DHCP option/IPv6CP from the ISP which tells your device the IP address where their queries are coming from. Henk> I don't think the average user will actually check the Henk> configuration menus before calling the helpdesk. Besides Henk> that, if you have no connectivity, what else can one do but Henk> check the configuration over the phone? My experience with Henk> friends and family with computer problems is that they always Henk> claim that "they didn't touch a thing" but in practice, they Henk> often did, so checking the config of the device is an useful Henk> thing to do. If the ISP has a backup of the configuration that was working (via the read-only interface), and the device can minimally work after a reset running-config-to-factory-default, then a comparison could occur. What matters here is that the reset-to-factory-defaults does not destroy the previously saved configuration, but rather moves it aside, yet leaves it accessible to SNMP. (And then there is the other cfg stuff, the one starts with Y, I think, and netconf too...?) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Tue Mar 6 07:15:48 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B101C21F8783 for ; Tue, 6 Mar 2012 07:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.471 X-Spam-Level: X-Spam-Status: No, score=-1.471 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 SMmQZ1EPdYIg for ; Tue, 6 Mar 2012 07:15:48 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id A73A821F8850 for ; Tue, 6 Mar 2012 07:15:46 -0800 (PST) Received: from marajade.sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id 9E04D344BF; Tue, 6 Mar 2012 10:13:15 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 6694E98281; Tue, 6 Mar 2012 10:15:45 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 635EE98280; Tue, 6 Mar 2012 10:15:45 -0500 (EST) From: Michael Richardson To: Mark Andrews In-Reply-To: <20120305222400.9B7761E120BC@drugs.dv.isc.org> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Tue, 06 Mar 2012 10:15:45 -0500 Message-ID: <19226.1331046945@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Ray Bellis , Kazunori Fujiwara , "homenet@ietf.org Group" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:15:48 -0000 >>>>> "Mark" == Mark Andrews writes: Mark> A significant percentage of home machines will roam and those Mark> machines will need to be able to register their current Mark> address in the DNS. I do this today when my Mac roams. TSIG Mark> is unavoidable and cheap. UPDATE itself is relatively cheap. Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith way to do key establishment so that TSIG can be initialized? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From jhw@apple.com Tue Mar 6 10:25:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56F021E80D7 for ; Tue, 6 Mar 2012 10:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.286 X-Spam-Level: X-Spam-Status: No, score=-110.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 GzZJtuDgFC46 for ; Tue, 6 Mar 2012 10:25:49 -0800 (PST) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 55D9021E8056 for ; Tue, 6 Mar 2012 10:25:15 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M0H00K1S73R3UM1@mail-out.apple.com> for homenet@ietf.org; Tue, 06 Mar 2012 10:24:54 -0800 (PST) X-AuditID: 11807136-b7c0cae000002dec-19-4f5656290aef Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id 48.48.11756.926565F4; Tue, 06 Mar 2012 10:23:37 -0800 (PST) From: james woodyatt In-reply-to: <19226.1331046945@marajade.sandelman.ca> Date: Tue, 06 Mar 2012 10:23:37 -0800 Message-id: <3725BCBE-2222-4AF8-A5C0-588381758A38@apple.com> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> To: HOMENET X-Mailer: Apple Mail (2.1427) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42IRPMjroFsaFuZvMH+DgsX7RYdYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWHyOsaCU+wVf5b/ZGxgbGTrYuTgkBAwkZi7WKaLkRPIFJO4 cG89UJiLQ0hgNpNET/d9FpAEs4CWxI1/L5lAbF4BPYnbF/8xgtjCAkYSVz73s4LYbAIqEt8u 3wWr4RQwlTjQ8Z0NxGYBirds+MEGMUdbYtnC18wQc2wkvjfvYYZYdp9Jomn5abBBIgJyEhs/ 7GaEOE5W4ux7+QmMfLOQnDELyRmzkIxdwMi8ilGwKDUnsdLQVC+xoCAnVS85P3cTIyiQGgrN djDu+Ct3iFGAg1GJh/eifpi/EGtiWXFl7iFGCQ5mJRHeb+9D/YV4UxIrq1KL8uOLSnNSiw8x SnOwKInzrvsf6C8kkJ5YkpqdmlqQWgSTZeLglGpgdCmc+ayXwV1ESLk5M+i03rbvZydmrspf oOJ82TlzwSaJbyaW09gu/XyYfs5spqVuerLs1UVXm1ezhM4KyEnq4drN8+ruXHe223/Y9d7/ 8yluOyXHonYxtCJrqV35x+xXz8NaK/JqJ1nnXFvEtu4+v97BiZlOTznPbUz/qvPc/v7kiA/f AlVTlFiKMxINtZiLihMBVK8l6yACAAA= Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:25:52 -0000 On Mar 6, 2012, at 07:15 , Michael Richardson wrote: > "Mark" == Mark Andrews writes: > Mark> A significant percentage of home machines will roam and those > Mark> machines will need to be able to register their current > Mark> address in the DNS. I do this today when my Mac roams. TSIG > Mark> is unavoidable and cheap. UPDATE itself is relatively cheap. > > Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith > way to do key establishment so that TSIG can be initialized? The alternative is to delegate all that business to 3rd parties with big data centers in the proverbial cloud. Yes, that means that you're relying on Internet service to be constantly available to resolve service locations on your local home network, but it does seem to work reasonably well today. -- james woodyatt member of technical staff, core os networking From dave.taht@gmail.com Tue Mar 6 10:49:28 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED40E21E80A4 for ; Tue, 6 Mar 2012 10:49:28 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 p2W2YCEtRBDW for ; Tue, 6 Mar 2012 10:49:28 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A941321E807C for ; Tue, 6 Mar 2012 10:49:27 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so3395021wgb.13 for ; Tue, 06 Mar 2012 10:49:26 -0800 (PST) Received-SPF: pass (google.com: domain of dave.taht@gmail.com designates 10.180.93.233 as permitted sender) client-ip=10.180.93.233; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dave.taht@gmail.com designates 10.180.93.233 as permitted sender) smtp.mail=dave.taht@gmail.com; dkim=pass header.i=dave.taht@gmail.com Received: from mr.google.com ([10.180.93.233]) by 10.180.93.233 with SMTP id cx9mr13682385wib.14.1331059766927 (num_hops = 1); Tue, 06 Mar 2012 10:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nhZWIkg6eNUZbxP9zJZmTZi1Rq/i/P9dzCgYHrtrIds=; b=PcRFPSItVr/TqaAePEvEmTeiHtmjJEoKS0+G4Ng3QdIxEewVO7R94EX7wuuSm7svHf tRExKpQlzjghVpgvTektiROXBc4zEx1EEr3PbhoiWtj6Yda+q/0qu/17Gqbx9bUZ64WH rfoaUwkJFghGCyAvS067GYDpdqBS9sqHjZ2oJksZnlGKLra+hPz1vXaJIDEkjC/Fo5sS OvoY70nC81GAqk3rmP6jIaP0sp2xM+LKibSmywnRxBrPwtzBJwSxVRVoETV3b4NWn3M8 um0SOXm2z9dVh/xfd3A+CPxuvtWPGjNyiBRrHoFCZB8dBZODPfWN17mW3EjULT2hSTwD W1bA== MIME-Version: 1.0 Received: by 10.180.93.233 with SMTP id cx9mr10817803wib.14.1331059766816; Tue, 06 Mar 2012 10:49:26 -0800 (PST) Received: by 10.223.151.8 with HTTP; Tue, 6 Mar 2012 10:49:26 -0800 (PST) In-Reply-To: <3725BCBE-2222-4AF8-A5C0-588381758A38@apple.com> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <3725BCBE-2222-4AF8-A5C0-588381758A38@apple.com> Date: Tue, 6 Mar 2012 10:49:26 -0800 Message-ID: From: Dave Taht To: james woodyatt Content-Type: multipart/alternative; boundary=f46d04389481936fab04ba9780e7 Cc: HOMENET Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 18:49:29 -0000 --f46d04389481936fab04ba9780e7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 6, 2012 at 10:23 AM, james woodyatt wrote: > On Mar 6, 2012, at 07:15 , Michael Richardson wrote: > > "Mark" =3D=3D Mark Andrews writes: > > Mark> A significant percentage of home machines will roam and those > > Mark> machines will need to be able to register their current > > Mark> address in the DNS. I do this today when my Mac roams. TSIG > > Mark> is unavoidable and cheap. UPDATE itself is relatively cheap. > > > > Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith > > way to do key establishment so that TSIG can be initialized? > > > The alternative is to delegate all that business to 3rd parties with big > data centers in the proverbial cloud. Yes, that means that you're relyin= g > on Internet service to be constantly available to resolve service locatio= ns > on your local home network, but it does seem to work reasonably well toda= y. > In some parts of the world, maybe, like california. Elsewhere, say in Nicaragua... not so much. I would personally prefer that those designing this stuff with *any* dependencies on centralized services spend some time doing research in south america, Libya, africa, eastern europe, the australian outback, and places like that... > -- > james woodyatt > member of technical staff, core os networking > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net --f46d04389481936fab04ba9780e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 6, 2012 at 10:23 AM, james w= oodyatt <jhw@apple.co= m> wrote:
On Mar 6, 2012, at 07:15 , Michael Richardson <mcr@sandelman.ca> wrote:
> "Mark" =3D=3D Mark Andrews <marka@isc.org> writes:
> =A0 =A0Mark> A significant percentage of home machines will roam an= d those
> =A0 =A0Mark> machines will need to be able to register their curren= t
> =A0 =A0Mark> address in the DNS. =A0I do this today when my Mac roa= ms. =A0TSIG
> =A0 =A0Mark> is unavoidable and cheap. =A0UPDATE itself is relative= ly cheap.
>
> Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith<= br> > way to do key establishment so that TSIG can be initialized?


The alternative is to delegate all that business to 3rd parties with = big data centers in the proverbial cloud. =A0Yes, that means that you'r= e relying on Internet service to be constantly available to resolve service= locations on your local home network, but it does seem to work reasonably = well today.

In some parts of the world, maybe, like california. <= br>
Elsewhere, say in Nicaragua... not so much. I would personally prefe= r that those designing this stuff with *any* dependencies on centralized se= rvices spend some time doing research in south america, Libya, africa, east= ern europe, the australian outback, and places like that...


--
james woodyatt <jhw@apple.com> member of technical staff, core os networking



_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet



--
Dave T=E4ht=
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
--f46d04389481936fab04ba9780e7-- From gettysjim@gmail.com Tue Mar 6 11:00:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D10E21F87A0 for ; Tue, 6 Mar 2012 11:00:42 -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 Ez52CmwHknZf for ; Tue, 6 Mar 2012 11:00:41 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE3C21F8779 for ; Tue, 6 Mar 2012 11:00:36 -0800 (PST) Received: by yhpp34 with SMTP id p34so2747765yhp.31 for ; Tue, 06 Mar 2012 11:00:35 -0800 (PST) Received-SPF: pass (google.com: domain of gettysjim@gmail.com designates 10.236.9.33 as permitted sender) client-ip=10.236.9.33; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gettysjim@gmail.com designates 10.236.9.33 as permitted sender) smtp.mail=gettysjim@gmail.com; dkim=pass header.i=gettysjim@gmail.com Received: from mr.google.com ([10.236.9.33]) by 10.236.9.33 with SMTP id 21mr35526025yhs.39.1331060435795 (num_hops = 1); Tue, 06 Mar 2012 11:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aCBmQmQqK1KA8AsvHIv3CGXuh0lT8i90AkEdndqShMo=; b=cGEny1znk62lZfxal9CCkpaHLRlqhdK5PDIwb2eb0DQU2lamigvVpkFATpsviI1qMG 1tE9Z2lJCmxKfUc9kwNxEhEjQivoiNLhW1iOyfqMoMlupBvvLVqJ6WvM7plek7UijUmK jyVY4N6Tp2t/pV4blgIdzV1rj+IZjOVTjN7hzmibljqtXCQlWyvM1Ikefle9f5/g2HKJ WvjYhcfP/MTlVh4d6GDzfoIv5N4g8cjge2fl+67VNJjnk3YL/VH9XaX50rdPUNR9oyzQ hQtbjsyxxPMw194YV77YnM49qv21l/JP37LAd3e+kLQm+PR1n09Xxlv5dQlw2YDTssoK CLnw== Received: by 10.236.9.33 with SMTP id 21mr28237129yhs.39.1331060435714; Tue, 06 Mar 2012 11:00:35 -0800 (PST) Received: from [192.168.1.27] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id f40sm31873616ani.16.2012.03.06.11.00.33 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 11:00:34 -0800 (PST) Sender: Jim Gettys Message-ID: <4F565ED0.1060105@freedesktop.org> Date: Tue, 06 Mar 2012 14:00:32 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Dave Taht References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <3725BCBE-2222-4AF8-A5C0-588381758A38@apple.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: HOMENET , james woodyatt Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 19:00:42 -0000 On 03/06/2012 01:49 PM, Dave Taht wrote: > > > On Tue, Mar 6, 2012 at 10:23 AM, james woodyatt > wrote: > > On Mar 6, 2012, at 07:15 , Michael Richardson > wrote: > > "Mark" == Mark Andrews > > writes: > > Mark> A significant percentage of home machines will roam and > those > > Mark> machines will need to be able to register their current > > Mark> address in the DNS. I do this today when my Mac roams. > TSIG > > Mark> is unavoidable and cheap. UPDATE itself is relatively > cheap. > > > > Are you asking for a link-local/mDNS-across-the-homenet > leap-of-faith > > way to do key establishment so that TSIG can be initialized? > > > The alternative is to delegate all that business to 3rd parties > with big data centers in the proverbial cloud. Yes, that means > that you're relying on Internet service to be constantly available > to resolve service locations on your local home network, but it > does seem to work reasonably well today. > > > In some parts of the world, maybe, like california. > > Elsewhere, say in Nicaragua... not so much. I would personally prefer > that those designing this stuff with *any* dependencies on centralized > services spend some time doing research in south america, Libya, > africa, eastern europe, the australian outback, and places like that... > > Or Peru, or Uruguay, or Uganda, or.... (given my OLPC experience). I have to emphasise what Dave's saying here: requiring centralised services to work at all is really a non-starter, not to mention what happens when things break in the developed world. What's more, in those parts of the world, they can't afford either the reliable connectivity or expensive kit in schools/houses and often use off the shelf commodity home routers even in places we'd probably do something much better. My point of view is to do it right in the home, so everyone benefits at the low end. - Jim From mcr@sandelman.ca Tue Mar 6 11:38:10 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4986521E80AE for ; Tue, 6 Mar 2012 11:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 vS3r34sDrd09 for ; Tue, 6 Mar 2012 11:38:09 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id A638E21E807C for ; Tue, 6 Mar 2012 11:38:08 -0800 (PST) Received: from marajade.sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id 8AD3A344BF; Tue, 6 Mar 2012 14:35:37 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 6185E98281; Tue, 6 Mar 2012 14:38:07 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5E0F198280; Tue, 6 Mar 2012 14:38:07 -0500 (EST) From: Michael Richardson To: Mark Townsley In-Reply-To: References: , <9B12A77F-91FE-4FAC-B4F9-36E0639B9069@dlink.com.tw> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Tue, 06 Mar 2012 14:38:07 -0500 Message-ID: <5442.1331062687@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Framing homenet borders and default policies X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 19:38:10 -0000 {I was cleaning out email that I felt I SHOULD read} >>>>> "Mark" == Mark Townsley writes: Mark> For the 3 base cases listed above (Local, Internet, Guest) If Mark> we can solidly answer the 5 (6) questions below, we've Mark> accomplished well what is within our scope: Mark> 1. Do we share or accept assigned prefixes over this link? Mark> 2. Do we share or accept routing information over this link? Mark> 3. Do we share or accept services information over this link? Mark> 4. Do we share or accept naming information over this link? Mark> 5. Do we allow application traffic to flow over this link? If Mark> so, do we apply a firewall function? (6.) Do we allow Mark> troubleshooting protocols over this link (ping, traceroute - Mark> could be part of the FW question in #5)? What are we going to do with this? Does this discussion go into the architecture document? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From rturner@amalfisystems.com Tue Mar 6 12:14:31 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB31B21E80D6 for ; Tue, 6 Mar 2012 12:14:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sC+euk-T-LBh for ; Tue, 6 Mar 2012 12:14:31 -0800 (PST) Received: from omr11.networksolutionsemail.com (omr11.networksolutionsemail.com [205.178.146.61]) by ietfa.amsl.com (Postfix) with ESMTP id E246D21E80D2 for ; Tue, 6 Mar 2012 12:14:30 -0800 (PST) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr11.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q26KETZh030916 for ; Tue, 6 Mar 2012 15:14:29 -0500 X-Authenticated-IP: 98.151.18.158 Received: from [98.151.18.158] ([98.151.18.158:49800] helo=[192.168.1.128]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id 35/93-09323-420765F4; Tue, 06 Mar 2012 15:14:29 -0500 References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <3725BCBE-2222-4AF8-A5C0-588381758A38@apple.com> <4F565ED0.1060105@freedesktop.org> In-Reply-To: <4F565ED0.1060105@freedesktop.org> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A406) From: Randy Turner Date: Tue, 6 Mar 2012 12:14:28 -0800 To: Jim Gettys Cc: HOMENET , Dave Taht , james woodyatt Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 20:14:31 -0000 +1 On Mar 6, 2012, at 11:00 AM, Jim Gettys wrote: > On 03/06/2012 01:49 PM, Dave Taht wrote: >> >> >> On Tue, Mar 6, 2012 at 10:23 AM, james woodyatt > > wrote: >> >> On Mar 6, 2012, at 07:15 , Michael Richardson > > wrote: >>> "Mark" == Mark Andrews > >> writes: >>> Mark> A significant percentage of home machines will roam and >> those >>> Mark> machines will need to be able to register their current >>> Mark> address in the DNS. I do this today when my Mac roams. >> TSIG >>> Mark> is unavoidable and cheap. UPDATE itself is relatively >> cheap. >>> >>> Are you asking for a link-local/mDNS-across-the-homenet >> leap-of-faith >>> way to do key establishment so that TSIG can be initialized? >> >> >> The alternative is to delegate all that business to 3rd parties >> with big data centers in the proverbial cloud. Yes, that means >> that you're relying on Internet service to be constantly available >> to resolve service locations on your local home network, but it >> does seem to work reasonably well today. >> >> >> In some parts of the world, maybe, like california. >> >> Elsewhere, say in Nicaragua... not so much. I would personally prefer >> that those designing this stuff with *any* dependencies on centralized >> services spend some time doing research in south america, Libya, >> africa, eastern europe, the australian outback, and places like that... >> >> > > Or Peru, or Uruguay, or Uganda, or.... (given my OLPC experience). > > I have to emphasise what Dave's saying here: requiring centralised > services to work at all is really a non-starter, not to mention what > happens when things break in the developed world. > > What's more, in those parts of the world, they can't afford either the > reliable connectivity or expensive kit in schools/houses and often use > off the shelf commodity home routers even in places we'd probably do > something much better. My point of view is to do it right in the home, > so everyone benefits at the low end. > - Jim > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From rturner@amalfisystems.com Tue Mar 6 12:19:06 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D7421E8053 for ; Tue, 6 Mar 2012 12:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 OT0Vc3-n-jdN for ; Tue, 6 Mar 2012 12:19:06 -0800 (PST) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id F0B8021E80A3 for ; Tue, 6 Mar 2012 12:19:05 -0800 (PST) Received: from cm-omr9 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q26KJ4CV032116 for ; Tue, 6 Mar 2012 15:19:05 -0500 X-Authenticated-IP: 98.151.18.158 Received: from [98.151.18.158] ([98.151.18.158:49808] helo=[192.168.1.128]) by cm-omr9 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTP id FA/19-22803-831765F4; Tue, 06 Mar 2012 15:19:04 -0500 References: <9B12A77F-91FE-4FAC-B4F9-36E0639B9069@dlink.com.tw> <5442.1331062687@marajade.sandelman.ca> In-Reply-To: <5442.1331062687@marajade.sandelman.ca> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A406) From: Randy Turner Date: Tue, 6 Mar 2012 12:19:03 -0800 To: Michael Richardson Cc: "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] Framing homenet borders and default policies X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 20:19:06 -0000 After a 2nd reading of the current arch doc, I'm still not sure where the "b= ounding box" is around our work - seems like the language in section 3 shoul= d be tightened up - or rephrased to emphasize that the list of topology supp= ort is normative and not a set of examples Randy On Mar 6, 2012, at 11:38 AM, Michael Richardson wrote: >=20 > {I was cleaning out email that I felt I SHOULD read} >=20 >>>>>> "Mark" =3D=3D Mark Townsley writes: > Mark> For the 3 base cases listed above (Local, Internet, Guest) If > Mark> we can solidly answer the 5 (6) questions below, we've > Mark> accomplished well what is within our scope: >=20 > Mark> 1. Do we share or accept assigned prefixes over this link? > Mark> 2. Do we share or accept routing information over this link? > Mark> 3. Do we share or accept services information over this link? > Mark> 4. Do we share or accept naming information over this link? > Mark> 5. Do we allow application traffic to flow over this link? If > Mark> so, do we apply a firewall function? (6.) Do we allow > Mark> troubleshooting protocols over this link (ping, traceroute - > Mark> could be part of the FW question in #5)? >=20 > What are we going to do with this? > Does this discussion go into the architecture document? >=20 > --=20 > ] He who is tired of Weird Al is tired of life! | firewal= ls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archi= tect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dr= iver[ > Kyoto Plus: watch the video > then sign the petition.=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 From marka@isc.org Tue Mar 6 14:54:54 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68F221E8014 for ; Tue, 6 Mar 2012 14:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] 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 1wN1UZHtTncV for ; Tue, 6 Mar 2012 14:54:50 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 455E621F8523 for ; Tue, 6 Mar 2012 14:54:50 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 80987C9423; Tue, 6 Mar 2012 22:54:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:17d:90bc:5fc8:434]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 48F89216C31; Tue, 6 Mar 2012 22:54:37 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 52D1D1E1E29D; Wed, 7 Mar 2012 09:54:30 +1100 (EST) To: Michael Richardson From: Mark Andrews References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> In-reply-to: Your message of "Tue, 06 Mar 2012 10:15:45 CDT." <19226.1331046945@marajade.sandelman.ca> Date: Wed, 07 Mar 2012 09:54:30 +1100 Message-Id: <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> Cc: Ray Bellis , Kazunori Fujiwara , "homenet@ietf.org Group" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:54:54 -0000 In message <19226.1331046945@marajade.sandelman.ca>, Michael Richardson writes: > >>>>> "Mark" == Mark Andrews writes: > Mark> A significant percentage of home machines will roam and those > Mark> machines will need to be able to register their current > Mark> address in the DNS. I do this today when my Mac roams. TSIG > Mark> is unavoidable and cheap. UPDATE itself is relatively cheap. > > Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith > way to do key establishment so that TSIG can be initialized? For homes a shared key is fine or if you want a small database of keys. Businesses would use a shared database between the nameserver and the provision system for storing the TSIG key associations. The TSIG key should be assigned as part of the machines registration process. The machines do the same thing in both environments. Just the implementation differs slightly. TSIG is nothing more than a name/secret pair. One could go all the way to using GSS-TSIG but that is overkill for the home network and for many small businesses. The point is that the home router is expecting to see signed UPDATE requests from both inside and outside and to potententially be a master for zone transfers to external nameserver which publish the zone to the world. With IPv6 homes don't need to be second class entities. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mcr@sandelman.ca Wed Mar 7 10:15:25 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D561621F8661 for ; Wed, 7 Mar 2012 10:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 hmSpBY9mfS4D for ; Wed, 7 Mar 2012 10:15:25 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E05F121F8631 for ; Wed, 7 Mar 2012 10:15:24 -0800 (PST) Received: from marajade.sandelman.ca (74-115-197-34.eng.wind.ca [74.115.197.34]) by relay.sandelman.ca (Postfix) with ESMTPS id 9600F344CB; Wed, 7 Mar 2012 13:12:49 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 715A798281; Wed, 7 Mar 2012 08:46:31 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5C35598182; Wed, 7 Mar 2012 08:46:31 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 07 Mar 2012 08:46:31 -0500 Message-ID: <26689.1331127991@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Mark Andrews Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 18:15:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mark" =3D=3D Mark Andrews writes: Mark> In message <19226.1331046945@marajade.sandelman.ca>, Michael Rich= ardson writes: >> >>>>> "Mark" =3D=3D Mark Andrews writes: Mark> A significant percentage of home machines will roam and those Mark> machines will need to be able to register their current Mark> address in the DNS. I do this today when my Mac roams. TSIG Mark> is unavoidable and cheap. UPDATE itself is relatively cheap. >> Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith >> way to do key establishment so that TSIG can be initialized? Mark> For homes a shared key is fine or if you want a small database of Mark> keys. You didn't answer my question! I wasn't asking for justification, I was asking for clarification of what you are proposing. I imagine a situation where one plugs into the homenet with your laptop. Some application/agent on the laptop realizes (via mDNS/Bonjour? via DCHP? TBD) that this network supports IPv6, and supports persistent names. It asks you if you'd like to persist your name into the local zone. It has an option to say, "make this name follow me"(%). There is a protocol exchange (TBD) with the designated homenet DNS server(s), and this establishes a TSIG for later use.=20=20 Same TSIG could also be used to update the reverse map, but as you indicate, TCP from the address you want to update is probably good enough for addresses considered "local". While this might seems bit out of scope for homenet (to provide names for laptops which are not at home), it's actually not. Depending upon how the protocol works, it might be another way to deal with the mDNS/Bonjour-does-not-cross-link problem. If the TSIG setup protocol can be mediated(proxied) in a link-layer attached way, then it might be that we do not need to make Bonjour cross links, as we can just use DNS. (%)-one need not have a globally reachable name. One might be registering into .homenet/.lan/.local. This may be for the benefit of machines which are still at home, and which need to find your laptop. Or the home user might have a global DNS name. The difference is really just a matter of NS/DS records. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT1dmtoqHRg3pndX9AQI7WQP/QilJgSkue2m5AvoBQkAl1RRPlZ3E8xwW 6Jm6PTBHyf/tN2uBL5frNBzhfALT3nsXWsUujF3qmWv7lwbUCNCYE0rpLKuoUw3Z 82J/4ArNE0N88ht+dQ7ruYNNlb7H69xdblhEf9DG4eGGkPmVed1n7XCm/TY2b6j4 OIRjF0FsdcQ= =QTZ2 -----END PGP SIGNATURE----- --=-=-=-- From marka@isc.org Wed Mar 7 17:20:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB8621E8014 for ; Wed, 7 Mar 2012 17:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] 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 4wT6bhSk0A6z for ; Wed, 7 Mar 2012 17:20:27 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5E021E800C for ; Wed, 7 Mar 2012 17:20:27 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 42649C942B; Thu, 8 Mar 2012 01:20:14 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:d6f:a002:cd07:ed09]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id E0DBB216C31; Thu, 8 Mar 2012 01:20:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 1E4221E28C02; Thu, 8 Mar 2012 12:20:11 +1100 (EST) To: Michael Richardson From: Mark Andrews References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> In-reply-to: Your message of "Wed, 07 Mar 2012 08:46:31 CDT." <26689.1331127991@marajade.sandelman.ca> Date: Thu, 08 Mar 2012 12:20:11 +1100 Message-Id: <20120308012011.1E4221E28C02@drugs.dv.isc.org> Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:20:27 -0000 In message <26689.1331127991@marajade.sandelman.ca>, Michael Richardson writes: > >>>>> "Mark" =3D=3D Mark Andrews writes: > Mark> In message <19226.1331046945@marajade.sandelman.ca>, Michael Rich= > ardson writes: > >> >>>>> "Mark" =3D=3D Mark Andrews writes: > Mark> A significant percentage of home machines will roam and those > Mark> machines will need to be able to register their current > Mark> address in the DNS. I do this today when my Mac roams. TSIG > Mark> is unavoidable and cheap. UPDATE itself is relatively cheap. > > >> Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith > >> way to do key establishment so that TSIG can be initialized? > > Mark> For homes a shared key is fine or if you want a small database of > Mark> keys. > > You didn't answer my question! I wasn't asking for justification, I was > asking for clarification of what you are proposing. Ok. Lets look at a working model that Microsoft has with AD. You boot the machine them a Adminstrator adds the machine to the AD domain using the administrators credentials. One can do essentially the same thing with TKEY and get a TSIG key that can be stored. The home owner would register the machine with the router using TKEY. The credentials used would allow registration on behalf. TKEY support sending additional data in the request we only need a standard description on how to do "on behalf of". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From gettysjim@gmail.com Wed Mar 7 17:27:23 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4027521E8014 for ; Wed, 7 Mar 2012 17:27:23 -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 A8Od3k45aNom for ; Wed, 7 Mar 2012 17:27:22 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A22421E8011 for ; Wed, 7 Mar 2012 17:27:22 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so6930618vcb.31 for ; Wed, 07 Mar 2012 17:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BT1F2XXYMYVmtoM+pQuwP9Xr9v83aZ1z5iRjtU2omqo=; b=vKLG1c60+9UWJkJefZm0/kNe0nRFoBI8Xe/C7KU7qbdq0jZQwu/4mgLovzcXBWjhji WQbawBpmXEvtXZf/9T43yvjMYL/V/84Jt5yVRNmuOrvPDzptoq3aZC+VA9BMTsDIHIlM EE8mOyGGBa9qi1Jzv75c8vvSVdsSNMrPYSNEcKCmzaOJXlESXSyiciSCPe7aOStlu4qK MAu0+y3R0GzafTRLTvPN//2juQsbP9vcvaTRwOHg1GZcUu3bcai9zTgJGVeuk/D1JIYR 5Z8IxpDtTFxcGWbI9M8Q8gqc5xnKhVJMzv2YiF12DhDAA45yifbfKL+EEhMHENRfBajX mvbQ== Received: by 10.52.27.1 with SMTP id p1mr7239872vdg.17.1331170041885; Wed, 07 Mar 2012 17:27:21 -0800 (PST) Received: from [192.168.1.19] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id hf9sm275684vdb.7.2012.03.07.17.27.20 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 17:27:20 -0800 (PST) Sender: Jim Gettys Message-ID: <4F580AF7.6080508@freedesktop.org> Date: Wed, 07 Mar 2012 20:27:19 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Michael Richardson References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> In-Reply-To: <26689.1331127991@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 01:27:23 -0000 On 03/07/2012 08:46 AM, Michael Richardson wrote: >>>>>> "Mark" == Mark Andrews writes: > Mark> In message <19226.1331046945@marajade.sandelman.ca>, Michael Richardson writes: > >> >>>>> "Mark" == Mark Andrews writes: > Mark> A significant percentage of home machines will roam and those > Mark> machines will need to be able to register their current > Mark> address in the DNS. I do this today when my Mac roams. TSIG > Mark> is unavoidable and cheap. UPDATE itself is relatively cheap. > > >> Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith > >> way to do key establishment so that TSIG can be initialized? > > Mark> For homes a shared key is fine or if you want a small database of > Mark> keys. > > You didn't answer my question! I wasn't asking for justification, I was > asking for clarification of what you are proposing. > > I imagine a situation where one plugs into the homenet with your laptop. > Some application/agent on the laptop realizes (via mDNS/Bonjour? via > DCHP? TBD) that this network supports IPv6, and supports persistent > names. It asks you if you'd like to persist your name into the local > zone. It has an option to say, "make this name follow me"(%). > > There is a protocol exchange (TBD) with the designated homenet DNS > server(s), and this establishes a TSIG for later use. > Same TSIG could also be used to update the reverse map, but as you > indicate, TCP from the address you want to update is probably good > enough for addresses considered "local". > > While this might seems bit out of scope for homenet (to provide names for > laptops which are not at home), it's actually not. Depending upon how > the protocol works, it might be another way to deal with the > mDNS/Bonjour-does-not-cross-link problem. If the TSIG setup protocol > can be mediated(proxied) in a link-layer attached way, then it might be > that we do not need to make Bonjour cross links, as we can just use DNS. > > (%)-one need not have a globally reachable name. One might be > registering into .homenet/.lan/.local. This may be for the > benefit of machines which are still at home, and which need to > find your laptop. Or the home user might have a global DNS > name. The difference is really just a matter of NS/DS records. > > BTW, it appears Dave Taht has mDNS forwarding working between networks in CeroWrt using Avah; but we need to do more testing. I don't think that is the only place where we may have such issues; SNMP comes to mind, but I don't know how commonly that is used in home environments. - Jim From fred@cisco.com Wed Mar 7 22:29:13 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F6121F8698 for ; Wed, 7 Mar 2012 22:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.78 X-Spam-Level: X-Spam-Status: No, score=-108.78 tagged_above=-999 required=5 tests=[AWL=1.775, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Rcy3jtTXjpvy for ; Wed, 7 Mar 2012 22:29:13 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E52AB21F8693 for ; Wed, 7 Mar 2012 22:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=187; q=dns/txt; s=iport; t=1331188153; x=1332397753; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=xWeff3nOh8b0PmqZdCQsjCysKSPFlT0FESzAG9sWVlw=; b=ZsFSUXIKJqIQpFHOEKnBRL/r92Z6Xfk3ONJMGHS7CNevenz0Eh2YYMUM qBn8oP3PL3FCnbw5dRU9K2XBM6IYWHNMV3g298kr2tu1Zq3IgL+X7ZuR1 RoShgUAsfz+JnrEzPgeU647gBEVRvHHaTJVatLrxXLJ9Ac+7egzSO1wXx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEIAFlRWE+rRDoG/2dsb2JhbABDJrUFgQeCIwEnP4Fzh2WbAQGfFI1Mgj9jBIhQjHGFZIozgnI X-IronPort-AV: E=Sophos;i="4.73,550,1325462400"; d="scan'208";a="35101498" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 08 Mar 2012 06:29:12 +0000 Received: from Freds-Computer.local (tky-vpn-client-231-56.cisco.com [10.70.231.56]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q286TBaC021953; Thu, 8 Mar 2012 06:29:12 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 08 Mar 2012 15:29:12 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 08 Mar 2012 15:29:12 +0900 From: Fred Baker Date: Thu, 8 Mar 2012 12:27:03 +0900 Message-Id: To: homenet-chairs@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: [homenet] draft-baker-homenet-prefix-assignment-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:29:14 -0000 I have updated this. The principle changes are a pass through a spell = checker and removal of the proposed RA option, as discussed re -00. May = have further discussion if you wish.= From mcr@sandelman.ca Thu Mar 8 08:57:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6863021F8622 for ; Thu, 8 Mar 2012 08:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.68 X-Spam-Level: X-Spam-Status: No, score=-0.68 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_20=-0.74, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 xsEBj6gXh-rN for ; Thu, 8 Mar 2012 08:57:17 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 933D421F861B for ; Thu, 8 Mar 2012 08:57:17 -0800 (PST) Received: from marajade.sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id B3E86344BF; Thu, 8 Mar 2012 11:54:44 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 46FB798182; Thu, 8 Mar 2012 11:57:15 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 3C8DA9802A; Thu, 8 Mar 2012 11:57:15 -0500 (EST) From: Michael Richardson To: Jim Gettys In-Reply-To: <4F580AF7.6080508@freedesktop.org> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> <4F580AF7.6080508@freedesktop.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 08 Mar 2012 11:57:15 -0500 Message-ID: <30333.1331225835@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "homenet@ietf.org" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:57:18 -0000 >>>>> "Jim" == Jim Gettys writes: >> (%)-one need not have a globally reachable name. One might be >> registering into .homenet/.lan/.local. This may be for the >> benefit of machines which are still at home, and which need to >> find your laptop. Or the home user might have a global DNS >> name. The difference is really just a matter of NS/DS records. Jim> BTW, it appears Dave Taht has mDNS forwarding working between Jim> networks in CeroWrt using Avah; but we need to do more testing. so, basically it's just a proxy? Jim> I don't think that is the only place where we may have such Jim> issues; SNMP comes to mind, but I don't know how commonly that Jim> is used in home environments. - Jim SNMP is unused in home networks. I don't know why there is any issue with SNMP though. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From dave.taht@gmail.com Thu Mar 8 09:07:46 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D3821F8639 for ; Thu, 8 Mar 2012 09:07:46 -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=[AWL=0.000, 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 xnvKXCLLm4C0 for ; Thu, 8 Mar 2012 09:07:45 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1080421F8669 for ; Thu, 8 Mar 2012 09:07:44 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so482025wgb.13 for ; Thu, 08 Mar 2012 09:07:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jn4SJJ3W3hgI/6kIOK1fN/DIGFZOOUvMnW228NCnMY8=; b=JqJ/S9Y+adndS+XeLzO40Jj1x4QxGEkgy2YMLfGt5gMLNZizahz9gKa1aKOtzuerjF 1ZkEvVpILKG7VJb74Y98QZ5lOik53CstaUkY1zvIH8EkEP56YWc05bUp3kyJx44+QsHk pw7uJfonVdCgP22csKaesUKxrRYip8lo0dZci5N3wwJSnDoOBvyShkStU2dlTEyeWVpX I+v670mXp9yfMHMRuPKF2lJQpLVSPLfba834yAzKwLcDuLdNv0OB6Y1YykeCgukkNrtM 9DSC8Jp/OloevxOzbMAwhxv7/LJgjpwsYzfC7xrL0wWVqNywtBfkHFRa7G9PGmjGBqaT fZzQ== MIME-Version: 1.0 Received: by 10.180.91.10 with SMTP id ca10mr8221065wib.17.1331226463310; Thu, 08 Mar 2012 09:07:43 -0800 (PST) Received: by 10.223.151.8 with HTTP; Thu, 8 Mar 2012 09:07:43 -0800 (PST) In-Reply-To: <30333.1331225835@marajade.sandelman.ca> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> <4F580AF7.6080508@freedesktop.org> <30333.1331225835@marajade.sandelman.ca> Date: Thu, 8 Mar 2012 17:07:43 +0000 Message-ID: From: Dave Taht To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org" , Jim Gettys Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:07:46 -0000 On Thu, Mar 8, 2012 at 4:57 PM, Michael Richardson wrote= : > > > >>>>> "Jim" =3D=3D Jim Gettys writes: > =A0 =A0>> (%)-one need not have a globally reachable name. =A0One might b= e > =A0 =A0>> registering into .homenet/.lan/.local. =A0This may be for the > =A0 =A0>> benefit of machines which are still at home, and which need to > =A0 =A0>> find your laptop. =A0Or the home user might have a global DNS > =A0 =A0>> name. The difference is really just a matter of NS/DS records. > > =A0 =A0Jim> BTW, it appears Dave Taht has mDNS forwarding working between > =A0 =A0Jim> networks in CeroWrt using Avah; but we need to do more testin= g. > > so, basically it's just a proxy? =A0yes. they call it a 'reflector'. From avaha-daemon's man page Section [reflector] enable-reflector=3D Takes a boolean value ("yes" or "no"). If set to "yes" avahi-daemon will reflect incoming mDNS requests to all local network interfaces, effectively allowing clients to browse mDNS/DNS-SD services on all networks connected to the gateway. The gateway is somewhat intelligent and should work with all kinds of mDNS traffic, though some functionality is lost (specifically the unicast reply bit, which is used rarely anyway). Make sure to not run multiple reflectors between the same networks, this might cause them to play Ping Pong with mDNS packets. Defaults to "no". reflect-ipv=3D Takes a boolean value ("yes" or "no"). If set to "yes" and enable-reflector is enabled, avahi-daemon will forward mDNS traffic between IPv4 and IPv6, which is usually not recommended. Defaults to "no". ... there are other problems with the mdns spec, notably the TTL figure is fixed, making routing problematic, even if multicast routing worked worth beans. > > =A0 =A0Jim> I don't think that is the only place where we may have such > =A0 =A0Jim> issues; SNMP comes to mind, but I don't know how commonly tha= t > =A0 =A0Jim> is used in home environments. =A0- Jim > > SNMP is unused in home networks. > I don't know why there is any issue with SNMP though. > The elephant in the room is that we no longer have E2E connectivity in much of the world, so centralized polling utilities such as those that use snmp, can't work through the multiple layers of NAT. The edge has gone dark. I wouldn't claim that snmp is unused in home networks, but it is sorely underused, as the relevant monitoring utilities are complex to setup and maintain. I've been explicitly enabling snmp over ipv6, I note, and using tools such as those available from 'dartware' -- Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net From dave.taht@gmail.com Thu Mar 8 09:12:47 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88B121F864E for ; Thu, 8 Mar 2012 09:12:47 -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 Lvki2K1rURkD for ; Thu, 8 Mar 2012 09:12:47 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96F6321F8646 for ; Thu, 8 Mar 2012 09:12:46 -0800 (PST) Received: by wicr5 with SMTP id r5so587950wic.31 for ; Thu, 08 Mar 2012 09:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2enekYDT42x5IPQ7+NhG11zOIaYYCzn/qfAbgIYKCB8=; b=ntXsTX+4ezqh2QFt1zYTqVqG+AF8c/BC8RdFAw7K2Ih6D0SGqJdvA3s3LykNbOXzSa TOeFAWFgQPXK775ogwVI8uyjm/NCNBAwKb9d+uGJ7oDXyCrrBGYL36kQtOZP6uSVJ3GS I7+6RZtUlcudU8IHc131yDX/aZdCgyzNd38N+uXToT9n2Vu/dMHespHIwoo94Rdrwio9 eCkw13CdAVpnEIPKEsfZvOVhP14iWTt2dmq3SZrKOW04/gq831mHV2BWDSeN7K1F3JUR RCG9WA+YpIqbaM4sCbig72MPALJkhoa6asm4kdp1sQU66yRQ1Q1LggNY/J85mK1IjaPf AuoA== MIME-Version: 1.0 Received: by 10.180.93.232 with SMTP id cx8mr37088856wib.14.1331226765671; Thu, 08 Mar 2012 09:12:45 -0800 (PST) Received: by 10.223.151.8 with HTTP; Thu, 8 Mar 2012 09:12:45 -0800 (PST) In-Reply-To: <20120308012011.1E4221E28C02@drugs.dv.isc.org> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> <20120308012011.1E4221E28C02@drugs.dv.isc.org> Date: Thu, 8 Mar 2012 17:12:45 +0000 Message-ID: From: Dave Taht To: Mark Andrews Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:12:48 -0000 On Thu, Mar 8, 2012 at 1:20 AM, Mark Andrews wrote: > > In message <26689.1331127991@marajade.sandelman.ca>, Michael Richardson w= rites: >> >>>>> "Mark" =3D3D=3D3D Mark Andrews writes: >> =A0 =A0 Mark> In message <19226.1331046945@marajade.sandelman.ca>, Micha= el Rich=3D >> ardson writes: >> =A0 =A0 >> >>>>> "Mark" =3D3D=3D3D Mark Andrews writes: >> =A0 =A0 Mark> A significant percentage of home machines will roam and th= ose >> =A0 =A0 Mark> machines will need to be able to register their current >> =A0 =A0 Mark> address in the DNS. =A0I do this today when my Mac roams. = =A0TSIG >> =A0 =A0 Mark> is unavoidable and cheap. =A0UPDATE itself is relatively c= heap. >> >> =A0 =A0 >> Are you asking for a link-local/mDNS-across-the-homenet leap-= of-faith >> =A0 =A0 >> way to do key establishment so that TSIG can be initialized? >> >> =A0 =A0 Mark> For homes a shared key is fine or if you want a small data= base of >> =A0 =A0 Mark> keys. >> >> You didn't answer my question! =A0I wasn't asking for justification, I w= as >> asking for clarification of what you are proposing. > > Ok. Lets look at a working model that Microsoft has with AD. =A0You boot > the machine them a Adminstrator adds the machine to the AD domain using > the administrators credentials. > > One can do essentially the same thing with TKEY and get a TSIG key > that can be stored. =A0The home owner would register the machine with > the router using TKEY. =A0The credentials used would allow registration > on behalf. =A0TKEY support sending additional data in the request we > only need a standard description on how to do "on behalf of". An implementation problem is that the 'publishable' quality is not representable with things like bind9. Bind9 supports 'views', and in my case, I have a 'us' (for inside the network) and 'them' view (for everybody else). Inside the network, machines generally have rfc1918 addresses and ipv6 addresses, and outside, only ipv6 addresses. So you need to update both views/databases in order to have a consistent namespace. You don't want to leak the rfc1918 addresses to the outside world, but you (probably) want to make your ipv6 addresses available both inside and outside. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= c.org > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net From mcr@sandelman.ca Thu Mar 8 11:59:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47C521E802D for ; Thu, 8 Mar 2012 11:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 0FbeUoO2q0iM for ; Thu, 8 Mar 2012 11:59:41 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACF721E802B for ; Thu, 8 Mar 2012 11:59:40 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id C18F0344D4; Thu, 8 Mar 2012 14:57:07 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 057E098281; Thu, 8 Mar 2012 14:59:38 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id ED3E69827F; Thu, 8 Mar 2012 14:59:38 -0500 (EST) From: Michael Richardson To: Mark Andrews In-Reply-To: <20120308012011.1E4221E28C02@drugs.dv.isc.org> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> <20120308012011.1E4221E28C02@drugs.dv.isc.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 08 Mar 2012 14:59:38 -0500 Message-ID: <26134.1331236778@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:59:41 -0000 >>>>> "Mark" == Mark Andrews writes: >> You didn't answer my question! I wasn't asking for >> justification, I was asking for clarification of what you are >> proposing. ... Mark> One can do essentially the same thing with TKEY and get a TSIG Mark> key that can be stored. The home owner would register the Mark> machine with the router using TKEY. The credentials used Mark> would allow registration on behalf. TKEY support sending Mark> additional data in the request we only need a standard Mark> description on how to do "on behalf of". So, we need no additional protocol, we just need a DHCP option to tell the host that where this service is available. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Thu Mar 8 12:31:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDF021F84CD for ; Thu, 8 Mar 2012 12:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 lru4mXUTSAHi for ; Thu, 8 Mar 2012 12:31:16 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0B23D21F84C9 for ; Thu, 8 Mar 2012 12:31:16 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 9D635344DA; Thu, 8 Mar 2012 15:28:43 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id F062A98282; Thu, 8 Mar 2012 15:31:14 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id EA93398281; Thu, 8 Mar 2012 15:31:14 -0500 (EST) From: Michael Richardson To: Dave Taht In-Reply-To: References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> <4F580AF7.6080508@freedesktop.org> <30333.1331225835@marajade.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 08 Mar 2012 15:31:14 -0500 Message-ID: <32078.1331238674@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "homenet@ietf.org" , Jim Gettys Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:31:16 -0000 >>>>> "Dave" == Dave Taht writes: Dave> which is used rarely anyway). Make sure to not run multiple reflectors Dave> between the same networks, this might cause them to play Ping Pong Dave> with mDNS packets. Defaults to "no". reflect-ipv= Takes a Dave> boolean In other words, don't have a loop. homenet has assumed loops. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Thu Mar 8 12:34:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FD721E8046 for ; Thu, 8 Mar 2012 12:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 Dt591G+SShRM for ; Thu, 8 Mar 2012 12:34:10 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 099FD21E801C for ; Thu, 8 Mar 2012 12:34:05 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id BFEF1344C8; Thu, 8 Mar 2012 15:31:32 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2964498282; Thu, 8 Mar 2012 15:34:00 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 2284D98281; Thu, 8 Mar 2012 15:34:00 -0500 (EST) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> <4F580AF7.6080508@freedesktop.org> <30333.1331225835@marajade.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Thu, 08 Mar 2012 15:34:00 -0500 Message-ID: <32595.1331238840@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: dave.taht@gmail.com Subject: [homenet] snmp for monitoring home network X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:34:11 -0000 >>>>> "Dave" =3D=3D Dave Taht writes: >>=20 >> =A0 =A0Jim> I don't think that is the only place where we may have s= uch >> =A0 =A0Jim> issues; SNMP comes to mind, but I don't know how commonl= y that >> =A0 =A0Jim> is used in home environments. =A0- Jim >>=20 >> SNMP is unused in home networks. >> I don't know why there is any issue with SNMP though. >>=20 Dave> The elephant in the room is that we no longer have E2E connectivi= ty in Dave> much of the world, so centralized polling utilities Dave> such as those that use snmp, can't work through the multiple laye= rs of NAT. Dave> The edge has gone dark. I think the edge never had any light :-) Dave> I wouldn't claim that snmp is unused in home networks, but it is Dave> sorely underused, as the relevant monitoring utilities are comple= x to Dave> setup and maintain. Dave> I've been explicitly enabling snmp over ipv6, I note, and using t= ools Dave> such as those available from 'dartware' I agree --- I've put IPv6 (non-connected networks) into a number of data centre operations specifically so that I could use SNMP. I am not familiar with dartware... is it: http://www.intermapper.com/ I think that E2E into the home for SNMP is perhaps one of the things that would motivate an ISP to support homenet. --=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 From gettysjim@gmail.com Thu Mar 8 14:33:01 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018F421F843C for ; Thu, 8 Mar 2012 14:33:01 -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 p3Js+lpsuvGp for ; Thu, 8 Mar 2012 14:33:00 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF7A21F8433 for ; Thu, 8 Mar 2012 14:32:57 -0800 (PST) Received: by vbbez10 with SMTP id ez10so992400vbb.31 for ; Thu, 08 Mar 2012 14:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=K3+V2OHas6ETrJodnSWfSSj3PvsgMBAGsqy1LfjnERM=; b=wMyMhMl3Wh1SrSga8ht+nd9qlyDCFCHSMTrvb5nN/2zUdInbEQbZzN1CnP7300JS9X j93kIB2rMq+QWx2AssWEyxwhN807wAyd/KwCHKMB+5Wmrb9j2ZbETCyVR7+SNZw/LKD2 m73HrV0l9eGqET5Ve8MOxwH9ycPa0GrAZ1MZXHJnzBmflCyouhFzWyhqm3EJ3pc+vscb UQGkSlArZYgJw/Acx8xvHeEbhkh5VaaKM2HO1O/4oTxvxtulMdk40dAMCh/DlDcuvJQc zbh5FfyD4EFIQktrsJkMc1PGArt4nKaKHgl8JnA4sacmDc9qq44wIJI5Px41xsx4SqT7 /P6Q== Received: by 10.52.24.233 with SMTP id x9mr12782367vdf.116.1331245976842; Thu, 08 Mar 2012 14:32:56 -0800 (PST) Received: from [172.30.42.80] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id ht6sm6400921vdb.8.2012.03.08.14.32.55 (version=SSLv3 cipher=OTHER); Thu, 08 Mar 2012 14:32:55 -0800 (PST) Sender: Jim Gettys Message-ID: <4F593396.6010108@freedesktop.org> Date: Thu, 08 Mar 2012 17:32:54 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Michael Richardson References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> <4F580AF7.6080508@freedesktop.org> <30333.1331225835@marajade.sandelman.ca> <32595.1331238840@marajade.sandelman.ca> In-Reply-To: <32595.1331238840@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" , dave.taht@gmail.com Subject: Re: [homenet] snmp for monitoring home network X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 22:33:01 -0000 On 03/08/2012 03:34 PM, Michael Richardson wrote: >>>>>> "Dave" == Dave Taht writes: > >> > >> Jim> I don't think that is the only place where we may have such > >> Jim> issues; SNMP comes to mind, but I don't know how commonly that > >> Jim> is used in home environments. - Jim > >> > >> SNMP is unused in home networks. > >> I don't know why there is any issue with SNMP though. > >> > > The specific worry is that when investigating why I couldn't see my home printer, I came across a reference to the use of multicast SNMP possibly being used for printer discovery. I also remember there being a IPP multicast discovery "feature". Again, I don't know if either of these are used much in practice, whereas we know mDNS is used quite a lot. It is wiggling worms like these that make me so convinced that "running code" is the only way to find out what can actually be deployed. - Jim From marka@isc.org Thu Mar 8 14:50:24 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F1A21F865B for ; Thu, 8 Mar 2012 14:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=-1.473, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, MANGLED_CHEAP=2.3] 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 O1ZpQWrCOk-F for ; Thu, 8 Mar 2012 14:50:23 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id F164E21F8659 for ; Thu, 8 Mar 2012 14:50:22 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id D30E45F98AF; Thu, 8 Mar 2012 22:50:05 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5df4:2bae:698c:ea04]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 64101216C31; Thu, 8 Mar 2012 22:50:03 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 6A52C1E3463C; Fri, 9 Mar 2012 09:49:57 +1100 (EST) To: Dave Taht From: Mark Andrews References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> <20120308012011.1E4221E28C02@drugs.dv.isc.org> In-reply-to: Your message of "Thu, 08 Mar 2012 17:12:45 -0000." Date: Fri, 09 Mar 2012 09:49:56 +1100 Message-Id: <20120308224957.6A52C1E3463C@drugs.dv.isc.org> Cc: "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 22:50:24 -0000 In message , Dave Taht writes: > On Thu, Mar 8, 2012 at 1:20 AM, Mark Andrews wrote: > > > > In message <26689.1331127991@marajade.sandelman.ca>, Michael Richardson w= > rites: > >> >>>>> "Mark" =3D3D=3D3D Mark Andrews writes: > >> =A0 =A0 Mark> In message <19226.1331046945@marajade.sandelman.ca>, Micha= > el Rich=3D > >> ardson writes: > >> =A0 =A0 >> >>>>> "Mark" =3D3D=3D3D Mark Andrews writes: > >> =A0 =A0 Mark> A significant percentage of home machines will roam and th= > ose > >> =A0 =A0 Mark> machines will need to be able to register their current > >> =A0 =A0 Mark> address in the DNS. =A0I do this today when my Mac roams. = > =A0TSIG > >> =A0 =A0 Mark> is unavoidable and cheap. =A0UPDATE itself is relatively c= > heap. > >> > >> =A0 =A0 >> Are you asking for a link-local/mDNS-across-the-homenet leap-= > of-faith > >> =A0 =A0 >> way to do key establishment so that TSIG can be initialized? > >> > >> =A0 =A0 Mark> For homes a shared key is fine or if you want a small data= > base of > >> =A0 =A0 Mark> keys. > >> > >> You didn't answer my question! =A0I wasn't asking for justification, I w= > as > >> asking for clarification of what you are proposing. > > > > Ok. Lets look at a working model that Microsoft has with AD. =A0You boot > > the machine them a Adminstrator adds the machine to the AD domain using > > the administrators credentials. > > > > One can do essentially the same thing with TKEY and get a TSIG key > > that can be stored. =A0The home owner would register the machine with > > the router using TKEY. =A0The credentials used would allow registration > > on behalf. =A0TKEY support sending additional data in the request we > > only need a standard description on how to do "on behalf of". > > An implementation problem is that the 'publishable' quality is not > representable with things like bind9. Bind9 supports 'views', and in > my case, I have a 'us' (for inside the network) and 'them' view (for > everybody else). Inside the network, machines generally have rfc1918 > addresses and ipv6 addresses, and outside, only ipv6 addresses. Named already transfers in a zone, strips out any NSEC, DNSKEY, NSEC3, NSEC3PARAM and RRSIG records to get a clean unsigned zone, the signs the zone using a new set of DNSKEY records to perform inline signing. Filtering out RFC 1918 address in addition would not be a major issue, basically you would have to define a acl to determine what is filtered. Zones are transferable between views. UPDATE requests on the outside view can be forwarded to the inside view, processed, the resulting zone is transfered, filtered and signed. This requires the inside view to be a superset of the outside view. If you don't give the inline signing zone a set of DNSKEYs to work with it just serves the filtered version of the zone. > So you need to update both views/databases in order to have a > consistent namespace. You don't want to leak the rfc1918 addresses to > the outside world, but you (probably) want to make your ipv6 addresses > available both inside and outside. > > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is= > c.org > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > --=20 > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://www.bufferbloat.net -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From marka@isc.org Thu Mar 8 15:04:54 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5989A21F85F7 for ; Thu, 8 Mar 2012 15:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] 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 rw-xwUO1QQea for ; Thu, 8 Mar 2012 15:04:53 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 194A121F86AD for ; Thu, 8 Mar 2012 15:04:52 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 9C58F5F9891; Thu, 8 Mar 2012 23:04:32 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:5df4:2bae:698c:ea04]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 91C55216C33; Thu, 8 Mar 2012 23:04:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id DAF571E347A6; Fri, 9 Mar 2012 10:04:23 +1100 (EST) To: Michael Richardson From: Mark Andrews References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <5CFF9C2C-E605-400A-B76B-ACEA4ECEDA07@nominet.org.uk> <20120305222400.9B7761E120BC@drugs.dv.isc.org> <19226.1331046945@marajade.sandelman.ca> <20120306225430.52D1D1E1E29D@drugs.dv.isc.org> <26689.1331127991@marajade.sandelman.ca> <20120308012011.1E4221E28C02@drugs.dv.isc.org> <26134.1331236778@marajade.sandelman.ca> In-reply-to: Your message of "Thu, 08 Mar 2012 14:59:38 CDT." <26134.1331236778@marajade.sandelman.ca> Date: Fri, 09 Mar 2012 10:04:23 +1100 Message-Id: <20120308230423.DAF571E347A6@drugs.dv.isc.org> Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 23:04:54 -0000 In message <26134.1331236778@marajade.sandelman.ca>, Michael Richardson writes: > > >>>>> "Mark" == Mark Andrews writes: > >> You didn't answer my question! I wasn't asking for > >> justification, I was asking for clarification of what you are > >> proposing. > > ... > > Mark> One can do essentially the same thing with TKEY and get a TSIG > Mark> key that can be stored. The home owner would register the > Mark> machine with the router using TKEY. The credentials used > Mark> would allow registration on behalf. TKEY support sending > Mark> additional data in the request we only need a standard > Mark> description on how to do "on behalf of". > > So, we need no additional protocol, we just need a DHCP option to tell > the host that where this service is available. More a TKEY option. > -- > ] He who is tired of Weird Al is tired of life! | firewalls > [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architec > t[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device drive > r[ > Kyoto Plus: watch the video > then sign the petition. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From lorenzo@google.com Thu Mar 8 19:12:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1459C11E8072 for ; Thu, 8 Mar 2012 19:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.793 X-Spam-Level: X-Spam-Status: No, score=-102.793 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 FG3d2oGaH+ag for ; Thu, 8 Mar 2012 19:12:00 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1B4511E8080 for ; Thu, 8 Mar 2012 19:11:59 -0800 (PST) Received: by obbta4 with SMTP id ta4so1714222obb.31 for ; Thu, 08 Mar 2012 19:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=uX7+YkLBYD7V38Rj+VStHTfGKMw/o5jGH7bCfKFjmaM=; b=eYyktcCI5ZMx44x9DHeiSebgmt08/E7uSyJCV3wgmb3gMVZj0xAx0EsvgfI0kBfpwv eJ0NTASM+m+yn9BMJyYdasM/tiCjYTPnOW31OaAPZWuMUxjUp4+RTdgeTE4VADeli/j+ RX6XAl92efmv6Vi7397AMwrP551KbNcBFbUinw+zko2QIY1Y6WYng6TUkR8Og5yeTN2c F35WuRlFqnZkTF7ggIW4KwABwc05Oq7GI6mD37PDxGEvldqXnZy/xSyWmvwkMr3k4qjX 9ZFiE8MLflQ4tKaQymLwvIb5vMIbmT/oe7zZSUCS/L9kM0MS5FQKvmUHEgA+vu/1O8FE OSqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=uX7+YkLBYD7V38Rj+VStHTfGKMw/o5jGH7bCfKFjmaM=; b=mFnFYHFFXLDDEyaWXAU85TLZVSb96vp/9o8ZV1yT/zh9p52zujbfKjb3niTm4+ZjkX 52s5neitOEvUEsIva3Z8t+eXuXN8UKBEW9O0aEzTpHlV3QpiJNutl1yJw6W3Xwxkql/t JevNZG0ZFvm3XvpqYDOEGH/ZGr4siXCpc20Tj4yW00RW9/pm+U1n1gBoZ9t2DjgG3QBc 1Yy4MGmsyLDHj75EA36i9fSR4/D1QgthEjuVolcD9AAt6scEWmb6T2XRkUtVxbUVavbx sPLLgh0KBkLJUO2C0oSianQW9R11+VA+IjI/WXap7Ml0xDBVq0brwgkzOdt9QE6QSO0l Vmmg== Received: by 10.182.216.41 with SMTP id on9mr268401obc.18.1331262719581; Thu, 08 Mar 2012 19:11:59 -0800 (PST) Received: by 10.182.216.41 with SMTP id on9mr268395obc.18.1331262719475; Thu, 08 Mar 2012 19:11:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.5.67 with HTTP; Thu, 8 Mar 2012 19:11:39 -0800 (PST) In-Reply-To: <7796.1330985113@marajade.sandelman.ca> References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <7796.1330985113@marajade.sandelman.ca> From: Lorenzo Colitti Date: Fri, 9 Mar 2012 12:11:39 +0900 Message-ID: To: Michael Richardson Content-Type: multipart/alternative; boundary=f46d04478a7f7f3e1104bac6c1d9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnVJKK/Ov50Fbjv8++k5Zh2a/q28BtxcR2wsokZ8NKu2Ma+W6uTGmkFrS6X+sAFCb4VVa7q0ENa8ACJRpf9xN9WEYuYZNK1J+uxi7aGc1qPoWEVFSTZ+/fsWabpQsDRcw+YFumn Cc: homenet@ietf.org Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 03:12:05 -0000 --f46d04478a7f7f3e1104bac6c1d9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 6, 2012 at 07:05, Michael Richardson wrote: > > In the DNS space, I would like the WG to declare the name-based > selection of DNS servers (what some want to do for walled gardens) > should be ruled harmful. > > If some walled garden wants the name->AAAA mapping private, then > just restrict queries to source addresses within the walled garden. > If necessary, add level of NS record. > And do what in response to queries for that name coming from outside the walled garden? Return REFUSED? Return NXDOMAIN? Drop the query? None of these works, I think. --f46d04478a7f7f3e1104bac6c1d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 6, 2012 at 07:05, Michael Richardson= <mcr@sandelman.ca= > wrote:
In the DNS space, I would like the WG to declare the name-based
selection of DNS servers (what some want to do for walled gardens)
should be ruled harmful.

If some walled garden wants the name->AAAA mapping private, then
just restrict queries to source addresses within the walled garden.
If necessary, add level of NS record.

A= nd do what in response to queries for that name coming from outside the wal= led garden? Return REFUSED? Return NXDOMAIN? Drop the query?=A0None of thes= e works, I think.
--f46d04478a7f7f3e1104bac6c1d9-- From jason_livingood@cable.comcast.com Thu Mar 8 20:42:10 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A1E21F8505 for ; Thu, 8 Mar 2012 20:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=-2.356, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 T5QXNH4rXllG for ; Thu, 8 Mar 2012 20:42:10 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 1526921F8501 for ; Thu, 8 Mar 2012 20:42:10 -0800 (PST) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.8574010; Thu, 08 Mar 2012 21:30:51 -0700 Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 23:42:06 -0500 From: "Livingood, Jason" To: Michael Richardson , "homenet@ietf.org" Thread-Topic: [homenet] snmp for monitoring home network Thread-Index: AQHM/WrVyyGB9iFTM0myXkFhZD8EsZZhYyGA Date: Fri, 9 Mar 2012 04:42:02 +0000 Message-ID: In-Reply-To: <32595.1331238840@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [147.191.125.11] Content-Type: multipart/alternative; boundary="_000_CB7EF2F553E28jasonlivingoodcablecomcastcom_" MIME-Version: 1.0 Cc: Dave Taht Subject: Re: [homenet] snmp for monitoring home network X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:42:10 -0000 --_000_CB7EF2F553E28jasonlivingoodcablecomcastcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that E2E into the home for SNMP is perhaps one of the things that w= ould motivate an ISP to support homenet. E2E network management and/or monitoring, yes. SNMP, at least on a public i= nterface, maybe not so much. We may be entering a phase where ISPs consider= blocking TCP/UDP 161. The reason is that SNMP is becoming more and more widely abused. I still ha= ve no idea why for example (1) some gear ships with public as the default s= tring and the daemon running by default as such, (2) some gear does not pre= sent the user with an interface to turn off SNMP or change the community st= ring at all (so you may be stuck with on/public). So maybe on SNMP, tread carefully. ;-) Jason --_000_CB7EF2F553E28jasonlivingoodcablecomcastcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <6BC96E9CD7FD384C9452A9DB9A639FE1@cable.comcast.com> Content-Transfer-Encoding: quoted-printable
I think t= hat E2E into the home for SNMP is perhaps one of the things that would motiva= te an ISP to support homenet.

E2E network management and/or monitoring, yes. SNMP, at least on = a public interface, maybe not so much. We may be entering a phase where ISP= s consider blocking TCP/UDP 161.  

The reason is that SNMP is becoming more and more widely abused. I sti= ll have no idea why for example (1) some gear ships with public as the defa= ult string and the daemon running by default as such, (2) some gear does no= t present the user with an interface to turn off SNMP or change the community string at all (so you may be stuc= k with on/public). 

So maybe on SNMP, tread carefully. ;-)

Jason
--_000_CB7EF2F553E28jasonlivingoodcablecomcastcom_-- From mcr@sandelman.ca Fri Mar 9 06:19:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F521F85FC for ; Fri, 9 Mar 2012 06:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 R89-S3kosG+s for ; Fri, 9 Mar 2012 06:19:15 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id EE96D21F84B6 for ; Fri, 9 Mar 2012 06:19:02 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 85B08344D6 for ; Fri, 9 Mar 2012 09:16:27 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 3359C98282; Fri, 9 Mar 2012 09:18:59 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 2EAFE98281 for ; Fri, 9 Mar 2012 09:18:59 -0500 (EST) From: Michael Richardson To: homenet@ietf.org In-Reply-To: References: <7355.1327954105@marajade.sandelman.ca> <20120302.202125.48495135.fujiwara@jprs.co.jp> <000118C4-3ABA-47D0-BDF6-69E59EF1C630@nominet.org.uk> <20120306.001533.653026525707348379.fujiwara@wide.ad.jp> <7796.1330985113@marajade.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 09 Mar 2012 09:18:59 -0500 Message-ID: <31414.1331302739@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Home DNS server for homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:19:16 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Lorenzo" =3D=3D Lorenzo Colitti writes: >> In the DNS space, I would like the WG to declare the name-based >> selection of DNS servers (what some want to do for walled gardens) >> should be ruled harmful. >> If some walled garden wants the name->AAAA mapping private, then >> just restrict queries to source addresses within the walled garden. >> If necessary, add level of NS record. Lorenzo> And do what in response to queries for that name coming Lorenzo> from outside the=20 Lorenzo> walled garden? Return REFUSED? Return NXDOMAIN? Drop the Lorenzo> query? None of=20 Lorenzo> these works, I think. 1) if you use an extra level of NS, then whomever asks for the AAAA will get a timeout. By this, I mean: public example.com ns: walled.example.com IN NS ns.walled.example.com. ns.walled.example.com IN AAAA 4000:dead:beef::1 (Let's assume that walled-gardens get clear Non-Connected Network allocation in 4000:/3, but it works fine with 2000:/3 space which is either un-advertised or firewalled) private walled.example.com ns: coolserver.walled.example.com IN AAAA 4000:dead:beef::2 If you ask from within the walled garden, then you can talk to the 4000:dead:beef:/48 network (and you do so from your 4000:/3 address), so you get an answer. If you ask from without, you get a timeout. So even the name of the service is hidden, which is what I'm told the providers want. 2) if you do not use this extra level, but have a name server which the world can reach, then you can return whatever value you want. You can return a different AAAA too if you want. But, tell how is this any different than what I'm told they originally wanted, which is that we'd have: if($domain =3D~ /.*somesuffice.com$/) { $ns =3D $walledgardendns; } in applications and stub resolvers? If you aren't in the walled garden, what would the application do when $walledgardenns is not reachable? =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT1oRU4qHRg3pndX9AQJe3gP/XcUXnpkX3S/zH0ef3FvO8B673WHkuBxl 23oHn5D7DYP6hz1vtQQ/UnfncAtMBSwt5jdfS7f35f/860ftJV+LJ25lnEY7DGRZ M9Hsm05c7gxoLQd6SKPWO5ExPelMJ9KOz8WcQMa8uptIs8FXmgrTa5RrGFfDubsn beJptg5Lzzg= =f6FT -----END PGP SIGNATURE----- --=-=-=-- From gettysjim@gmail.com Fri Mar 9 06:38:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CACE21F84E1 for ; Fri, 9 Mar 2012 06:38:51 -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 Kbwfd8DWPL50 for ; Fri, 9 Mar 2012 06:38:51 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E120521F84D6 for ; Fri, 9 Mar 2012 06:38:50 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1650776vcb.31 for ; Fri, 09 Mar 2012 06:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RZ0JHaou3azCuYMFi+OPEEaDvf7pHGEMwwxSziwu5ic=; b=JBmEI57yAX3NGY5QDiB5JD4hpSYR/A3o6e1ZS1c4orIGttJAryvpHqGzO/WV3g/9I5 Kzf35sjftiwNA7Vcx9Qxkh9JE+xL7bFe6IMmNDaDtTbqFtY3vpVNWdXgn+u5W5UIQe8c u698d68jiwehtds/JvYDEbA/6Y9/Qw1ywLl94oe/Ew6s/mBxCorYpepcAUAgRAYplRR1 hZnvCsJIUob+t/2C/M/nN6ImBPpmvwL5vBx3Agc+yfhSN5PycYaVfR5IS8g31rViCCIN 9A+LNHZciewkRNpD2SmHt5WohTrqpRzTnIjIvdxu57VoHnqyiiFQ6Q55swpcboS4Nd3N 85Wg== Received: by 10.52.155.173 with SMTP id vx13mr2096381vdb.88.1331303930366; Fri, 09 Mar 2012 06:38:50 -0800 (PST) Received: from [192.168.1.24] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id jr10sm10937660vdb.14.2012.03.09.06.38.48 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 06:38:48 -0800 (PST) Sender: Jim Gettys Message-ID: <4F5A15F7.5000501@freedesktop.org> Date: Fri, 09 Mar 2012 09:38:47 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Livingood, Jason" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" , Michael Richardson , Dave Taht Subject: Re: [homenet] snmp for monitoring home network X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:38:51 -0000 On 03/08/2012 11:42 PM, Livingood, Jason wrote: > > I think that E2E into the home for SNMP is perhaps one of the > things that would motivate an ISP to support homenet. > > > E2E network management and/or monitoring, yes. SNMP, at least on a > public interface, maybe not so much. We may be entering a phase where > ISPs consider blocking TCP/UDP 161. > > The reason is that SNMP is becoming more and more widely abused. I > still have no idea why for example (1) some gear ships with public as > the default string and the daemon running by default as such, (2) some > gear does not present the user with an interface to turn off SNMP or > change the community string at all (so you may be stuck with on/public). > > So maybe on SNMP, tread carefully. ;-) > Just to make it clear, I was worrying about the possible use of multicast to *discover* SNMP devices, and routing versus bridging where the multicast packet might need forwarding to other networks in the hime, not SNMP in general. I had noted its possible use to *discover* printers to initially configure them. - Jim From ietfdbh@comcast.net Fri Mar 9 07:23:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27DD21F868A for ; Fri, 9 Mar 2012 07:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.535 X-Spam-Level: X-Spam-Status: No, score=-101.535 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] 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 ZQbYRifTZCPX for ; Fri, 9 Mar 2012 07:23:12 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0A10421F86AB for ; Fri, 9 Mar 2012 07:23:11 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta05.westchester.pa.mail.comcast.net with comcast id jS0P1i00627AodY55TPCdp; Fri, 09 Mar 2012 15:23:12 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta19.westchester.pa.mail.comcast.net with comcast id jTNu1i02e3Ecudz3fTP2fM; Fri, 09 Mar 2012 15:23:12 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 09 Mar 2012 10:22:52 -0500 From: David Harrington To: "Livingood, Jason" , Michael Richardson , "homenet@ietf.org" Message-ID: Thread-Topic: [homenet] snmp for monitoring home network In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3414133391_43180165" Cc: Dave Taht Subject: Re: [homenet] snmp for monitoring home network X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 15:23:16 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3414133391_43180165 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, I am not promoting (nor discouraging) SNMP for home networks, but if you're going to discuss it, let me just make sure the WG understands some of the features of SNMP designed to be relevant to an IT department managing a hom= e network remotely (and other cross-admin domain use cases). You want to avoid SNMPv1 and SNMPv2 over an untrusted network, because they have only minimal security based on a shared password passed in cleartext i= n every message =AD a community string. The IETF has declared SNMPv1 and SNMPv2 Historic and NOT RECOMMENDED, so certainly you should not write any recommendations for their use in homenet= . SNMP is a protocol designed to carry MIB information. That separation of message from content is critically important, to enable protocols other tha= n SNMP to also carry MIB information. If most end users do not use SNMPv1 because **MIB-based management** is too complex and user-unfriendly for home use, SNMPv3 will not solve that problem. It uses the same MIB. SNMPv1 is quite easy to configure =AD you just point it at an address and giv= e it the right community string. SNMPv3 was designed to be secure, and has lots of security setup that would baffle most home users. However, IT departments wanting SNMP to reach into the home could consider SNMPv3. SNMPv3 offers authentication using negotiated methods - its own security, SSH and TLS. (all IETF standards). It offers authorization on a per-user-session basis using RADIUS, tied into SSH and/or TLS. While SNMPv1 and SNMPv3 both run over ports 161/162, SNMPv3 can distinguish whether the authentication is done using community strings, SSH, TLS or the SNMPv3 built-in security, and allow/deny accordingly. SNMPv3 supports security fallback =AD e.g., if the network is flaky and you cannot reach a CA, it can fall back to using the built-in SNMP security. SNMPv3 offers MIB database access control (who can perform what operations on which information) Access control uses a tree-based approach, much like many graphical backup applications; this allows policies to be defined, for example, at the everything, the MIB module level, table level, or the object-level. Access can be dynamically configured by using RADIUS to assign a user to a predefined access policy (e.g., engineering vs accounting, Boston vs San Jose, home vs in-office, help-desk vs routing-admin, and so on). The authentication/authorization/MIB access control can be used to allow users to manage certain aspects of their network, such as device discovery and fault monitoring and host resources (RFC2790), while also allowing an ISP to manage aspects of the home network. SNMPv3 provides agents with a global identifier independent of their curren= t address. This was designed specifically to handle dynamically-changing addresses, such as from DHCP and NAT, or recognizing that a single agent is using multiple interfaces with different addresses (important for correlating the data received via multiple addresses for the same agent). There is an SNMP proxy-mib that provides a message-header rewrite (but not payload) between security approaches. The proxy-mib can be used for proxying between SNMPv1 and SNMPv3 security. For example, SNMPv1 can be used managing a trusted internal network or a network with no SNMPv3 support, like a homenet, and then proxy to SNMPv3 fo= r carrying the data over an untrusted network like the Internet. If no proxy rule applies, the message gets dropped, like a firewall. In a NAT environment, or other environment that uses aggregation, you may o= r may not want an ALG to do address translation in the payload. If you are looking at a server farm, some uses might be better served by seeing this as one abstract aggregation; For performance and fault monitoring, you migh= t want to look at each individual server. See RFC2962. I hope this helps provide more detail about relevant aspects of SNMP for home networks. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 From: Jason Livingood Date: Fri, 9 Mar 2012 04:42:02 +0000 To: Michael Richardson , "homenet@ietf.org" Cc: Dave Taht Subject: Re: [homenet] snmp for monitoring home network > I think that E2E into the home for SNMP is perhaps one of the things that > would motivate an ISP to support homenet. E2E network management and/or monitoring, yes. SNMP, at least on a public interface, maybe not so much. We may be entering a phase where ISPs conside= r blocking TCP/UDP 161. The reason is that SNMP is becoming more and more widely abused. I still have no idea why for example (1) some gear ships with public as the default string and the daemon running by default as such, (2) some gear does not present the user with an interface to turn off SNMP or change the community string at all (so you may be stuck with on/public). So maybe on SNMP, tread carefully. ;-) Jason _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet --B_3414133391_43180165 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi,

=
I am not promoting (nor discouraging) SNMP for home networks= , but if you're going to discuss it, let me just make sure the WG under= stands some of the features of SNMP designed to be relevant to an IT departm= ent managing a home network remotely (and other cross-admin domain use cases= ).

You want to avoid SNMPv1 and SNMPv2 over a= n untrusted network, because they have only minimal security based on a shar= ed password passed in cleartext in every message – a community string.=  
The IETF has declared SNMPv1 and SNMPv2 Historic and NOT RE= COMMENDED, so certainly you should not write any recommendations for their u= se in homenet.

SNMP is a protocol designed to carry= MIB information. That separation of message from content is critically impo= rtant, to enable protocols other than SNMP to also carry MIB information.
If most end users do not use SNMPv1 because **MIB-based management**= is too complex and user-unfriendly for home use,  SNMPv3 will not solv= e that problem. It uses the same MIB.
SNMPv1 is quite easy to conf= igure – you just point it at an address and give it the right communit= y string. 
SNMPv3 was designed to be secure, and has lots of = security setup that would baffle most home users.
However, IT depa= rtments wanting SNMP to reach into the home could consider SNMPv3.

SNMPv3 offers authentication using negotiated methods -= its own security,  SSH and TLS. (all IETF standards).
It off= ers authorization on a per-user-session basis using RADIUS, tied into SSH an= d/or TLS.
While SNMPv1 and SNMPv3 both run over ports 161/162, SNM= Pv3 can distinguish whether the authentication is done using community strin= gs, SSH, TLS or the SNMPv3 built-in security, and allow/deny accordingly.&nb= sp;
SNMPv3 supports security fallback – e.g., if the network= is flaky and you cannot reach a CA, it can fall back to using the built-in = SNMP security.

SNMPv3 offers MIB database access co= ntrol (who can perform what operations on which information) 
Access control uses a tree-based approach, much like many graphical backup = applications; this allows policies to be defined, for example, at the everyt= hing, the MIB module level, table level, or the object-level. Access can be = dynamically configured by using RADIUS to assign a user to a predefined acce= ss policy (e.g., engineering vs accounting, Boston vs San Jose, home vs in-o= ffice, help-desk vs routing-admin, and so on).
The authentication/= authorization/MIB access control can be used to allow users to manage certai= n aspects of their network, such as device discovery and fault monitoring an= d host resources (RFC2790), while also allowing an ISP to manage aspects of = the home network.

SNMPv3 provides agents with a glo= bal identifier independent of their current address.
This was desi= gned specifically to handle dynamically-changing addresses, such as from DHC= P and NAT, or recognizing that a single agent is using multiple interfaces w= ith different addresses (important for correlating the data received via mul= tiple addresses for the same agent).

There is an SN= MP proxy-mib that provides a message-header rewrite (but not payload) betwee= n security approaches. 
The proxy-mib can be used for proxyin= g between SNMPv1 and SNMPv3 security.
For example, SNMPv1 can be u= sed managing a trusted internal network or a network with no SNMPv3 support,= like a homenet, and then proxy to SNMPv3 for carrying the data over an untr= usted network like the Internet.
If no proxy rule applies, the mes= sage gets dropped, like a firewall.

In a NAT enviro= nment, or other environment that uses aggregation, you may or may not want a= n ALG to do address translation in the payload. If you are looking at a &nbs= p;server farm, some uses might be better served by seeing this as one abstra= ct aggregation; For performance and fault monitoring, you might want to look= at each individual server. See RFC2962.

I hope thi= s helps provide more detail about relevant aspects of SNMP for home networks= .

--
=
David Harrington
Director, Transport= Area
Internet Engineering Task Force (IETF= )
Ietfdbh@comcast.net<= /div>
+1-603-828-1401


From: Jason Livingood <Jason_Livingood@cable.comcast.com>
Date: Fri, 9 Mar 2012 04:42:02 +0000
To: Michael Richardson <mcr@sandelman.ca>, "homenet@i= etf.org" <homenet@ietf.org><= br>Cc: Dave Taht <dave.taht@gmail.com>
Subject: Re: [homenet] snmp for monitoring home network

I think that E2E i= nto the home for SNMP is perhaps one of the things that would motivate an ISP to su= pport homenet.

E2E network mana= gement and/or monitoring, yes. SNMP, at least on a public interface, ma= ybe not so much. We may be entering a phase where ISPs consider blocking TCP= /UDP 161.  

The reason is that SNMP is becomin= g more and more widely abused. I still have no idea why for example (1) some= gear ships with public as the default string and the daemon running by defa= ult as such, (2) some gear does not present the user with an interface to turn off SNMP or change the community string at all (so you may be stuc= k with on/public). 

So maybe on SNMP, tread ca= refully. ;-)

Jason
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.or= g/mailman/listinfo/homenet --B_3414133391_43180165-- From ietfdbh@comcast.net Fri Mar 9 07:28:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE5421F86B9 for ; Fri, 9 Mar 2012 07:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.228 X-Spam-Level: X-Spam-Status: No, score=-102.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 AX5wztdQUE3A for ; Fri, 9 Mar 2012 07:28:01 -0800 (PST) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC6421F86E3 for ; Fri, 9 Mar 2012 07:28:01 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta06.westchester.pa.mail.comcast.net with comcast id jR1y1i0021ZXKqc56TU16H; Fri, 09 Mar 2012 15:28:01 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta21.westchester.pa.mail.comcast.net with comcast id jTTX1i01f3Ecudz3hTTk2t; Fri, 09 Mar 2012 15:28:00 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 09 Mar 2012 10:27:29 -0500 From: David Harrington To: Jim Gettys , Jason Livingood Message-ID: Thread-Topic: [homenet] snmp for monitoring home network In-Reply-To: <4F5A15F7.5000501@freedesktop.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "homenet@ietf.org" , Michael Richardson , Dave Taht Subject: Re: [homenet] snmp for monitoring home network X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 15:28:12 -0000 Hi, I am not sure what proposal you are referring to. I know multicast SNMP for discovery was proposed quite a few years ago, but multicast SNMP would depend on the non-secure nature of SNMPv1 and a well-known community string. This is at odds with the IETF declaring SNMPv1 Historic and not recommended. The multicast approach won't work with the built-in SNMPv3 security, and to my knowledge all effort to do this (at least in IETF) was dropped precipitously. Hopefully, nobody is seriously considering this approach again, if it builds on SNMPv1. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/9/12 9:38 AM, "Jim Gettys" wrote: >On 03/08/2012 11:42 PM, Livingood, Jason wrote: >> >> I think that E2E into the home for SNMP is perhaps one of the >> things that would motivate an ISP to support homenet. >> >> >> E2E network management and/or monitoring, yes. SNMP, at least on a >> public interface, maybe not so much. We may be entering a phase where >> ISPs consider blocking TCP/UDP 161. >> >> The reason is that SNMP is becoming more and more widely abused. I >> still have no idea why for example (1) some gear ships with public as >> the default string and the daemon running by default as such, (2) some >> gear does not present the user with an interface to turn off SNMP or >> change the community string at all (so you may be stuck with >>on/public). >> >> So maybe on SNMP, tread carefully. ;-) >> >Just to make it clear, I was worrying about the possible use of >multicast to *discover* SNMP devices, and routing versus bridging where >the multicast packet might need forwarding to other networks in the >hime, not SNMP in general. I had noted its possible use to *discover* >printers to initially configure them. > - Jim > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From gettysjim@gmail.com Fri Mar 9 08:00:46 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E1221F8710 for ; Fri, 9 Mar 2012 08:00:46 -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 jxzwswQWx+bq for ; Fri, 9 Mar 2012 08:00:46 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0239B21F85B6 for ; Fri, 9 Mar 2012 08:00:45 -0800 (PST) Received: by qcsq13 with SMTP id q13so1481277qcs.31 for ; Fri, 09 Mar 2012 08:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PiG8ux0tqy/uPBDuaAMc9eNQaUOcCCrt9tzHvyHGOWo=; b=YNI+AXDNjFxRH2lzMeMIDHdTD2fCPitobWghb7etg3mbIWQts3LnaEDu6rCwbdtTGY wKm457qNT4dWoMo5p4RyvL+68nWaa8Clchp2yZC6IzrYp4S4e8OSWSA3L6avu1bIIQN/ lOBpGN/ZFIbyD8XscVbyfkeNFNjByPZPf9nE2OIgNZiurDMmxTUiZLCr6gmuN1aPHOlG jOkZg30kJXTrl2eZrEgbt0jMjsCoFojCat3IaXypvpkEMPKouGISqG+dQxbJC9BQfX21 RY691lTDNKQqOD7u6JEQtfzSWeOBHkPQME85hxLHaGOdC9wZ4dB89FEdEya7ZDyhU16f /xxg== Received: by 10.224.177.145 with SMTP id bi17mr1038036qab.17.1331308845537; Fri, 09 Mar 2012 08:00:45 -0800 (PST) Received: from [192.168.1.24] (c-24-63-191-17.hsd1.ma.comcast.net. [24.63.191.17]) by mx.google.com with ESMTPS id ef6sm12236971qab.7.2012.03.09.08.00.42 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 08:00:43 -0800 (PST) Sender: Jim Gettys Message-ID: <4F5A2929.4010802@freedesktop.org> Date: Fri, 09 Mar 2012 11:00:41 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: David Harrington References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" , Jason Livingood , Michael Richardson , Dave Taht Subject: Re: [homenet] snmp for monitoring home network X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:00:47 -0000 On 03/09/2012 10:27 AM, David Harrington wrote: > Hi, > > I am not sure what proposal you are referring to. > I know multicast SNMP for discovery was proposed quite a few years ago, > but multicast SNMP would depend on the non-secure nature of SNMPv1 and a > well-known community string. This is at odds with the IETF declaring > SNMPv1 Historic and not recommended. > > The multicast approach won't work with the built-in SNMPv3 security, and > to my knowledge all effort to do this (at least in IETF) was dropped > precipitously. > Hopefully, nobody is seriously considering this approach again, if it > builds on SNMPv1. I was just observing comments I came across in code being used for printer discovery. That doesn't mean SNMP multicast is actually used significantly; it's mostly an example of another protocol that *could* cause trouble when we route rather than bridge everything inside the home. Having (apparently) demonstrated (we hope) that mDNS doesn't really present a major problem by implementation, I still have concerns if there are other protocols that matter that we'll have to worry about to get rid of the bridging horror we face today. I have *no* information that makes me think it's a *real* problem as yet, and see no way to do so before having running code in the hands of probably thousands of testers. At the moment, we have code in the hands of testers of the fingers on one or two hands.... More testers would be welcome.... I am encouraging everyone to think about potential problems that might be caused by other multicast protocols that may be in use; knowing sooner rather than later would be nice ;-). And thanks for the details about SNMP, they are indeed reassuring. - Jim On 3/9/12 9:38 AM, "Jim Gettys" wrote: >> On 03/08/2012 11:42 PM, Livingood, Jason wrote: >>> I think that E2E into the home for SNMP is perhaps one of the >>> things that would motivate an ISP to support homenet. >>> >>> >>> E2E network management and/or monitoring, yes. SNMP, at least on a >>> public interface, maybe not so much. We may be entering a phase where >>> ISPs consider blocking TCP/UDP 161. >>> >>> The reason is that SNMP is becoming more and more widely abused. I >>> still have no idea why for example (1) some gear ships with public as >>> the default string and the daemon running by default as such, (2) some >>> gear does not present the user with an interface to turn off SNMP or >>> change the community string at all (so you may be stuck with >>> on/public). >>> >>> So maybe on SNMP, tread carefully. ;-) >>> >> Just to make it clear, I was worrying about the possible use of >> multicast to *discover* SNMP devices, and routing versus bridging where >> the multicast packet might need forwarding to other networks in the >> hime, not SNMP in general. I had noted its possible use to *discover* >> printers to initially configure them. >> - Jim >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > From rdroms.ietf@gmail.com Fri Mar 9 10:06:01 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D5C21E8076 for ; Fri, 9 Mar 2012 10:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.155 X-Spam-Level: X-Spam-Status: No, score=-10.155 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 RIJcP6g4uqx2 for ; Fri, 9 Mar 2012 10:06:01 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF2321E806F for ; Fri, 9 Mar 2012 10:06:01 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1876576vcb.31 for ; Fri, 09 Mar 2012 10:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=U6NHSCI7qnzVpJbO1An0PdXs/9ZBTe1EYKClbMpyrUY=; b=qBGL1TYCkSX9UV+Q1d+ZqWBUsnzaqK5dz+QPiQpKVM6tCg9cZDGoUa0VWqs+vs1mT9 8PGFTfvS0G02TIOstLEJjWvuPrePEmYk+O3f3toNEjTcfM6oqSmGlmWrkcgGa7Q+pnAO aAGxMMn/DwL85t9w6WdoZkXU1l0SjJsG4uanUwhhAno9ECMq2N4gUZ92XI9Zw7nQLxPf NDx6msEAyJRv33ILQdLdzZyc8uPdniiH4I1AhX+rjlay1mj5fNUxi8+zB4/q2sKuxjyn CLIyzfbcXA0OqPSKJjmPeOmWEYdwI2YpITy5AGbtkyXl38OGDK3ScrW4aueAXy6/wnK0 +nFw== Received: by 10.52.88.9 with SMTP id bc9mr5137259vdb.74.1331316360750; Fri, 09 Mar 2012 10:06:00 -0800 (PST) Received: from ?IPv6:2001:420:2481:20:a8c9:84f5:9e50:2779? ([2001:420:2481:20:a8c9:84f5:9e50:2779]) by mx.google.com with ESMTPS id h5sm12015011vdk.0.2012.03.09.10.05.58 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 10:05:59 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 13:05:55 -0500 Message-Id: To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 18:06:01 -0000 Here's my list of "desired behaviors" for name resolution, proposed for = inclusion in the architecture document; comments and suggestions = welcome: * Disconnected operation ("fate sharing"): name resolution for reachable = devices continues if the local network is disconnected from the global = Internet * Relative name resolution: some naming convention that allows name = resolution while mitigating the need to know an absolute location in the = global DNS namespace * Unmanaged operation * Efficient message utilization: for example, keep unwanted traffic off = of an IEEE802.15.4 network * Representation in the global DNS namespace, for access from off-net - Ralph From Ray.Bellis@nominet.org.uk Fri Mar 9 10:24:34 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B9821F85B5 for ; Fri, 9 Mar 2012 10:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.217 X-Spam-Level: X-Spam-Status: No, score=-10.217 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 F0wiCBXkw2Za for ; Fri, 9 Mar 2012 10:24:33 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id A416C21F85B1 for ; Fri, 9 Mar 2012 10:24:28 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=W2Y4syVtdOHt9S+//QLfX79PVdI+QpoJE+36EAYDXw5ENwJx1t9ciFp9 cGp30vARzBbfjiP2zzyOwjQbKPBzKbVo+33gcipPYHQlDwBoacLQ58wGb abh6ZKf062mgRUb; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1331317469; x=1362853469; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Name=20resolution=20in=20th e=20homenet=20architecture=20document|Date:=20Fri,=209=20 Mar=202012=2018:24:25=20+0000|Message-ID:=20|To:=20Ralph=20Dr oms=20|CC:=20"" =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<79368332-1600-48c0-9ca9-4aa07e49c50c> |In-Reply-To:=20|References:=20; bh=dU7SbftzS1y4v01MUHtJCS6xfNuWDAVkKASIxVpMvbY=; b=FT9FZ/J1XdaAJWYEkMelh7dvsl/y8H/FuXxpERDbsLzW3HcnLvrNyQ32 4wVtBkC3SOF4wZnWFWtp4r6Mg1OIDoknUkQwzoa2i/r+L00jzEH6a2Xff ZAjqo/zL9pd2q8d; X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208";a="38733675" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 09 Mar 2012 18:24:27 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Fri, 9 Mar 2012 18:24:27 +0000 From: Ray Bellis To: Ralph Droms Thread-Topic: [homenet] Name resolution in the homenet architecture document Thread-Index: AQHM/h9UxKtxAP/z4U64+iJXWlgrSJZiR3eA Date: Fri, 9 Mar 2012 18:24:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <79368332-1600-48c0-9ca9-4aa07e49c50c> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 18:24:34 -0000 On 9 Mar 2012, at 18:05, Ralph Droms wrote: > Here's my list of "desired behaviors" for name resolution, proposed for i= nclusion in the architecture document; comments and suggestions welcome: Thanks - here are some comments, without my hat on: > * Disconnected operation ("fate sharing"): name resolution for reachable = devices continues if the local network is disconnected from the global Inte= rnet Yes, absolutely! > * Relative name resolution: some naming convention that allows name resol= ution while mitigating the need to know an absolute location in the global = DNS namespace Hmm, I'm uneasy about this one. I've been vocal in my complaints about how broken the DNS Search Path mecha= nism is. In particular, I'm concerned about the possible security implicat= ions of using a relative location when a mobile device is moving between ne= tworks. > * Unmanaged operation Yes > * Efficient message utilization: for example, keep unwanted traffic off o= f an IEEE802.15.4 network Yes > * Representation in the global DNS namespace, for access from off-net Yes. A related issue, also touched on above, is the local namespace. That is, s= hould there be a single namespace used in the Homenet, regardless of whethe= r the query mechanism is unicast DNS, mDNS, or xmDNS (per Kerry Lynn's draf= t), or even something that isn't DNS at all? I'm OK with the idea of a non-DNS based protocol using a pseudo TLD to indi= cate that it's something different (c.f. ".UUCP"), but to me it just feels = wrong that this should be necessary when using stuff that's _so_ close to "= normal" unicast DNS. Ray From mcr@sandelman.ca Fri Mar 9 10:45:32 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A630121E8088 for ; Fri, 9 Mar 2012 10:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 f00B1P2cn2fV for ; Fri, 9 Mar 2012 10:45:31 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id CB1D121E8081 for ; Fri, 9 Mar 2012 10:45:31 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 31BAA344DF for ; Fri, 9 Mar 2012 13:42:58 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 048D198282; Fri, 9 Mar 2012 13:45:29 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id F1BC498281 for ; Fri, 9 Mar 2012 13:45:29 -0500 (EST) From: Michael Richardson To: "" In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Fri, 09 Mar 2012 13:45:29 -0500 Message-ID: <16969.1331318729@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 18:45:32 -0000 >>>>> "Ray" == Ray Bellis writes: >> * Relative name resolution: some naming convention that allows >> name resolution while mitigating the need to know an absolute >> location in the global DNS namespace Ray> Hmm, I'm uneasy about this one. Ray> I've been vocal in my complaints about how broken the DNS Ray> Search Path mechanism is. In particular, I'm concerned about Ray> the possible security implications of using a relative location Ray> when a mobile device is moving between networks. I agree with your concern, but sufficient != necessary. I do not believe that anyone *OUGHT* to pay attention to DNS search order as provided by DHCP. That doesn't mean that it shouldn't be available!!!! (Most systems I've seen get this wrong. If you select DHCP, your search path is forced to DHCP, you have to select static to pick it) Ray> Yes. Ray> A related issue, also touched on above, is the local namespace. Ray> That is, should there be a single namespace used in the Ray> Homenet, regardless of whether the query mechanism is unicast Ray> DNS, mDNS, or xmDNS (per Kerry Lynn's draft), or even something Ray> that isn't DNS at all? I want one. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From brian.e.carpenter@gmail.com Fri Mar 9 10:55:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8E121E8095 for ; Fri, 9 Mar 2012 10:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 yMFP80d3SQbV for ; Fri, 9 Mar 2012 10:55:41 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 30BC021E808D for ; Fri, 9 Mar 2012 10:55:41 -0800 (PST) Received: by eeke51 with SMTP id e51so582855eek.31 for ; Fri, 09 Mar 2012 10:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3CL21qxMfNCfmsnI516rTC2iuHCwKBDRHf3EDiU9nJg=; b=rLROv8y5EWvWMkD6pzYfVQynMSPZDVfNXo5xdOZm2XWMt9MUJ0HlCfcBMbi6StWjGr 3uWYxOSFhcx3Dpiig3q0pVXWSgSBrhNNqSqj6f5CCuIn05GVN3fbMxPTkm+OeMsRswvw pvrn73q/YrMtBDjZSEwR15qxGApXg1oclwiiV/Kep0lGvZ8cSPEgFrTObA/dBMo2fWPh ci+aNkWt/ZlvoXCbcrD0/cfCFf7d8UIAKMDdQ3VgL1+dO8NRcy37B5ITKYcThRgWmGgI QTHbHET8qKZnud4yFje09/Cs3QaYeI5XiGff7s9j2+BlS9I9MCoSz3ClGOx5Od/Ez+Pi It6g== Received: by 10.213.2.69 with SMTP id 5mr396432ebi.104.1331319340322; Fri, 09 Mar 2012 10:55:40 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id o11sm21035992eef.4.2012.03.09.10.55.35 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 10:55:39 -0800 (PST) Message-ID: <4F5A521B.9030601@gmail.com> Date: Sat, 10 Mar 2012 07:55:23 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jim Gettys References: <4F5A2929.4010802@freedesktop.org> In-Reply-To: <4F5A2929.4010802@freedesktop.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jason Livingood , "homenet@ietf.org" , David Harrington , Michael Richardson , Dave Taht Subject: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 18:55:42 -0000 On 2012-03-10 05:00, Jim Gettys wrote: ... > I was just observing comments I came across in code being used for > printer discovery. Why would we consider anything other than SLP for service discovery? Brian From dave.taht@gmail.com Fri Mar 9 11:25:34 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE6F21E807B for ; Fri, 9 Mar 2012 11:25:34 -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 QYsaqnumrFDI for ; Fri, 9 Mar 2012 11:25:33 -0800 (PST) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7628721E8062 for ; Fri, 9 Mar 2012 11:25:33 -0800 (PST) Received: by wibhr17 with SMTP id hr17so694467wib.1 for ; Fri, 09 Mar 2012 11:25:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EW1gzOcITHNPzgH5+A5Vn/IrBPsFmyOhomYX2R6YvhI=; b=jBfIMDsiuWcDP8t2t3Zqmawu9v+BaOqDx+wFTfJ/6eGLQwJe/YD82wGgSbF5hf/lX8 2hU6sfTSGumvbFW6rM4AzN7k4YhXhmCzAXl+nYgFBfTbRfF5IEhssTP6IDWKlGzXUJit A9cM7gAy+MgZ6/avGakEMRmSWvgwcOdsICZmwB4RUPED/4AldGpzQtrtfJXeKg41QyNO 8VO8qGfaudpi1gXlNJpsZ2+NKlvyeKlTfKzi9e/kh/i49haiGYRZZ1eAturgkPzf1Pi/ rJYM31SaoVhtFN9G/gcJyvdvVsqFSk93Am/JdYIVa2CuqMKW8PqRrUQ/F9wdZ3NbCbRq Bw5A== MIME-Version: 1.0 Received: by 10.180.98.8 with SMTP id ee8mr7553237wib.14.1331321132699; Fri, 09 Mar 2012 11:25:32 -0800 (PST) Received: by 10.223.151.8 with HTTP; Fri, 9 Mar 2012 11:25:32 -0800 (PST) In-Reply-To: <4F5A521B.9030601@gmail.com> References: <4F5A2929.4010802@freedesktop.org> <4F5A521B.9030601@gmail.com> Date: Fri, 9 Mar 2012 11:25:32 -0800 Message-ID: From: Dave Taht To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org" Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 19:25:34 -0000 On Fri, Mar 9, 2012 at 10:55 AM, Brian E Carpenter wrote: > On 2012-03-10 05:00, Jim Gettys wrote: > ... >> I was just observing comments I came across in code being used for >> printer discovery. > > Why would we consider anything other than SLP for service discovery? I don't know the cause of jg's printing issue. Wouldn't mind knowing, but I doubt it's snmp. However I note that zeroconf is the way apparently apple is going, rather than SLP, since OS-X 10.2 and later, according to wikipedai and... http://www.unixmen.com/201202-apple-orphans-linux-cups-features-handicaps-o= pen-source-printing/ "CUPS Browsing, the pivotal process that detects cups-to-cups printer queue on Linux will no longer be available. Up until now each CUPS server typically sends UDP packets at 631 port to indicate its availability for queuing. Now, the new changes in CUPS 1.6 will not allow this browsing to happen and will be replaced with DNS-SD. This is already the standard for Mac OS X, but does not include Avahi support. Avahi is a popular system for zeroconf DNS-SD processes." --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net From paduffy@cisco.com Fri Mar 9 11:42:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A572A21E8083 for ; Fri, 9 Mar 2012 11:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 00Yu9tKzkD2z for ; Fri, 9 Mar 2012 11:42:42 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B396521E807B for ; Fri, 9 Mar 2012 11:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=576; q=dns/txt; s=iport; t=1331322161; x=1332531761; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HztO9Gse2VGi7a7/QMrszz7Fq7knBeHYfoiEuCkT79Y=; b=OKA+ju8aK5XRoJ0nbdQKNFvu/mFiQ/52aVUlBSjrccAwrkZLbNSN6wgv VdLLMcmtbop54uQCcGYwj8ahFtzhcaO7yUDVh2GmZ1QuT2PGIoeFs7fFz nQOkr6rhKV3Z4twcByi9r6U0lWKcosu5poMKATE1niKd5Fm4lQuSPSFGC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANpcWk+Q/khR/2dsb2JhbABCtT+BB4IKAQEBAwEBAQEPAQIBIjYKARALGAkWDwkDAgECARUwBg0BBQIBAR6HYwULoAMBgzEPAZNLBJB4BIhTjHaFZoo2gwE X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208";a="68121438" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 09 Mar 2012 19:42:40 +0000 Received: from [161.44.66.230] (dhcp-161-44-66-230.cisco.com [161.44.66.230]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q29JgdxU029349; Fri, 9 Mar 2012 19:42:39 GMT Message-ID: <4F5A5D2F.5030302@cisco.com> Date: Fri, 09 Mar 2012 14:42:39 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4F5A2929.4010802@freedesktop.org> <4F5A521B.9030601@gmail.com> In-Reply-To: <4F5A521B.9030601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Richardson , Jason Livingood , Dave Taht , Jim Gettys , "homenet@ietf.org" , David Harrington Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 19:42:42 -0000 On 3/9/2012 1:55 PM, Brian E Carpenter wrote: > On 2012-03-10 05:00, Jim Gettys wrote: > ... >> I was just observing comments I came across in code being used for >> printer discovery. > Why would we consider anything other than SLP for service discovery? Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more traction in the consumer space than SLP. Please do correct if I'm wrong. > > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From mellon@fugue.com Fri Mar 9 11:58:28 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CC221E8025 for ; Fri, 9 Mar 2012 11:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Z99j1CO70LNM for ; Fri, 9 Mar 2012 11:58:27 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6E721E8019 for ; Fri, 9 Mar 2012 11:58:27 -0800 (PST) Received: from [IPv6:2001:470:1f07:1486:5584:4e51:6424:9fbd] (unknown [IPv6:2001:470:1f07:1486:5584:4e51:6424:9fbd]) by toccata.fugue.com (Postfix) with ESMTPSA id DCA1D238224E; Fri, 9 Mar 2012 14:58:24 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F434FF4B-32A5-4E0E-AFC2-AF2B2AA3261D" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Ted Lemon In-Reply-To: Date: Fri, 9 Mar 2012 14:58:23 -0500 Message-Id: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> References: To: Ray Bellis X-Mailer: Apple Mail (2.1426) Cc: "" , Ralph Droms Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 19:58:28 -0000 --Apple-Mail=_F434FF4B-32A5-4E0E-AFC2-AF2B2AA3261D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 9, 2012, at 1:24 PM, Ray Bellis = wrote: > I've been vocal in my complaints about how broken the DNS Search Path = mechanism is. In particular, I'm concerned about the possible security = implications of using a relative location when a mobile device is moving = between networks. Very true. Ideally your homenet would have a namespace in the global = DNS hierarchy that would remain the same regardless of where you = connected, and your client would have TSIG credentials sufficient to = update its own name in that namespace. Roving namespaces seem fraught = with opportunities for the wrong thing to happen, intentionally or = otherwise. --Apple-Mail=_F434FF4B-32A5-4E0E-AFC2-AF2B2AA3261D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ray.Bellis@nominet.org.uk>= ; wrote:
I've been = vocal in my complaints about how broken the DNS Search Path mechanism = is.  In particular, I'm concerned about the possible security = implications of using a relative location when a mobile device is moving = between networks.

Very true.   = Ideally your homenet would have a namespace in the global DNS hierarchy = that would remain the same regardless of where you connected, and your = client would have TSIG credentials sufficient to update its own name in = that namespace.   Roving namespaces seem fraught with opportunities = for the wrong thing to happen, intentionally or = otherwise.

= --Apple-Mail=_F434FF4B-32A5-4E0E-AFC2-AF2B2AA3261D-- From brian.e.carpenter@gmail.com Sat Mar 10 10:58:53 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2B321F8476 for ; Sat, 10 Mar 2012 10:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 obhexkEL8VgR for ; Sat, 10 Mar 2012 10:58:52 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 294BC21F8475 for ; Sat, 10 Mar 2012 10:58:52 -0800 (PST) Received: by eaaq11 with SMTP id q11so724646eaa.31 for ; Sat, 10 Mar 2012 10:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/6gAe+5tIdogzkTjThtNaJqOHYULq2whXGEm2no6fOI=; b=H0H+F4UCzUmII2aQrl4hLW36z7/7VqSyplHFi1h644m4Bo8llDnOu03w2DoIGJNlpj z9RF6UFdvkiD/0+PxV+AXFXIqm8CWm285byDPrHg2UjexWStBcQh3RNLwZPIhkmt/Dqd uvHZ5cyVzNkFaTT1gZcJqLYTWkcuh0MJqUTKFh9C2WPoEFx+z2vcXKnMF79rxmL1/nJW taMGSaN9i119cUi11lEmxgZ3YB9x/wYtz+JRfro7omsfaan/JHO25T3BeVRA1STo2NRK KcD+wdHCvPYQElNye+qhYOoOGtV+FZKuuGHa9tdB3WxgxnJ7F2M7wV4xK9xdmDluSPgR XC7A== Received: by 10.14.22.16 with SMTP id s16mr1082570ees.2.1331405931114; Sat, 10 Mar 2012 10:58:51 -0800 (PST) Received: from [10.1.1.3] ([121.98.251.219]) by mx.google.com with ESMTPS id u9sm31266534eem.11.2012.03.10.10.58.45 (version=SSLv3 cipher=OTHER); Sat, 10 Mar 2012 10:58:50 -0800 (PST) Message-ID: <4F5BA45A.9040100@gmail.com> Date: Sun, 11 Mar 2012 07:58:34 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: paduffy@cisco.com References: <4F5A2929.4010802@freedesktop.org> <4F5A521B.9030601@gmail.com> <4F5A5D2F.5030302@cisco.com> In-Reply-To: <4F5A5D2F.5030302@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , Jason Livingood , Dave Taht , Jim Gettys , homenet@ietf.org, David Harrington Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 18:58:53 -0000 On 2012-03-10 08:42, Paul Duffy wrote: > On 3/9/2012 1:55 PM, Brian E Carpenter wrote: >> On 2012-03-10 05:00, Jim Gettys wrote: >> ... >>> I was just observing comments I came across in code being used for >>> printer discovery. >> Why would we consider anything other than SLP for service discovery? > > Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more > traction in the consumer space than SLP. > > Please do correct if I'm wrong. Aren't we trying to influence the future rather than document the past? We need a name-based service discovery solution. That's also a requirement emerging from 6renum. I think we should decide what's the best recommendation; it may end up being DNS-based, but this is what SLP was designed for, so IMHO it should be considered. This is clearly *not* what SNMP was designed for. Brian From d.sturek@att.net Sat Mar 10 13:21:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC0F21F8539 for ; Sat, 10 Mar 2012 13:21:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzfzENQQZOCt for ; Sat, 10 Mar 2012 13:21:57 -0800 (PST) Received: from nm35-vm7.bullet.mail.bf1.yahoo.com (nm35-vm7.bullet.mail.bf1.yahoo.com [72.30.238.79]) by ietfa.amsl.com (Postfix) with SMTP id 5F45721F8535 for ; Sat, 10 Mar 2012 13:21:57 -0800 (PST) Received: from [98.139.212.145] by nm35.bullet.mail.bf1.yahoo.com with NNFMP; 10 Mar 2012 21:21:51 -0000 Received: from [68.142.200.227] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 10 Mar 2012 21:21:51 -0000 Received: from [66.94.237.117] by t8.bullet.mud.yahoo.com with NNFMP; 10 Mar 2012 21:21:51 -0000 Received: from [127.0.0.1] by omp1022.access.mail.mud.yahoo.com with NNFMP; 10 Mar 2012 21:21:51 -0000 X-Yahoo-Newman-Id: 785670.8395.bm@omp1022.access.mail.mud.yahoo.com Received: (qmail 96865 invoked from network); 10 Mar 2012 21:21:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1331414511; bh=bLtQjn5cAtmbWyoIoEjnOF6RGBRNCdO/VqjzGbLWiVE=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=ZG4Fb5WpneYiEsZKw9QZweIuVRHkydJnBs+eeS14LaW4GPZSu8h4qArVGe3wjwTHupEL1Gf6PHYwFBYxVHwJWSK0aZ/Uex6fWkcsGSeoZwhhOAkNHSwsCJHH4zKs1kS7q9mHaBkQFqADv4Zh6ptvV15Tis0s31zLV2ebhoMStc4= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6iec7JoVM1kn4aWl4i.th9M2TY5RJmMQhcbYKqu7YtOdGZk ZS4YkBAfsaJDWg28nxl03yQ.Yp43JwHHCVsBOyRCCLT7OphyMnl.6.BW7Kmr tcyslqy1MuHBXVFTy63hmWgMavuHkd56j0_8lriLuyozJdx_ijSuzSd.JWe2 lcSJI_uss3sHr9mgCDMAckARuGAA40u1CugoC4de5co.vsIMn6_aiBmJVygw JRV18M2jxK3wDlDvbJqRin2.2E524F.XESgoG6u_neU9dSLylC.nuWSBxYk9 mZpkzjTw8MOmhTnacSpqAk2wA47fsUlGizkmvclhwpWbQxY0_nTVYnDkEkvk YKMFrqybZqCUjwyz0es7ICnTxZvV6hm69.eDynQ7OUaWfo.qkhnZALKriEup at2ccQZ.otJQPoH4jwS8DugThVi_zM461GSY- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.196] (d.sturek@69.224.190.132 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 10 Mar 2012 13:21:51 -0800 PST User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 10 Mar 2012 13:21:36 -0800 From: Don Sturek To: Brian E Carpenter , Message-ID: Thread-Topic: [homenet] Discovery [snmp for monitoring home network] In-Reply-To: <4F5BA45A.9040100@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Michael Richardson , Jason Livingood , Jim Gettys , Dave Taht , homenet@ietf.org, David Harrington Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 21:21:58 -0000 Can I ask exactly where SLP has been deployed? I spent some time investigating discovery solutions (we ended up using mDNS) but I could not find any significant deployments of SLP. It really came down to uPnP and mDNS....... Don On 3/10/12 10:58 AM, "Brian E Carpenter" wrote: >On 2012-03-10 08:42, Paul Duffy wrote: >> On 3/9/2012 1:55 PM, Brian E Carpenter wrote: >>> On 2012-03-10 05:00, Jim Gettys wrote: >>> ... >>>> I was just observing comments I came across in code being used for >>>> printer discovery. >>> Why would we consider anything other than SLP for service discovery? >> >> Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more >> traction in the consumer space than SLP. >> >> Please do correct if I'm wrong. > >Aren't we trying to influence the future rather than document the >past? > >We need a name-based service discovery solution. That's also a >requirement emerging from 6renum. I think we should decide what's >the best recommendation; it may end up being DNS-based, but this >is what SLP was designed for, so IMHO it should be considered. > >This is clearly *not* what SNMP was designed for. > > Brian >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From kerlyn2001@gmail.com Sat Mar 10 14:02:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0ED21F8540 for ; Sat, 10 Mar 2012 14:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] 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 6iZk6eAVJbrw for ; Sat, 10 Mar 2012 14:02:52 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C439921F8513 for ; Sat, 10 Mar 2012 14:02:51 -0800 (PST) Received: by lbol12 with SMTP id l12so722282lbo.31 for ; Sat, 10 Mar 2012 14:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oG+OsV6IKcXU7QppE/zq4+IBvpVL2LGlvlJYab2sUs4=; b=GvzJjJLKhQpm00L0ghYM/T6RcJPrvhnNvgOjBhp3jlxnVThrsmR21cklrCvMjbzDX+ DIqAEYkr/OauHtfHLAEVcalxGt7INV3bxZc6Hs0O6cRNyIqa3PEr0a4p/ihQR2Z5047q JRi6JixfV5HfTXzszZ/PZvaIsafeFcLuRiWzhD1SkS7SXOCiKnDIr3cYxCqpILXhoE+y U9l+Mdr9P9CludwVcb8PRw8VjeosJ1uJLm0CKsTiHnJOjQzDiZiNgPiT+mE+wtN8M9f/ L5l5v1RNqY4Bn9WrtD7gO++3qKklVuu2AMH+t+INGCkrhkiKyFC+bz4LtV6M4hggkv5p 7iBA== MIME-Version: 1.0 Received: by 10.152.103.239 with SMTP id fz15mr5202717lab.42.1331416970766; Sat, 10 Mar 2012 14:02:50 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.112.77.179 with HTTP; Sat, 10 Mar 2012 14:02:50 -0800 (PST) In-Reply-To: <4F5BA45A.9040100@gmail.com> References: <4F5A2929.4010802@freedesktop.org> <4F5A521B.9030601@gmail.com> <4F5A5D2F.5030302@cisco.com> <4F5BA45A.9040100@gmail.com> Date: Sat, 10 Mar 2012 14:02:50 -0800 X-Google-Sender-Auth: etymluaDaExsjW4t2ceLQpd1uzs Message-ID: From: Kerry Lynn To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Michael Richardson , paduffy@cisco.com, David Harrington , Jim Gettys , Dave Taht , homenet@ietf.org, Jason Livingood Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 22:02:52 -0000 On Sat, Mar 10, 2012 at 10:58 AM, Brian E Carpenter wrote: > On 2012-03-10 08:42, Paul Duffy wrote: >> On 3/9/2012 1:55 PM, Brian E Carpenter wrote: >>> On 2012-03-10 05:00, Jim Gettys wrote: >>> ... >>>> I was just observing comments I came across in code being used for >>>> printer discovery. >>> Why would we consider anything other than SLP for service discovery? >> >> Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more >> traction in the consumer space than SLP. >> >> Please do correct if I'm wrong. > > Aren't we trying to influence the future rather than document the > past? > Brian, I'm not sure of your point; mDNS and DNS-SD are Standards Track drafts currently in the RFC-Editor queue and there are tens of millions of deployed mDNS responders. If SLP is running in my home, I'm not aware of it. > We need a name-based service discovery solution. That's also a > requirement emerging from 6renum. I think we should decide what's > the best recommendation; it may end up being DNS-based, but this > is what SLP was designed for, so IMHO it should be considered. > Just as homenet has "Largest Possible Subnets", "Fewest Topology Assumptions", and "Self Organizing" principles, perhaps we should also consider "Fewest Protocols" as well. To my mind, using DNS for both service discovery and name resolution has many advantages. These are documented in the above mentioned drafts, but I would just point out three: simple DNS-based discovery is trivial to add to an existing resolver, mDNS has been demonstrated in constrained environments (e.g. it places limits on name length and character set), and it is based on a well-understood (and well-supported) protocol. There may be good reasons to consider SLP, but I'd like to see how these line up against the home net goals. I will add that I've co-authored a draft that considers extending mDNS to site scope and would like to receive any comments people have: https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/ Thanks, -K- > This is clearly *not* what SNMP was designed for. > > =A0 Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Sat Mar 10 15:53:31 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C911F21F8547 for ; Sat, 10 Mar 2012 15:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 sI8gXVAq2G4V for ; Sat, 10 Mar 2012 15:53:31 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D03D721F8545 for ; Sat, 10 Mar 2012 15:53:30 -0800 (PST) Received: by eeke51 with SMTP id e51so770451eek.31 for ; Sat, 10 Mar 2012 15:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Dy1ETDT57uJruiwzGIf2GuxZYttbfmwSg+9mQEq536Y=; b=vq4McsRXHgq63AI2FmavoW1QwQf2ScCh+5EUb+uWdGHPYLTUvW32p7s/EtNDgGDf41 hzzNWk1G/8AR2KLCWlIfqdFdlWyBlwvFwILT/yv3JRhqzFuwAYqJwGWepn/l4ubDq17m F0xQRjXUOwrPnFFdauInOyfWwz/tF0qDj+XTxwYUtJOkxx5VBpk3arSnlK6Xbk5UhzQ4 bDDGUdwYTLSOw1wafy+/hEdBuc0XAQNAasPWNvD4nmBsL6x0jm8v+jtoI6sd79jrKI5r aGZwYdb74HJ6BeUNnqbzh7DvEGpP4LqqmntVYcMn4sRp2/D0DSYeoVjD8EMDJ6F36fUl aI8Q== Received: by 10.14.50.207 with SMTP id z55mr1141562eeb.45.1331423609844; Sat, 10 Mar 2012 15:53:29 -0800 (PST) Received: from [10.1.1.3] ([121.98.251.219]) by mx.google.com with ESMTPS id n56sm11642174eeb.4.2012.03.10.15.53.23 (version=SSLv3 cipher=OTHER); Sat, 10 Mar 2012 15:53:28 -0800 (PST) Message-ID: <4F5BE96C.8040204@gmail.com> Date: Sun, 11 Mar 2012 12:53:16 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Kerry Lynn References: <4F5A2929.4010802@freedesktop.org> <4F5A521B.9030601@gmail.com> <4F5A5D2F.5030302@cisco.com> <4F5BA45A.9040100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Michael Richardson , paduffy@cisco.com, David Harrington , Jim Gettys , Dave Taht , homenet@ietf.org, Jason Livingood Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 23:53:31 -0000 Cutting to the chase (and this answers Don too): > There may be good reasons to consider SLP, but I'd > like to see how these line up against the home net goals. Exactly. It's perfectly fine by me if SLP is not the right answer for future homenets, but this should be a goal-based decision, not based on what happens to be deployed on single-subnet homenets today. Regards Brian On 2012-03-11 11:02, Kerry Lynn wrote: > On Sat, Mar 10, 2012 at 10:58 AM, Brian E Carpenter > wrote: >> On 2012-03-10 08:42, Paul Duffy wrote: >>> On 3/9/2012 1:55 PM, Brian E Carpenter wrote: >>>> On 2012-03-10 05:00, Jim Gettys wrote: >>>> ... >>>>> I was just observing comments I came across in code being used for >>>>> printer discovery. >>>> Why would we consider anything other than SLP for service discovery? >>> Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more >>> traction in the consumer space than SLP. >>> >>> Please do correct if I'm wrong. >> Aren't we trying to influence the future rather than document the >> past? >> > Brian, > > I'm not sure of your point; mDNS and DNS-SD are Standards Track > drafts currently in the RFC-Editor queue and there are tens of millions > of deployed mDNS responders. If SLP is running in my home, I'm > not aware of it. > >> We need a name-based service discovery solution. That's also a >> requirement emerging from 6renum. I think we should decide what's >> the best recommendation; it may end up being DNS-based, but this >> is what SLP was designed for, so IMHO it should be considered. >> > Just as homenet has "Largest Possible Subnets", "Fewest Topology > Assumptions", and "Self Organizing" principles, perhaps we should > also consider "Fewest Protocols" as well. To my mind, using DNS for > both service discovery and name resolution has many advantages. > These are documented in the above mentioned drafts, but I would > just point out three: simple DNS-based discovery is trivial to add to > an existing resolver, mDNS has been demonstrated in constrained > environments (e.g. it places limits on name length and character > set), and it is based on a well-understood (and well-supported) > protocol. There may be good reasons to consider SLP, but I'd > like to see how these line up against the home net goals. > > I will add that I've co-authored a draft that considers extending mDNS > to site scope and would like to receive any comments people have: > https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/ > > Thanks, -K- > >> This is clearly *not* what SNMP was designed for. >> >> Brian >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > From gettysjim@gmail.com Sat Mar 10 16:39:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F75621F844B for ; Sat, 10 Mar 2012 16:39:21 -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 9kzdU+QnCSDz for ; Sat, 10 Mar 2012 16:39:20 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 25C0C21F84CF for ; Sat, 10 Mar 2012 16:39:11 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so3354643vcb.31 for ; Sat, 10 Mar 2012 16:39:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NfcnNC/kwHvQ2wawimwqvmcLUIb3n5FeyVS/bDZxcgU=; b=OZ7QwZdy4HzohSwuta5Gtl47UQkTXuJQPBUN53DnpLOb4n87vdiWPmk8KB00FNor+9 ii6WtyCJokx8V7xu6fU5U6W38F4Zq2wzRap6MPprmoogyYiuVUSX5oEJ6KcxnwuZRimQ wFvXUMHsF+ahtqLNVrfLVbmjDQhFdLJDzr2xGrylBQLtAD47jtYTtL7JWFvpd+v/BcwK KNwsHf4pFCoK9Cw5VVrGR1ZOobxOKkrB4JbyUERTWHjeRqMfysPgSHa1pDubNxDSEF54 tjZ5G0p280RJlfD3znZ90HGad5j3mATUX/waqKgAUeGzIoNmCkdKG4xc9YA59fQgDnNY +X+g== Received: by 10.52.17.82 with SMTP id m18mr10826775vdd.89.1331426350314; Sat, 10 Mar 2012 16:39:10 -0800 (PST) Received: from [172.30.48.80] (c-50-138-169-248.hsd1.ma.comcast.net. [50.138.169.248]) by mx.google.com with ESMTPS id t8sm19707646vdh.11.2012.03.10.16.39.07 (version=SSLv3 cipher=OTHER); Sat, 10 Mar 2012 16:39:08 -0800 (PST) Sender: Jim Gettys Message-ID: <4F5BF42A.7050002@freedesktop.org> Date: Sat, 10 Mar 2012 19:39:06 -0500 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4F5A2929.4010802@freedesktop.org> <4F5A521B.9030601@gmail.com> <4F5A5D2F.5030302@cisco.com> <4F5BA45A.9040100@gmail.com> <4F5BE96C.8040204@gmail.com> In-Reply-To: <4F5BE96C.8040204@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kerry Lynn , Michael Richardson , paduffy@cisco.com, David Harrington , Dave Taht , homenet@ietf.org, Jason Livingood Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 00:39:21 -0000 On 03/10/2012 06:53 PM, Brian E Carpenter wrote: > Cutting to the chase (and this answers Don too): > >> There may be good reasons to consider SLP, but I'd >> like to see how these line up against the home net goals. > Exactly. It's perfectly fine by me if SLP is not the right > answer for future homenets, but this should be a goal-based > decision, not based on what happens to be deployed on > single-subnet homenets today. I agree Brian. My concern is just figuring out if there are any practical issues in already deployed discovery protocols (e.g. mDNS, uPnP) or wiggling things we don't know about in a corner that will stand in the way of making *real* home *networks*, that are actually networks, rather than our current bridged disasters that people call home routers, but really aren't... When there were discussions about routing versus bridging in homenet early on, there was quite a bit of scepticism that routing can be made to work without unforseen practical problems: we're trying to answer that along the way in our CeroWrt work. So far, thinks look ok. But I believe first all in "running code", much more than hand-waving.... - Jim > > Regards > Brian > > On 2012-03-11 11:02, Kerry Lynn wrote: >> On Sat, Mar 10, 2012 at 10:58 AM, Brian E Carpenter >> wrote: >>> On 2012-03-10 08:42, Paul Duffy wrote: >>>> On 3/9/2012 1:55 PM, Brian E Carpenter wrote: >>>>> On 2012-03-10 05:00, Jim Gettys wrote: >>>>> ... >>>>>> I was just observing comments I came across in code being used for >>>>>> printer discovery. >>>>> Why would we consider anything other than SLP for service discovery? >>>> Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more >>>> traction in the consumer space than SLP. >>>> >>>> Please do correct if I'm wrong. >>> Aren't we trying to influence the future rather than document the >>> past? >>> >> Brian, >> >> I'm not sure of your point; mDNS and DNS-SD are Standards Track >> drafts currently in the RFC-Editor queue and there are tens of millions >> of deployed mDNS responders. If SLP is running in my home, I'm >> not aware of it. >> >>> We need a name-based service discovery solution. That's also a >>> requirement emerging from 6renum. I think we should decide what's >>> the best recommendation; it may end up being DNS-based, but this >>> is what SLP was designed for, so IMHO it should be considered. >>> >> Just as homenet has "Largest Possible Subnets", "Fewest Topology >> Assumptions", and "Self Organizing" principles, perhaps we should >> also consider "Fewest Protocols" as well. To my mind, using DNS for >> both service discovery and name resolution has many advantages. >> These are documented in the above mentioned drafts, but I would >> just point out three: simple DNS-based discovery is trivial to add to >> an existing resolver, mDNS has been demonstrated in constrained >> environments (e.g. it places limits on name length and character >> set), and it is based on a well-understood (and well-supported) >> protocol. There may be good reasons to consider SLP, but I'd >> like to see how these line up against the home net goals. >> >> I will add that I've co-authored a draft that considers extending mDNS >> to site scope and would like to receive any comments people have: >> https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/ >> >> Thanks, -K- >> >>> This is clearly *not* what SNMP was designed for. >>> >>> Brian >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Sat Mar 10 16:47:39 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A2821F8516 for ; Sat, 10 Mar 2012 16:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] 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 kl1c82b4xxHW for ; Sat, 10 Mar 2012 16:47:38 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3C221F8514 for ; Sat, 10 Mar 2012 16:47:36 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2B0lEd1029337; Sun, 11 Mar 2012 00:47:14 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2B0lEd1029337 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1331426835; bh=V89YS2nRj7R0l5z8RhhQta2CZCU=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=wHUWoyMvf5LVGkYOb9dUZpQQgN3LC+r5DSKIA4KSek1tgcQskrzw4DQ4p0PIlNxV5 T5251CGHED23QO+AM3Zsw41PB+GOYfETo8TNmwW/Nf7MJ+uXYikskl5J7hYbFBQAR0 EBnzJoS00g85fnLtPdBmVCOX1A0sodS5MpSDY6JY= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o2A0lE0543725042FQ ret-id none; Sun, 11 Mar 2012 00:47:15 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2B0l5Iw031424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Mar 2012 00:47:05 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Chown In-Reply-To: <4F5BE96C.8040204@gmail.com> Date: Sun, 11 Mar 2012 00:47:05 +0000 Content-Transfer-Encoding: 7bit Message-ID: References: <4F5A2929.4010802@freedesktop.org> <4F5A521B.9030601@gmail.com> <4F5A5D2F.5030302@cisco.com> <4F5BA45A.9040100@gmail.com> <4F5BE96C.8040204@gmail.com> <6B178F93-2E36-4994-89C4-6BA84698311D@ecs.soton.ac.uk> To: Brian E Carpenter X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2A0lE054372504200; tid=o2A0lE0543725042FQ; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=9:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2B0lEd1029337 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Kerry Lynn , Michael Richardson , paduffy@cisco.com, Jason Livingood , Dave Taht , Jim Gettys , homenet@ietf.org, David Harrington Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 00:47:40 -0000 On 10 Mar 2012, at 23:53, Brian E Carpenter wrote: > Cutting to the chase (and this answers Don too): > >> There may be good reasons to consider SLP, but I'd >> like to see how these line up against the home net goals. > > Exactly. It's perfectly fine by me if SLP is not the right > answer for future homenets, but this should be a goal-based > decision, not based on what happens to be deployed on > single-subnet homenets today. Indeed; the arch text is capturing those goals, so some discussion and definition of those is very welcome. Tim > > Regards > Brian > > On 2012-03-11 11:02, Kerry Lynn wrote: >> On Sat, Mar 10, 2012 at 10:58 AM, Brian E Carpenter >> wrote: >>> On 2012-03-10 08:42, Paul Duffy wrote: >>>> On 3/9/2012 1:55 PM, Brian E Carpenter wrote: >>>>> On 2012-03-10 05:00, Jim Gettys wrote: >>>>> ... >>>>>> I was just observing comments I came across in code being used for >>>>>> printer discovery. >>>>> Why would we consider anything other than SLP for service discovery? >>>> Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more >>>> traction in the consumer space than SLP. >>>> >>>> Please do correct if I'm wrong. >>> Aren't we trying to influence the future rather than document the >>> past? >>> >> Brian, >> >> I'm not sure of your point; mDNS and DNS-SD are Standards Track >> drafts currently in the RFC-Editor queue and there are tens of millions >> of deployed mDNS responders. If SLP is running in my home, I'm >> not aware of it. >> >>> We need a name-based service discovery solution. That's also a >>> requirement emerging from 6renum. I think we should decide what's >>> the best recommendation; it may end up being DNS-based, but this >>> is what SLP was designed for, so IMHO it should be considered. >>> >> Just as homenet has "Largest Possible Subnets", "Fewest Topology >> Assumptions", and "Self Organizing" principles, perhaps we should >> also consider "Fewest Protocols" as well. To my mind, using DNS for >> both service discovery and name resolution has many advantages. >> These are documented in the above mentioned drafts, but I would >> just point out three: simple DNS-based discovery is trivial to add to >> an existing resolver, mDNS has been demonstrated in constrained >> environments (e.g. it places limits on name length and character >> set), and it is based on a well-understood (and well-supported) >> protocol. There may be good reasons to consider SLP, but I'd >> like to see how these line up against the home net goals. >> >> I will add that I've co-authored a draft that considers extending mDNS >> to site scope and would like to receive any comments people have: >> https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/ >> >> Thanks, -K- >> >>> This is clearly *not* what SNMP was designed for. >>> >>> Brian >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Sat Mar 10 17:05:56 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5013921F8545 for ; Sat, 10 Mar 2012 17:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] 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 iTJ7JN59m+uu for ; Sat, 10 Mar 2012 17:05:55 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 713F521F84EE for ; Sat, 10 Mar 2012 17:05:55 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2B15qBO032670 for ; Sun, 11 Mar 2012 01:05:52 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2B15qBO032670 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1331427952; bh=OsJHcw3hRZT2gm7MUwMPWu+exH0=; h=From:Subject:Date:To:Mime-Version:References; b=WhA6ZqMPKTzyaX57L16r9mgKZBDPXW9K0nDV15/v9fNNLsQHlSTiCdc3GrVBz9FUY GJ7fdjhPfpAUd/SXw6dicFVymLWrqDFcqol+V+g8jZHoXbwqZ5qMqOJehbAA18VY8s Ldonz8eINSxXkOv1S2SkKx1wHUvk6k7pQq12tYcI= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o2A15q0543725136R7 ret-id none; Sun, 11 Mar 2012 01:05:52 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2B14XaX002448 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 11 Mar 2012 01:04:34 GMT From: Tim Chown Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 11 Mar 2012 01:04:33 +0000 Message-ID: To: "homenet@ietf.org Group" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2A15q054372513600; tid=o2A15q0543725136R7; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2B15qBO032670 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 01:05:56 -0000 It's good to see some traction in service discovery and naming. We also have a fifth area, security. The text as it stands says a few things that apply to this area, e.g. a) An assumption of "Simple Security" with default deny on the CER. This implies PCP or uPnP to support punching holes. The text also talks about addressability vs reachability. b) Mention of appropriate mechanisms for users to associate devices, and that devices may need keys configured, e.g. WPA2. So we should be aiming for these tasks to be as simple as possible. c) The possibility to say that a ULA source indicates a connection within the home. Suggested by Chris Palmer in Quebec, but not discussed since. d) Mention of "Advanced Security", which talks about the ability to install 3rd party policies. Some have suggested removing this from the initial homenet spec. e) Discussion of (determination of) network borders; these are points at which policies may apply. In the "self-configuring" section we talk more on that task. Homenets may have internal policy borders, e.g. between private and guest areas. There's certainly scope to put down more in the way of goals; any comments in this area are welcome. Tim From d.sturek@att.net Sat Mar 10 17:25:24 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C40C21F8549 for ; Sat, 10 Mar 2012 17:25:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4vKQyRQK7jy for ; Sat, 10 Mar 2012 17:25:23 -0800 (PST) Received: from nm31-vm4.bullet.mail.ne1.yahoo.com (nm31-vm4.bullet.mail.ne1.yahoo.com [98.138.229.44]) by ietfa.amsl.com (Postfix) with SMTP id 3E04121F8545 for ; Sat, 10 Mar 2012 17:25:23 -0800 (PST) Received: from [98.138.90.51] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 11 Mar 2012 01:25:19 -0000 Received: from [68.142.200.227] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 11 Mar 2012 01:25:19 -0000 Received: from [66.94.237.116] by t8.bullet.mud.yahoo.com with NNFMP; 11 Mar 2012 01:25:18 -0000 Received: from [127.0.0.1] by omp1021.access.mail.mud.yahoo.com with NNFMP; 11 Mar 2012 01:25:18 -0000 X-Yahoo-Newman-Id: 886284.29018.bm@omp1021.access.mail.mud.yahoo.com Received: (qmail 46387 invoked from network); 11 Mar 2012 01:25:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1331429118; bh=FQD2+PHVVFoa7ZSI0ipct7JD8dw3WSJed/kfz/nkA+c=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=ibwHdrax/xpHg6Gcki6iEB1WnMRV9ph77HA08yKFZ75yP3QyeziH2ZtNUa8Lf+7haqWYqtEjujR4fxWHQkWOVYYY4bFqHYgewX32njIBesjRBDOVGdIef/f1InPtJADZLLbnIPec6QRFVNp01hGcYBmI2jPCkxEW7P86k8+DZBg= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6r5.AT8VM1mIS1hYsgxvwcOnqYdq9QJYz1B50OKjrcpA4Jl UO2aw5SrY3WE_F2IoOpPr7xu2hrUsXQ1UKE7K54y5Ldv5J0axOtjrxDQdYaO hsHWCi4fYI9wvy8BAO9plZ8fHapKDPX6Pier1EkZGWpxHxwLfhIRQe5mnWbC vo52Vnz7_rSGSHF8y0.kVr1axnF6UCcd9nXtgP3UiMnLXozrcbFkAN7ayT4N 6HN3Iy5u3y0ILy0dYGlBm3g8PC7gLW1u6lvsbVNn4TtarAM7odEnwws2JUG9 XHYDirIQ6qG1dXO58dSrhRrD920L.cuYvMw9qu5RGj.G7AqFpnyKsq5_qqLG AyeDiK4IEC_RcZECTYFUyjqG_8JK2FXdJQWq6Wu90NDuahq5VL03jpnmL2on JoJOIJHNEDCczPGwOddaU6ZJjKUnCQgF3kZ9oPnSNuRm_pIu1wJUiqoRY01y px_K4.eBnfrGUvJMQX.TPqlnN5uhKteL9qbGdWVdSe93Rcg-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.196] (d.sturek@69.224.123.193 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 10 Mar 2012 17:25:18 -0800 PST User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Sat, 10 Mar 2012 17:25:11 -0800 From: Don Sturek To: Brian E Carpenter , Kerry Lynn Message-ID: Thread-Topic: [homenet] Discovery [snmp for monitoring home network] In-Reply-To: <4F5BE96C.8040204@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Michael Richardson , paduffy@cisco.com, Jason Livingood , Dave Taht , Jim Gettys , homenet@ietf.org, David Harrington Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 01:25:24 -0000 Hi Brian, To be honest, I was not wedded to mDNS (or xmDNS though I am down as the author) but frankly that or uPnP seemed to be the only game in town when we made our selection. I was actually told by several people to avoid SLP since it was deployed in no real numbers anywhere and the code base was considered large for the devices we were targeting (I have to say the deployment numbers and experience we the main deciding factors, not the limited code size numbers.....). I would be happy to be proved wrong but it does seem that mDNS and uPnP seem to be the solutions with traction and deployment experience. If Homenet wants to go down the SLP path then I think we (the Homenet group) need to provide justification on why that choice is better than what is currently deployed. Don On 3/10/12 3:53 PM, "Brian E Carpenter" wrote: >Cutting to the chase (and this answers Don too): > >> There may be good reasons to consider SLP, but I'd >> like to see how these line up against the home net goals. > >Exactly. It's perfectly fine by me if SLP is not the right >answer for future homenets, but this should be a goal-based >decision, not based on what happens to be deployed on >single-subnet homenets today. > >Regards > Brian > >On 2012-03-11 11:02, Kerry Lynn wrote: >> On Sat, Mar 10, 2012 at 10:58 AM, Brian E Carpenter >> wrote: >>> On 2012-03-10 08:42, Paul Duffy wrote: >>>> On 3/9/2012 1:55 PM, Brian E Carpenter wrote: >>>>> On 2012-03-10 05:00, Jim Gettys wrote: >>>>> ... >>>>>> I was just observing comments I came across in code being used for >>>>>> printer discovery. >>>>> Why would we consider anything other than SLP for service discovery? >>>> Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more >>>> traction in the consumer space than SLP. >>>> >>>> Please do correct if I'm wrong. >>> Aren't we trying to influence the future rather than document the >>> past? >>> >> Brian, >> >> I'm not sure of your point; mDNS and DNS-SD are Standards Track >> drafts currently in the RFC-Editor queue and there are tens of millions >> of deployed mDNS responders. If SLP is running in my home, I'm >> not aware of it. >> >>> We need a name-based service discovery solution. That's also a >>> requirement emerging from 6renum. I think we should decide what's >>> the best recommendation; it may end up being DNS-based, but this >>> is what SLP was designed for, so IMHO it should be considered. >>> >> Just as homenet has "Largest Possible Subnets", "Fewest Topology >> Assumptions", and "Self Organizing" principles, perhaps we should >> also consider "Fewest Protocols" as well. To my mind, using DNS for >> both service discovery and name resolution has many advantages. >> These are documented in the above mentioned drafts, but I would >> just point out three: simple DNS-based discovery is trivial to add to >> an existing resolver, mDNS has been demonstrated in constrained >> environments (e.g. it places limits on name length and character >> set), and it is based on a well-understood (and well-supported) >> protocol. There may be good reasons to consider SLP, but I'd >> like to see how these line up against the home net goals. >> >> I will add that I've co-authored a draft that considers extending mDNS >> to site scope and would like to receive any comments people have: >> https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/ >> >> Thanks, -K- >> >>> This is clearly *not* what SNMP was designed for. >>> >>> Brian >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From rturner@amalfisystems.com Sat Mar 10 18:19:12 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092AB21F8550 for ; Sat, 10 Mar 2012 18:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] 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 MEJ0fhvqVYTM for ; Sat, 10 Mar 2012 18:19:11 -0800 (PST) Received: from omr15.networksolutionsemail.com (omr15.networksolutionsemail.com [205.178.146.65]) by ietfa.amsl.com (Postfix) with ESMTP id DDC4C21F8554 for ; Sat, 10 Mar 2012 18:19:10 -0800 (PST) Received: from cm-omr4 (mail.networksolutionsemail.com [205.178.146.50]) by omr15.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2B2J9m2023925 for ; Sat, 10 Mar 2012 21:19:09 -0500 Authentication-Results: cm-omr4 smtp.user=rturner@amalfisystems.com; auth=pass (CRAM-MD5) X-Authenticated-UID: rturner@amalfisystems.com Received: from [98.151.18.158] ([98.151.18.158:50471] helo=[192.168.1.114]) by cm-omr4 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES128-SHA) id 98/50-14799-D9B0C5F4; Sat, 10 Mar 2012 21:19:09 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1257) From: Randy Turner In-Reply-To: Date: Sat, 10 Mar 2012 18:19:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8C6DD064-D89A-4098-901F-0C60D95EEFC5@amalfisystems.com> References: To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1257) Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 02:19:12 -0000 Zero configuration seems to be a goal of our work=85it would be = unfortunate if the output of the previous IETF "zeroconf" WG wasn't put = to good use, or if not sufficient, extended. Randy On Mar 10, 2012, at 5:25 PM, Don Sturek wrote: > Hi Brian, >=20 > To be honest, I was not wedded to mDNS (or xmDNS though I am down as = the > author) but frankly that or uPnP seemed to be the only game in town = when > we made our selection. >=20 > I was actually told by several people to avoid SLP since it was = deployed > in no real numbers anywhere and the code base was considered large for = the > devices we were targeting (I have to say the deployment numbers and > experience we the main deciding factors, not the limited code size > numbers.....). >=20 > I would be happy to be proved wrong but it does seem that mDNS and = uPnP > seem to be the solutions with traction and deployment experience. >=20 > If Homenet wants to go down the SLP path then I think we (the Homenet > group) need to provide justification on why that choice is better than > what is currently deployed. >=20 > Don >=20 >=20 >=20 >=20 >=20 > On 3/10/12 3:53 PM, "Brian E Carpenter" > wrote: >=20 >> Cutting to the chase (and this answers Don too): >>=20 >>> There may be good reasons to consider SLP, but I'd >>> like to see how these line up against the home net goals. >>=20 >> Exactly. It's perfectly fine by me if SLP is not the right >> answer for future homenets, but this should be a goal-based >> decision, not based on what happens to be deployed on >> single-subnet homenets today. >>=20 >> Regards >> Brian >>=20 >> On 2012-03-11 11:02, Kerry Lynn wrote: >>> On Sat, Mar 10, 2012 at 10:58 AM, Brian E Carpenter >>> wrote: >>>> On 2012-03-10 08:42, Paul Duffy wrote: >>>>> On 3/9/2012 1:55 PM, Brian E Carpenter wrote: >>>>>> On 2012-03-10 05:00, Jim Gettys wrote: >>>>>> ... >>>>>>> I was just observing comments I came across in code being used = for >>>>>>> printer discovery. >>>>>> Why would we consider anything other than SLP for service = discovery? >>>>> Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more >>>>> traction in the consumer space than SLP. >>>>>=20 >>>>> Please do correct if I'm wrong. >>>> Aren't we trying to influence the future rather than document the >>>> past? >>>>=20 >>> Brian, >>>=20 >>> I'm not sure of your point; mDNS and DNS-SD are Standards Track >>> drafts currently in the RFC-Editor queue and there are tens of = millions >>> of deployed mDNS responders. If SLP is running in my home, I'm >>> not aware of it. >>>=20 >>>> We need a name-based service discovery solution. That's also a >>>> requirement emerging from 6renum. I think we should decide what's >>>> the best recommendation; it may end up being DNS-based, but this >>>> is what SLP was designed for, so IMHO it should be considered. >>>>=20 >>> Just as homenet has "Largest Possible Subnets", "Fewest Topology >>> Assumptions", and "Self Organizing" principles, perhaps we should >>> also consider "Fewest Protocols" as well. To my mind, using DNS for >>> both service discovery and name resolution has many advantages. >>> These are documented in the above mentioned drafts, but I would >>> just point out three: simple DNS-based discovery is trivial to add = to >>> an existing resolver, mDNS has been demonstrated in constrained >>> environments (e.g. it places limits on name length and character >>> set), and it is based on a well-understood (and well-supported) >>> protocol. There may be good reasons to consider SLP, but I'd >>> like to see how these line up against the home net goals. >>>=20 >>> I will add that I've co-authored a draft that considers extending = mDNS >>> to site scope and would like to receive any comments people have: >>> https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/ >>>=20 >>> Thanks, -K- >>>=20 >>>> This is clearly *not* what SNMP was designed for. >>>>=20 >>>> Brian >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 From mellon@fugue.com Sat Mar 10 19:38:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9C721F85E5 for ; Sat, 10 Mar 2012 19:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 svi1ClH3unXQ for ; Sat, 10 Mar 2012 19:38:26 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7659021F85E4 for ; Sat, 10 Mar 2012 19:38:26 -0800 (PST) Received: from [IPv6:2001:470:1f07:1486:1512:ae20:350f:77a3] (unknown [IPv6:2001:470:1f07:1486:1512:ae20:350f:77a3]) by toccata.fugue.com (Postfix) with ESMTPSA id 95F90238218C; Sat, 10 Mar 2012 22:38:18 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_07FD0F0C-35D9-4902-B3E1-2C813B7E067E" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Ted Lemon In-Reply-To: <8C6DD064-D89A-4098-901F-0C60D95EEFC5@amalfisystems.com> Date: Sat, 10 Mar 2012 22:38:17 -0500 Message-Id: References: <8C6DD064-D89A-4098-901F-0C60D95EEFC5@amalfisystems.com> To: Randy Turner X-Mailer: Apple Mail (2.1426) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 03:38:27 -0000 --Apple-Mail=_07FD0F0C-35D9-4902-B3E1-2C813B7E067E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 10, 2012, at 9:19 PM, Randy Turner = wrote: > it would be unfortunate if the output of the previous IETF "zeroconf" = WG wasn't put to good use, or if not sufficient, extended. Why do you say that? --Apple-Mail=_07FD0F0C-35D9-4902-B3E1-2C813B7E067E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=windows-1252
On Mar 10, 2012, at 9:19 PM, Randy Turner <rturner@amalfisystems.com> wrote:
it would be unfortunate if the output of the previous IETF "zeroconf" WG wasn't put to good use, or if not sufficient, extended.

Why do you say that?

--Apple-Mail=_07FD0F0C-35D9-4902-B3E1-2C813B7E067E-- From rturner@amalfisystems.com Sat Mar 10 19:51:13 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C6521F85FD for ; Sat, 10 Mar 2012 19:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 WohNUgzBgsil for ; Sat, 10 Mar 2012 19:51:13 -0800 (PST) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id 1413A21F85FB for ; Sat, 10 Mar 2012 19:51:10 -0800 (PST) Received: from cm-omr2 ([205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q2B3pA5J010767 for ; Sat, 10 Mar 2012 22:51:10 -0500 Authentication-Results: cm-omr2 smtp.user=rturner@amalfisystems.com; auth=pass (CRAM-MD5) X-Authenticated-UID: rturner@amalfisystems.com Received: from [98.151.18.158] ([98.151.18.158:51335] helo=[192.168.1.114]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES128-SHA) id F6/D0-09323-D212C5F4; Sat, 10 Mar 2012 22:51:10 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_B97A83FF-4663-4605-AD30-E008FE2EF7A0" From: Randy Turner In-Reply-To: Date: Sat, 10 Mar 2012 19:51:10 -0800 Message-Id: <30070A42-71DA-49E1-B4BB-D53D552FDC49@amalfisystems.com> References: <8C6DD064-D89A-4098-901F-0C60D95EEFC5@amalfisystems.com> To: Ted Lemon X-Mailer: Apple Mail (2.1257) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 03:51:13 -0000 --Apple-Mail=_B97A83FF-4663-4605-AD30-E008FE2EF7A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Just seems like the IETF has tried to address one of our requirements = (zero configuration) in the past -- if the IETF has already published = proposed standards for zero configuration, why wouldn't we look at this = first? Or at least "cherry pick" what we like from this effort. R. On Mar 10, 2012, at 7:38 PM, Ted Lemon wrote: > On Mar 10, 2012, at 9:19 PM, Randy Turner = wrote: >> it would be unfortunate if the output of the previous IETF "zeroconf" = WG wasn't put to good use, or if not sufficient, extended. >=20 > Why do you say that? >=20 --Apple-Mail=_B97A83FF-4663-4605-AD30-E008FE2EF7A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
R.

On Mar 10, = 2012, at 7:38 PM, Ted Lemon wrote:

On Mar 10, 2012, at = 9:19 PM, Randy Turner <rturner@amalfisystems.com>= ; wrote:
it would = be unfortunate if the output of the previous IETF "zeroconf" WG wasn't = put to good use, or if not sufficient, = extended.

Why do you say = that?


= = --Apple-Mail=_B97A83FF-4663-4605-AD30-E008FE2EF7A0-- From mellon@fugue.com Sat Mar 10 20:12:17 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F289E21F861C for ; Sat, 10 Mar 2012 20:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 bBms+xemftxn for ; Sat, 10 Mar 2012 20:12:16 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 802A821F8624 for ; Sat, 10 Mar 2012 20:12:16 -0800 (PST) Received: from [IPv6:2001:470:1f07:1486:1512:ae20:350f:77a3] (unknown [IPv6:2001:470:1f07:1486:1512:ae20:350f:77a3]) by toccata.fugue.com (Postfix) with ESMTPSA id A08202382192; Sat, 10 Mar 2012 23:12:14 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C4DC964-3E60-4717-BDDB-DE9FC35559ED" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Ted Lemon In-Reply-To: <30070A42-71DA-49E1-B4BB-D53D552FDC49@amalfisystems.com> Date: Sat, 10 Mar 2012 23:12:13 -0500 Message-Id: References: <8C6DD064-D89A-4098-901F-0C60D95EEFC5@amalfisystems.com> <30070A42-71DA-49E1-B4BB-D53D552FDC49@amalfisystems.com> To: Randy Turner X-Mailer: Apple Mail (2.1426) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 04:12:17 -0000 --Apple-Mail=_0C4DC964-3E60-4717-BDDB-DE9FC35559ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Mar 10, 2012, at 10:51 PM, Randy Turner = wrote: > Just seems like the IETF has tried to address one of our requirements = (zero configuration) in the past -- if the IETF has already published = proposed standards for zero configuration, why wouldn't we look at this = first? Or at least "cherry pick" what we like from this effort. I think it would be better to decide what problem we are trying to = solve, and then think about how we'd like to solve it, and then see if = there are solutions available that we can leverage to solve the problem, = rather than predisposing any decision-making process towards choosing = the output of the zeroconf working group. Certainly it would be = irresponsible to entirely fail to consider zeroconf work, but the = problems it set out to solve, and the way it solved them, are not = particularly applicable to the homenet scenario. If you use zeroconf = work as a starting point, you probably won't get to a very satisfying = destination. --Apple-Mail=_0C4DC964-3E60-4717-BDDB-DE9FC35559ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 rturner@amalfisystems.com>= ; wrote:
Just seems = like the IETF has tried to address one of our requirements (zero = configuration) in the past -- if the IETF has already published proposed = standards for zero configuration, why wouldn't we look at this first? =  Or at least "cherry pick" what we like from this = effort.

I think it would be = better to decide what problem we are trying to solve, and then think = about how we'd like to solve it, and then see if there are solutions = available that we can leverage to solve the problem, rather than = predisposing any decision-making process towards choosing the output of = the zeroconf working group.   Certainly it would be irresponsible = to entirely fail to consider zeroconf work, but the problems it set out = to solve, and the way it solved them, are not particularly applicable to = the homenet scenario.   If you use zeroconf work as a starting = point, you probably won't get to a very satisfying = destination.

= --Apple-Mail=_0C4DC964-3E60-4717-BDDB-DE9FC35559ED-- From rturner@amalfisystems.com Sat Mar 10 20:24:39 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AEC21F85C5 for ; Sat, 10 Mar 2012 20:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 fgYDHFzhiRK7 for ; Sat, 10 Mar 2012 20:24:39 -0800 (PST) Received: from omr4.networksolutionsemail.com (omr4.networksolutionsemail.com [205.178.146.54]) by ietfa.amsl.com (Postfix) with ESMTP id E337E21F8598 for ; Sat, 10 Mar 2012 20:24:38 -0800 (PST) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q2B4OcO3022986 for ; Sat, 10 Mar 2012 23:24:38 -0500 Authentication-Results: cm-omr3 smtp.user=rturner@amalfisystems.com; auth=pass (CRAM-MD5) X-Authenticated-UID: rturner@amalfisystems.com Received: from [98.151.18.158] ([98.151.18.158:51423] helo=[192.168.1.114]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES128-SHA) id 7A/D9-25783-5092C5F4; Sat, 10 Mar 2012 23:24:38 -0500 From: Randy Turner Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C0CBC6E-CDC4-40C1-9BFE-701AA7232EE1" Date: Sat, 10 Mar 2012 20:24:38 -0800 In-Reply-To: To: "homenet@ietf.org Group" References: <8C6DD064-D89A-4098-901F-0C60D95EEFC5@amalfisystems.com> <30070A42-71DA-49E1-B4BB-D53D552FDC49@amalfisystems.com> Message-Id: <030DD7ED-5924-413B-8705-7B76491D0EA9@amalfisystems.com> X-Mailer: Apple Mail (2.1257) Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 04:24:39 -0000 --Apple-Mail=_0C0CBC6E-CDC4-40C1-9BFE-701AA7232EE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 According to the zeroconf charter, home networking and SOHO environments = were a primary target of the zeroconf work. I don't think the zeroconf = and homenet scenarios are as divergent as you indicate, but I agree on = letting things play out a bit more to determine the problem(s) we're = trying to solve.=20 R. On Mar 10, 2012, at 8:12 PM, Ted Lemon wrote: > On Mar 10, 2012, at 10:51 PM, Randy Turner = wrote: >> Just seems like the IETF has tried to address one of our requirements = (zero configuration) in the past -- if the IETF has already published = proposed standards for zero configuration, why wouldn't we look at this = first? Or at least "cherry pick" what we like from this effort. >=20 >=20 > I think it would be better to decide what problem we are trying to = solve, and then think about how we'd like to solve it, and then see if = there are solutions available that we can leverage to solve the problem, = rather than predisposing any decision-making process towards choosing = the output of the zeroconf working group. Certainly it would be = irresponsible to entirely fail to consider zeroconf work, but the = problems it set out to solve, and the way it solved them, are not = particularly applicable to the homenet scenario. If you use zeroconf = work as a starting point, you probably won't get to a very satisfying = destination. >=20 --Apple-Mail=_0C0CBC6E-CDC4-40C1-9BFE-701AA7232EE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Mar 10, 2012, at = 10:51 PM, Randy Turner <rturner@amalfisystems.com>= ; wrote:
Just seems = like the IETF has tried to address one of our requirements (zero = configuration) in the past -- if the IETF has already published proposed = standards for zero configuration, why wouldn't we look at this first? =  Or at least "cherry pick" what we like from this = effort.

I think it would be = better to decide what problem we are trying to solve, and then think = about how we'd like to solve it, and then see if there are solutions = available that we can leverage to solve the problem, rather than = predisposing any decision-making process towards choosing the output of = the zeroconf working group.   Certainly it would be irresponsible = to entirely fail to consider zeroconf work, but the problems it set out = to solve, and the way it solved them, are not particularly applicable to = the homenet scenario.   If you use zeroconf work as a starting = point, you probably won't get to a very satisfying = destination.


= --Apple-Mail=_0C0CBC6E-CDC4-40C1-9BFE-701AA7232EE1-- From kerlyn2001@gmail.com Sat Mar 10 20:33:43 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA08721F858D for ; Sat, 10 Mar 2012 20:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] 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 ld2lKBTt4jyn for ; Sat, 10 Mar 2012 20:33:43 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B24821F85D6 for ; Sat, 10 Mar 2012 20:33:42 -0800 (PST) Received: by lagj5 with SMTP id j5so3266783lag.31 for ; Sat, 10 Mar 2012 20:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WpiyTYUghpRWWRaJxZ0N9V3WMQsbGRwQN0yX4n37wM4=; b=QskdwuMachw0YooNWEJtAeJ2ZRINilJ8RWAOKish8jKQUiqa4INCQkgQWFGVF5Wn8l 88Rgt5kbLiW4pSMqGPnVf86JCNH7g9zM51f+zIfQx8iaUCqq8Q6IkAubHEv26OzJ02cO nKs7YtWjaD0nuV4ELubEF2SOOYneGzgMLuv3MwTX5cZlpcNgP4Dyqx6h4pIcm3Cy6Khr QYEDQxun6xQAy5aVJm/nn6dV4tRVHbm94aGl7Ck5jaHQy0iE+TJ44T6TtvjV2cD8NLVG 0sGEm3T102ujZKRAYFk3zG4revWX50b2h1dZDd8z686EXb0itI7+zlO2PYUPu9GGdzVJ 9QKA== MIME-Version: 1.0 Received: by 10.152.103.239 with SMTP id fz15mr5737654lab.42.1331440421508; Sat, 10 Mar 2012 20:33:41 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.112.77.179 with HTTP; Sat, 10 Mar 2012 20:33:41 -0800 (PST) In-Reply-To: <30070A42-71DA-49E1-B4BB-D53D552FDC49@amalfisystems.com> References: <8C6DD064-D89A-4098-901F-0C60D95EEFC5@amalfisystems.com> <30070A42-71DA-49E1-B4BB-D53D552FDC49@amalfisystems.com> Date: Sat, 10 Mar 2012 20:33:41 -0800 X-Google-Sender-Auth: 7WcxxIuqiypi-SJzgOVHiy1dXPk Message-ID: From: Kerry Lynn To: Randy Turner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 04:33:44 -0000 On Sat, Mar 10, 2012 at 7:51 PM, Randy Turner w= rote: > > Just seems like the IETF has tried to address one of our requirements (ze= ro > configuration) in the past -- if the IETF has already published proposed > standards for zero configuration, why wouldn't we look at this first? =A0= Or at > least "cherry pick" what we like from this effort. > > R. > This seems like a good place to briefly describe the mDNS extensions we proposed in https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/ LLNs are a primary target. Since an LLN's definition of "link-local" means first-hop neighbors, the first change is to use the site-local multicast address FF05::FB to make sure the whole mesh is covered. Next, since the behavior of name resolution for .local names is completely defined by the mDNS draft (and tens of millions of extant resolvers) we decided to define another special TLD .site. As there are currently no legacy implementations, we have some latitude to modify the way certain fields like hop limit are used. When it comes to routing behavior, there are three possibilities: a router *always* forwards xmDNS out the other "in scope" ports (e.g. this is the defined behavior of interior mesh nodes), a router *never* forwards xmDNS (e.g. across the HAN/ISP border), or it *may* forward xmDNS. This last one is tricky one. The xmDNS draft does not take a position (yet, anyway) on how to define a site boundary. It may be that there are several in a single homenet. We probably don't want LLNs to be over- whelmed by discovery packets from an adjacent ethernet link and might choose to put a proxy there instead; one that selectively forwards requests or at least shapes the traffic at that border. I note that the current arch draft is virtually silent on the matter of mul= ti- cast forwarding. It seems to me that we really must ultimately declare multicast forwarding to in or out of scope. I favor the former, since we should anticipate applications like multi-player online games or media distribution inside the home. One possible candidate is MLD Proxy (RFC 4605) but then we'd have to come up with a way to form a tree. -K- From kerlyn2001@gmail.com Sat Mar 10 20:40:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE3621F85F1 for ; Sat, 10 Mar 2012 20:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 wKcO6-2f7vz3 for ; Sat, 10 Mar 2012 20:40:14 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD0A21F85DD for ; Sat, 10 Mar 2012 20:40:13 -0800 (PST) Received: by lagj5 with SMTP id j5so3268583lag.31 for ; Sat, 10 Mar 2012 20:40:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VZ414I/FEqmX5mrEntGKUKKPJhaawlEC24UutxaPt4E=; b=m/cauM/0LTTG7UmM2bSbvrJkuFwGyTWwgMgaEGnGVMFO2Jnyv0UfYHKtLxjTC5xqUI wwY/3pfqBM60d6mL8LBB+/eIYqakj/ZNL7d/wv2UEaHffYNu5jNfryU1iPARUhPbM3We XLJJZRJD1iP+Vo0Uc4u7ZdtBjWRtRWVWPfk94z/1luOXhDqiFxnS3CGws4N/48RNR7D1 MEs1pQN9G0IZzl8eAI8vWAFqewEg0nnsr7VxRRivK42gdlfJdOCVPMZtTg4Y8gfVbC5Y cm8Lsg0W2HLm124BvbHpu4mS+jeXKwl+R25piFOGQARoQAcQpbrEfNq+r2FMm5WkLv/i 2Jfw== MIME-Version: 1.0 Received: by 10.112.38.195 with SMTP id i3mr2584079lbk.21.1331440813027; Sat, 10 Mar 2012 20:40:13 -0800 (PST) Sender: kerlyn2001@gmail.com Received: by 10.112.77.179 with HTTP; Sat, 10 Mar 2012 20:40:12 -0800 (PST) In-Reply-To: References: <8C6DD064-D89A-4098-901F-0C60D95EEFC5@amalfisystems.com> <30070A42-71DA-49E1-B4BB-D53D552FDC49@amalfisystems.com> Date: Sat, 10 Mar 2012 20:40:12 -0800 X-Google-Sender-Auth: 56Od-c12rbtWZKYFLO1cBIw_vxE Message-ID: From: Kerry Lynn To: Ted Lemon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Randy Turner , "homenet@ietf.org Group" Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 04:40:15 -0000 On Sat, Mar 10, 2012 at 8:12 PM, Ted Lemon wrote: > On Mar 10, 2012, at 10:51 PM, Randy Turner > wrote: > > Just seems like the IETF has tried to address one of our requirements (ze= ro > configuration) in the past -- if the IETF has already published proposed > standards for zero configuration, why wouldn't we look at this first? =A0= Or at > least "cherry pick" what we like from this effort. > > > I think it would be better to decide what problem we are trying to solve, > and then think about how we'd like to solve it, and then see if there are > solutions available that we can leverage to solve the problem, rather tha= n > predisposing any decision-making process towards choosing the output of t= he > zeroconf working group. =A0 Certainly it would be irresponsible to entire= ly > fail to consider zeroconf work, but the problems it set out to solve, and > the way it solved them, are not particularly applicable to the homenet > scenario. =A0 If you use zeroconf work as a starting point, you probably = won't > get to a very satisfying destination. > I think Ralph offered an initial set of requirements for Naming and Service Discovery. Do you have additional requirements to add, or think that any of Ralph's points are out of scope? IOW, what's the consensus opinion on the "problem we are trying to solve"? > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From cb.list6@gmail.com Sat Mar 10 21:28:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1377321F869A for ; Sat, 10 Mar 2012 21:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 2XhzMp18pX0R for ; Sat, 10 Mar 2012 21:28:04 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5F83621F8699 for ; Sat, 10 Mar 2012 21:28:04 -0800 (PST) Received: by dakl33 with SMTP id l33so3752572dak.31 for ; Sat, 10 Mar 2012 21:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ExqwD67StkWdZ9+uHuwq+L73KTzclmmdHiNvEbFa8+Y=; b=SZz2eTiSLyJJydEegLoGBEyJJmpUr6H/vLhKVFaUXnnvNGjTICG98DkDNZpAUq3jbi FHlPl7x3P/Dkm3FzlCHDcnSfF+i6G8H4Xw1rgSdR8MisVEPBvpKvasYdYGnOCXzkOGh/ OIo5YWenJG/nrWmYyWWI5th1RC+wSdFFfElqlfF4145csWK2mKWNarXBUKD95AWyzMzm bzvalH/KZLU9lTNrW+TATIOJ2J9INhX0par0iU0YyHzM5E2AJEUvWo5Qx37qKzeEiTYK NsIR6E/W9bZ6ZZA9wtTxXNJG2HkC5AKaRnpxBTQ8ZXv5NQSS1BCbKZ0lTAe2RhIG0zys mrCA== MIME-Version: 1.0 Received: by 10.68.129.100 with SMTP id nv4mr12212947pbb.109.1331443684196; Sat, 10 Mar 2012 21:28:04 -0800 (PST) Received: by 10.142.163.16 with HTTP; Sat, 10 Mar 2012 21:28:03 -0800 (PST) Received: by 10.142.163.16 with HTTP; Sat, 10 Mar 2012 21:28:03 -0800 (PST) In-Reply-To: References: Date: Sat, 10 Mar 2012 21:28:03 -0800 Message-ID: From: Cameron Byrne To: Tim Chown Content-Type: multipart/alternative; boundary=047d7b11178dd5c28f04baf0e3c3 Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 05:28:05 -0000 --047d7b11178dd5c28f04baf0e3c3 Content-Type: text/plain; charset=ISO-8859-1 On Mar 10, 2012 5:05 PM, "Tim Chown" wrote: > > It's good to see some traction in service discovery and naming. > > We also have a fifth area, security. The text as it stands says a few > things that apply to this area, e.g. > > a) An assumption of "Simple Security" with default deny on the CER. > This implies PCP or uPnP to support punching holes. The text > also talks about addressability vs reachability. > I still disagree with this premise that we must default deny and have a mess of inadequate and complex signalling to compensate . Can someone articulate a threat model that requires this default deny and state tracking ? Or must we put the cart before the horse without facts presented (maybe I missed that detailed presentation of threats) ? Because win2k required a network based firewall, we must always cripple e2e? Or, can homenet simply say home devices must be independently secure, may have host based firewalls, or they must be placed in a properly screened subnet of fundamentally flawed devices that require network security controls and multi device port coordination ? Cb > b) Mention of appropriate mechanisms for users to associate > devices, and that devices may need keys configured, e.g. WPA2. > So we should be aiming for these tasks to be as simple as possible. > > c) The possibility to say that a ULA source indicates a connection > within the home. Suggested by Chris Palmer in Quebec, but not > discussed since. > > d) Mention of "Advanced Security", which talks about the ability to > install 3rd party policies. Some have suggested removing this > from the initial homenet spec. > > e) Discussion of (determination of) network borders; these are > points at which policies may apply. In the "self-configuring" > section we talk more on that task. Homenets may have internal > policy borders, e.g. between private and guest areas. > > There's certainly scope to put down more in the way of goals; any > comments in this area are welcome. > > Tim > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --047d7b11178dd5c28f04baf0e3c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 10, 2012 5:05 PM, "Tim Chown" <tjc@ecs.soton.ac.uk> wrote:
>
> It's good to see some traction in service discovery and naming. >
> We also have a fifth area, security. =A0The text as it stands says a f= ew
> things that apply to this area, e.g.
>
> a) An assumption of "Simple Security" with default deny on t= he CER.
> =A0 =A0This implies PCP or uPnP to support punching holes. =A0The text=
> =A0 =A0 also talks about addressability vs reachability.
>

I still disagree with this premise that we must default deny and have a = mess of inadequate and complex=A0 signalling to compensate . Can someone ar= ticulate a threat model that requires this default deny and state tracking = ? Or must we put the cart before the horse without facts presented (maybe I= missed that detailed presentation of threats) ? Because win2k required a n= etwork based firewall, we must always cripple e2e?

Or, can homenet simply say home devices must be independently secure, ma= y have host based firewalls, or they must be placed in a properly screened = subnet of fundamentally flawed devices that require network security contro= ls and multi device port coordination ?

Cb
> b) Mention of appropriate mechanisms for users to associate
> =A0 =A0devices, and that devices may need keys configured, e.g. WPA2.<= br> > =A0 =A0So we should be aiming for these tasks to be as simple as possi= ble.
>
> c) The possibility to say that a ULA source indicates a connection
> =A0 =A0within the home. Suggested by Chris Palmer in Quebec, but not > =A0 =A0discussed since.
>
> d) Mention of "Advanced Security", which talks about the abi= lity to
> =A0 =A0 install 3rd party policies. =A0Some have suggested removing th= is
> =A0 =A0 from the initial homenet spec.
>
> e) =A0Discussion of (determination of) network borders; these are
> =A0 =A0 points at which policies may apply. =A0In the "self-confi= guring"
> =A0 =A0 section we talk more on that task. =A0Homenets may have intern= al
> =A0 =A0 policy borders, e.g. between private and guest areas.
>
> There's certainly scope to put down more in the way of goals; any<= br> > comments in this area are welcome.
>
> Tim
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.= ietf.org/mailman/listinfo/homenet

--047d7b11178dd5c28f04baf0e3c3-- From rdroms.ietf@gmail.com Sun Mar 11 05:02:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76DA21F85F1 for ; Sun, 11 Mar 2012 05:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 DxLAVtGAY43L for ; Sun, 11 Mar 2012 05:02:08 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 15F0121F85A4 for ; Sun, 11 Mar 2012 05:02:08 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2051670ghb.31 for ; Sun, 11 Mar 2012 05:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZSNoX1KfxQTr5DRe5IMwUow8ZUz0sKLwxi881p7uMzk=; b=Kc+/JWFDmuDlf/F18ohTCLby1CETRl1skxW+2ceslbDjcS3qAkyUToqPdr1rlY8QpE z0UerRoA4N1PFv1CEgXKVMdJuEn4CUk85GG/O3OH4e/YKMWvyprnxjWrSaZQCTSMllFE M3cSAPGVP9O8oTDJ7UyFk/J0L4hSZoE7M9YqOCYWczArdVMmWe7i9lMMlZTycMXIm7n9 iet5bh3Xc70+qtoOF/bUElayPfL1Vw0g5QiSCY4Fmj7KAX/jQ8VH0fwT2SfZbGf+yIbg +x2o1Yk8K3fAqBAhhW336HdmagtcQLQbiRLT+LuuFteBv5dJJY+lp2Ng4xa55Kro04FN t1Gg== Received: by 10.224.185.16 with SMTP id cm16mr4422592qab.0.1331467327663; Sun, 11 Mar 2012 05:02:07 -0700 (PDT) Received: from rtp-rdroms-89113.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id eq6sm21568092qab.2.2012.03.11.05.02.05 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 05:02:06 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> Date: Sun, 11 Mar 2012 08:02:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1251.1) Cc: Ray Bellis , "" , Ralph Droms Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 12:02:09 -0000 On Mar 9, 2012, at 2:58 PM 3/9/12, Ted Lemon wrote: > On Mar 9, 2012, at 1:24 PM, Ray Bellis = wrote: >> I've been vocal in my complaints about how broken the DNS Search Path = mechanism is. In particular, I'm concerned about the possible security = implications of using a relative location when a mobile device is moving = between networks. >=20 > Very true. Ideally your homenet would have a namespace in the global = DNS hierarchy that would remain the same regardless of where you = connected, and your client would have TSIG credentials sufficient to = update its own name in that namespace. Roving namespaces seem fraught = with opportunities for the wrong thing to happen, intentionally or = otherwise. This point is what I was trying to get at with my second bullet. Ted, = who is the "you" in the "where you connected": the homenet, the device, = ??? Yes, I'm stalling for time... There are two sides to the local or "relative" namespace - the device = with the name and the entity trying to contact the device. I'm trying = to work through the scenarios (independent of whether the solution is in = applications, a service, DNS-SD, DNS, etc.) and write them down... - Ralph From mellon@fugue.com Sun Mar 11 06:53:28 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B8221F86BD for ; Sun, 11 Mar 2012 06:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 hZ8Dwk4S82-Z for ; Sun, 11 Mar 2012 06:53:28 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 46D9621F86AF for ; Sun, 11 Mar 2012 06:53:28 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:1512:ae20:350f:77a3] (unknown [IPv6:2001:470:1f07:1486:1512:ae20:350f:77a3]) by toccata.fugue.com (Postfix) with ESMTPSA id 7C3D123821BD; Sun, 11 Mar 2012 09:53:26 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_2B372A32-28FE-4ED9-96E7-DBB01D08B551" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Ted Lemon In-Reply-To: Date: Sun, 11 Mar 2012 09:53:24 -0400 Message-Id: References: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> To: Ralph Droms X-Mailer: Apple Mail (2.1426) Cc: Ray Bellis , "" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 13:53:29 -0000 --Apple-Mail=_2B372A32-28FE-4ED9-96E7-DBB01D08B551 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 11, 2012, at 8:02 AM, Ralph Droms wrote: > This point is what I was trying to get at with my second bullet. Ted, = who is the "you" in the "where you connected": the homenet, the device, = ??? IOW, when a device is configured locally, how does that configuration = propagate through the homenet gateway to the real world, when the = gateway isn't necessarily connected when the device configures? My preferred answer is that the homenet gateway is authoritative for the = zone that's being updated, and can process updates even when = disconnected. I realize that MDNS-style solutions are in some sense = easier, but they don't give you a consistent name, so you wind up with = the search list problem Ray is talking about. Of course, in this scenario, if the homenet is disconnected, a roaming = device would be unable to update it until it reconnected. I think this = is probably okay. I realize this is a bit more heavyweight than what some people have been = talking about, and I'm not claiming they're wrong and I'm right; I'm = just saying that this is how I would want my homenet to work, and I = think it ties into the idea of end-to-end functionality for homenets, = both internally and externally. --Apple-Mail=_2B372A32-28FE-4ED9-96E7-DBB01D08B551 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii rdroms.ietf@gmail.com> = wrote:
This point = is what I was trying to get at with my second bullet.  Ted, who is = the "you" in the "where you connected": the homenet, the device, = ???
" , Ralph Droms Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 15:03:41 -0000 On 03/11/2012 09:53 AM, Ted Lemon wrote: > On Mar 11, 2012, at 8:02 AM, Ralph Droms > wrote: >> This point is what I was trying to get at with my second bullet. >> Ted, who is the "you" in the "where you connected": the homenet, the >> device, ??? > > IOW, when a device is configured locally, how does that configuration > propagate through the homenet gateway to the real world, when the > gateway isn't necessarily connected when the device configures? > > My preferred answer is that the homenet gateway is authoritative for > the zone that's being updated, and can process updates even when > disconnected. I realize that MDNS-style solutions are in some sense > easier, but they don't give you a consistent name, so you wind up with > the search list problem Ray is talking about. That's exactly what we're trying to achieve with CeroWrt, with its use of Bind (with both interior and exterior views). (See bind a as a place holder for "real fully featured DNS server" if you have some other favourite; it's just that dnsmasq can't support this kind of vision at the moment). Again, "running code" rather than assertion is what we'd like here, though I think we're far enough along to be able to claim this is feasible and desirable. I see/hope that mDNS and uPNP become legacy protocols in the long run; my previous mail on this topic is that I am always concerned that there are transition strategies that really work. > > Of course, in this scenario, if the homenet is disconnected, a roaming > device would be unable to update it until it reconnected. I think > this is probably okay. As do I... > > I realize this is a bit more heavyweight than what some people have > been talking about, and I'm not claiming they're wrong and I'm right; > I'm just saying that this is how I would want my homenet to work, and > I think it ties into the idea of end-to-end functionality for > homenets, both internally and externally. > Exactly. Care to help with the final piece of the CeroWrt demonstration of this? What's needed are two things: 1) some dhcp handshake with the upstream ISP provider to provide the domain keys so that the domain can be delegated and the home router become the authoritative for the delegated domain. 2) GUI work so that if the user has a domain of their own (or the ISP does not/is incapable of delegation), you can get it hooked up with your DNS provider; while we have bind all running fine, the GUI work for configuring bind has lagged (I've been intending to do it, but have been somewhat ill of late). Right now, the CeroWrt GUI is still for configuring dnsmasq, which we don't use. I think there is an interesting question of whether interior *names* should be automatically published into the global DNS by default or not, which will depend on the security of the devices and systems and the users' expertise, if only to make it a bit harder for attackers to discover interior systems to attack (since with IPv6 finding them by brute force address space search is relatively hard). I suspect that it should default to "off", myself, if only because I know I have boxes in my house that the vendors seldom if ever update the firmware for, and I don't want them exposed. Clearly, we have the reality of many insecure devices mouldering in home environments, and can't ignore this problem. Jim From mellon@fugue.com Sun Mar 11 08:18:23 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8436821F8716 for ; Sun, 11 Mar 2012 08:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 X5oUdQFHeEa2 for ; Sun, 11 Mar 2012 08:18:23 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1C35921F870E for ; Sun, 11 Mar 2012 08:18:23 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:c965:da0b:2935:deae] (unknown [IPv6:2001:470:1f07:1486:c965:da0b:2935:deae]) by toccata.fugue.com (Postfix) with ESMTPSA id 1A7FC2382179; Sun, 11 Mar 2012 11:18:20 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A6943F04-B77B-4873-BA52-EDE0D6C72390" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Ted Lemon In-Reply-To: <4F5CBEC9.90201@freedesktop.org> Date: Sun, 11 Mar 2012 11:18:19 -0400 Message-Id: References: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> <4F5CBEC9.90201@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1426) Cc: Ray Bellis , "" , Ralph Droms Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 15:18:23 -0000 --Apple-Mail=_A6943F04-B77B-4873-BA52-EDE0D6C72390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am actually working on a draft that is a start at addressing this = problem, and indeed the initial comments I got back suggest that there = is more work to do along the lines you're talking about=97my draft as = written just dealt with the reverse zone and not the forward zone. The = draft is at http://tools.ietf.org/html/draft-lemon-dhc-dns-pd-00. I = think I need to add the bit that you just described, and I might try to = turn around a -01 before the deadline to do this. I'd be curious to = know what you think about it. --Apple-Mail=_A6943F04-B77B-4873-BA52-EDE0D6C72390 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am = actually working on a draft that is a start at addressing this problem, = and indeed the initial comments I got back suggest that there is more = work to do along the lines you're talking about=97my draft as written = just dealt with the reverse zone and not the forward zone.   The = draft is at http://tools= .ietf.org/html/draft-lemon-dhc-dns-pd-00.   I think I need to = add the bit that you just described, and I might try to turn around a = -01 before the deadline to do this.   I'd be curious to know what = you think about it.

= --Apple-Mail=_A6943F04-B77B-4873-BA52-EDE0D6C72390-- From fred@cisco.com Sun Mar 11 08:22:37 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0895C21F8691 for ; Sun, 11 Mar 2012 08:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.033 X-Spam-Level: X-Spam-Status: No, score=-109.033 tagged_above=-999 required=5 tests=[AWL=1.566, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Ncc-6a+3n-Og for ; Sun, 11 Mar 2012 08:22:36 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2627721F8688 for ; Sun, 11 Mar 2012 08:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1439; q=dns/txt; s=iport; t=1331479356; x=1332688956; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=WIAmzaPxC8PkD7msie/TyO7byen6LDuYs2MjUybemXk=; b=ZjknCPXPWGaFefuxw/82gYEtzYqJzzP856g/C6PmQ6SJXluxlQG/9Les cgxu/w8YHAataUuIpVWFo6I92siSC1TfZZkeDbnoZzEO+kLGo5b8Vd4LI 1Ud9b6DBrlEYjdJ4GlX07UNSIzzt0im/hR/YBBMsJ+KAhUSPZeZq0OF06 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAATCXE+rRDoH/2dsb2JhbABCtUGBB4IJAQEBAwEBAQEPASc0CwULCw4ENCciDgYTIoVvgXQEDJtUAZ1rBJAeYwSIVIx4hWmKOoMDgTw X-IronPort-AV: E=Sophos;i="4.73,566,1325462400"; d="scan'208";a="35618436" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 11 Mar 2012 15:22:36 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2BFMZvu015972; Sun, 11 Mar 2012 15:22:35 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 11 Mar 2012 08:22:35 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 11 Mar 2012 08:22:35 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sun, 11 Mar 2012 08:22:18 -0700 Message-Id: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> References: To: Ralph Droms X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 15:22:37 -0000 Two things someone will need to think about: ICANN is now selling "dotless" names. A name without dots has a defined = behavior in most DNS resolvers; they find a way to further qualify them. = Do we want to humor ICANN, or solve this? mDNS is crippled, in that it operates on a single LAN. That might = describe Apple networks; per the architecture document it doesn't = describe all home networks. Do we want to provide an admin-scope = multicast address for it, and if so, what do we recommend for routing? On Mar 9, 2012, at 10:05 AM, Ralph Droms wrote: > Here's my list of "desired behaviors" for name resolution, proposed = for inclusion in the architecture document; comments and suggestions = welcome: >=20 > * Disconnected operation ("fate sharing"): name resolution for = reachable devices continues if the local network is disconnected from = the global Internet > * Relative name resolution: some naming convention that allows name = resolution while mitigating the need to know an absolute location in the = global DNS namespace > * Unmanaged operation > * Efficient message utilization: for example, keep unwanted traffic = off of an IEEE802.15.4 network > * Representation in the global DNS namespace, for access from off-net >=20 > - Ralph >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mellon@fugue.com Sun Mar 11 08:25:14 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE7A21F86B0 for ; Sun, 11 Mar 2012 08:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 n8y4k4WFHaPP for ; Sun, 11 Mar 2012 08:25:14 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCB021F8611 for ; Sun, 11 Mar 2012 08:25:14 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:c965:da0b:2935:deae] (unknown [IPv6:2001:470:1f07:1486:c965:da0b:2935:deae]) by toccata.fugue.com (Postfix) with ESMTPSA id B7677238217E; Sun, 11 Mar 2012 11:25:12 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_72FA985F-41DE-4FE4-A521-64E97653AE40" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Ted Lemon In-Reply-To: <4F5CBEC9.90201@freedesktop.org> Date: Sun, 11 Mar 2012 11:25:11 -0400 Message-Id: <167CFE21-22F1-49CB-B73E-9D7E9DAC2739@fugue.com> References: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> <4F5CBEC9.90201@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1426) Cc: Ray Bellis , "" , Ralph Droms Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 15:25:14 -0000 --Apple-Mail=_72FA985F-41DE-4FE4-A521-64E97653AE40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 11, 2012, at 11:03 AM, Jim Gettys wrote: > I think there is an interesting question of whether interior *names* > should be automatically published into the global DNS by default or > not, which will depend on the security of the devices and systems and > the users' expertise, if only to make it a bit harder for attackers to > discover interior systems to attack (since with IPv6 finding them by > brute force address space search is relatively hard). Doesn't making the zone non-enumerable and disabling zone transfers = address this problem? I guess you could still do a dictionary attack = on the zone and decrease the cost of the search somewhat in the usual = case, but it's a pretty sketchy way to try to start an attack. Having = said that, I think it's probably fine to disable propagation of the zone = by default, except that then we have to figure out what to name the = non-propagated zone, and how to deal with the transition from = non-propagated to propagated. --Apple-Mail=_72FA985F-41DE-4FE4-A521-64E97653AE40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii jg@freedesktop.org> = wrote:
I think = there is an interesting question of whether interior *names*
should be = automatically published into the global DNS by default or
not, =  which will depend on the security of the devices and systems = and
the users' = expertise, if only to make it a bit harder for attackers to
discover = interior systems to attack (since with IPv6 finding them by
brute = force address space search is relatively = hard).

Doesn't making the zone = non-enumerable and disabling zone transfers address this problem?   = I guess you could still do a dictionary attack on the zone and decrease = the cost of the search somewhat in the usual case, but it's a pretty = sketchy way to try to start an attack.   Having said that, I think = it's probably fine to disable propagation of the zone by default, except = that then we have to figure out what to name the non-propagated zone, = and how to deal with the transition from non-propagated to = propagated.

= --Apple-Mail=_72FA985F-41DE-4FE4-A521-64E97653AE40-- From gettysjim@gmail.com Sun Mar 11 08:43:29 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9B921F8726 for ; Sun, 11 Mar 2012 08:43:29 -0700 (PDT) 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 Qin86A99BSYs for ; Sun, 11 Mar 2012 08:43:29 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D62F021F8725 for ; Sun, 11 Mar 2012 08:43:28 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3848166vcb.31 for ; Sun, 11 Mar 2012 08:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=biUHwAE99nkfn1CPQHKqNCt0x6ziqHuv3ASLbcwjiC4=; b=cjdyGavqiMxkSYZlzZjQDtkRFJEK/jLH08UUyNQhV0Hhgzo+izUzKPRr6RwIYt7FjE 9JUdY4fFSR0sJhagiTESBTW6Bd3ZT1DFOUS21a3rXD1D4gZAXKFGZsZ3vtWRcmI+tr8V FJefEi0YUm5QHY0tQ4pqjmxfXw6lLBKeNwzY7ULX8Mg70z0c2vLU5j05cexhj9hU96Nq OKGW46f8nlWGsvnNbBBdPdgEqcrQxl0UQg3LlvbqMe4+uModt7tf16G2Vo0SOKPDx5bt KZAjWVLK4YPAODWjRlXl6VqsMG4NKl64h7Lf7LdIjFw9xwXZ5ugv9Nbdc2j5Jmy9OZYl vnug== Received: by 10.52.65.244 with SMTP id a20mr5216723vdt.24.1331480608451; Sun, 11 Mar 2012 08:43:28 -0700 (PDT) Received: from [172.30.48.80] (c-50-138-169-248.hsd1.ma.comcast.net. [50.138.169.248]) by mx.google.com with ESMTPS id h5sm22609073vdk.0.2012.03.11.08.43.26 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 08:43:27 -0700 (PDT) Sender: Jim Gettys Message-ID: <4F5CC81D.3070005@freedesktop.org> Date: Sun, 11 Mar 2012 11:43:25 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ted Lemon References: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> <4F5CBEC9.90201@freedesktop.org> <167CFE21-22F1-49CB-B73E-9D7E9DAC2739@fugue.com> In-Reply-To: <167CFE21-22F1-49CB-B73E-9D7E9DAC2739@fugue.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ray Bellis , "" , Ralph Droms Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 15:43:29 -0000 On 03/11/2012 11:25 AM, Ted Lemon wrote: > On Mar 11, 2012, at 11:03 AM, Jim Gettys > wrote: >> I think there is an interesting question of whether interior *names* >> should be automatically published into the global DNS by default or >> not, which will depend on the security of the devices and systems and >> the users' expertise, if only to make it a bit harder for attackers to >> discover interior systems to attack (since with IPv6 finding them by >> brute force address space search is relatively hard). > > Doesn't making the zone non-enumerable and disabling zone transfers > address this problem? I guess you could still do a dictionary attack > on the zone and decrease the cost of the search somewhat in the usual > case, but it's a pretty sketchy way to try to start an attack. > Having said that, I think it's probably fine to disable propagation of > the zone by default, except that then we have to figure out what to > name the non-propagated zone, and how to deal with the transition from > non-propagated to propagated. > Had been thinking more along the line of the multiple "view" stuff in bind; there would be/is already a public view, and then a private view only visible internally. - Jim From rdroms.ietf@gmail.com Sun Mar 11 08:48:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C55B621F8712 for ; Sun, 11 Mar 2012 08:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.585 X-Spam-Level: X-Spam-Status: No, score=-103.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 0RQ5zUv80eWX for ; Sun, 11 Mar 2012 08:48:21 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 408CC21F86F8 for ; Sun, 11 Mar 2012 08:48:21 -0700 (PDT) Received: by yenm5 with SMTP id m5so2121919yen.31 for ; Sun, 11 Mar 2012 08:48:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=teGFKbhBbAKwIT4udmzvzaeo6VSDEew5PnMp1+7m0mA=; b=kffXg0bZwnebF9kZ2oz978uE+egtJmid1Gg019sGKyOR6q4I4xEiNRyk7aIFgqvmk9 luBlcMnRgmI3oS143Ufd6CQNqtnpkwFfOOjpsu6JcGCOaKF5zjQ4Qbs4ILcNrciitP+O T87/lUNvpPdqJ1M9edXHDppbmbSshLE10cCF0Oo+3AtqNAfpMZsn/Emu+6oLhFEO71qF m0t6vv5AJWfKUz1tA25CMmFE+Bxm6imx8sMfCjmPg4Wrt1pzyu9vhNEi6oZkDdLZwNsf 8wa1zJ7wOr542JUlmRwU1h5SutS7CEA5stzACWuNaPFjr1TyNt8LzZN5XMUvrb49XEF8 GziQ== Received: by 10.224.197.198 with SMTP id el6mr5121267qab.7.1331480900854; Sun, 11 Mar 2012 08:48:20 -0700 (PDT) Received: from rtp-rdroms-89113.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id f12sm22506008qan.1.2012.03.11.08.48.18 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 08:48:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> Date: Sun, 11 Mar 2012 11:48:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 15:48:21 -0000 Fred... On Mar 11, 2012, at 11:22 AM 3/11/12, Fred Baker wrote: > Two things someone will need to think about: >=20 > ICANN is now selling "dotless" names. A name without dots has a = defined behavior in most DNS resolvers; they find a way to further = qualify them. Do we want to humor ICANN, or solve this? Do you have a pointer to a description of the behavior of "dotless" = names? > mDNS is crippled, in that it operates on a single LAN. That might = describe Apple networks; per the architecture document it doesn't = describe all home networks. Do we want to provide an admin-scope = multicast address for it, and if so, what do we recommend for routing? See draft-lynn-homenet-site-mdns-00. - Ralph > On Mar 9, 2012, at 10:05 AM, Ralph Droms wrote: >=20 >> Here's my list of "desired behaviors" for name resolution, proposed = for inclusion in the architecture document; comments and suggestions = welcome: >>=20 >> * Disconnected operation ("fate sharing"): name resolution for = reachable devices continues if the local network is disconnected from = the global Internet >> * Relative name resolution: some naming convention that allows name = resolution while mitigating the need to know an absolute location in the = global DNS namespace >> * Unmanaged operation >> * Efficient message utilization: for example, keep unwanted traffic = off of an IEEE802.15.4 network >> * Representation in the global DNS namespace, for access from off-net >>=20 >> - Ralph >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 From mellon@fugue.com Sun Mar 11 10:24:22 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C4D21F8578 for ; Sun, 11 Mar 2012 10:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 vGr9md9EcvF0 for ; Sun, 11 Mar 2012 10:24:22 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 83A2321F855F for ; Sun, 11 Mar 2012 10:24:21 -0700 (PDT) Received: from [IPv6:2001:470:1f07:1486:c965:da0b:2935:deae] (unknown [IPv6:2001:470:1f07:1486:c965:da0b:2935:deae]) by toccata.fugue.com (Postfix) with ESMTPSA id B6A432382178; Sun, 11 Mar 2012 13:24:19 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6913B7A9-DFB8-4651-A57B-F66EF92A67A1" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1426\)) From: Ted Lemon In-Reply-To: <4F5CC81D.3070005@freedesktop.org> Date: Sun, 11 Mar 2012 13:24:18 -0400 Message-Id: References: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> <4F5CBEC9.90201@freedesktop.org> <167CFE21-22F1-49CB-B73E-9D7E9DAC2739@fugue.com> <4F5CC81D.3070005@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1426) Cc: Ray Bellis , "" , Ralph Droms Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 17:24:22 -0000 --Apple-Mail=_6913B7A9-DFB8-4651-A57B-F66EF92A67A1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Mar 11, 2012, at 11:43 AM, Jim Gettys wrote: > Had been thinking more along the line of the multiple "view" stuff in > bind; there would be/is already a public view, and then a private view > only visible internally. Oh, I see, automagic DNS split horizon. That does make sense, yes. --Apple-Mail=_6913B7A9-DFB8-4651-A57B-F66EF92A67A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii jg@freedesktop.org> = wrote:
Had been = thinking more along the line of the multiple "view" stuff in
bind; = there would be/is already a public view, and then a private = view
only = visible internally.

Oh, I see, = automagic DNS split horizon.   That does make sense, = yes.

= --Apple-Mail=_6913B7A9-DFB8-4651-A57B-F66EF92A67A1-- From rdroms.ietf@gmail.com Sun Mar 11 10:25:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A1521F8578 for ; Sun, 11 Mar 2012 10:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 7C86M2aetUIZ for ; Sun, 11 Mar 2012 10:25:41 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C3B6A21F84F5 for ; Sun, 11 Mar 2012 10:25:41 -0700 (PDT) Received: by yhpp34 with SMTP id p34so2159428yhp.31 for ; Sun, 11 Mar 2012 10:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JfZ3+xzHb4IDlIs0DjZLqf/drHmlyGvglxLi4kUxO4I=; b=QQ3zxSTI1Aqyjwheee82TA8KDlDxEbF23062CvukHLD6I4fLUGX+g8KyDk7wPY5S9E ujc0qnEf1ZEYWMDHnu+kXFLVwUh1nK7dgO7L+0++KKtubSuElo/bmyL12lBQ+bKi/LZR A30vDBfCPaNlKXBpHs0l7iPcica6G7KZRg1ei78s70XBgPByIIL8B96Xu0Z7MWsWKjFv VblcyWJYpump8/XygC90ZrcMecNaOG9pLu7N8/F+tb/rSs5Gq3w4aex4Y0Jkt/YV7xy3 YH2cRz8SFRq6WGDgz/tTo6s2bt1lfIzTchFfU+/uuxpGaolLpy2afwYh5JrvNHu1kqnf t9AQ== Received: by 10.224.205.130 with SMTP id fq2mr5238719qab.53.1331486741363; Sun, 11 Mar 2012 10:25:41 -0700 (PDT) Received: from rtp-rdroms-89113.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id eo4sm22875163qab.16.2012.03.11.10.25.39 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 10:25:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: <4F5CC81D.3070005@freedesktop.org> Date: Sun, 11 Mar 2012 13:25:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> <4F5CBEC9.90201@freedesktop.org> <167CFE21-22F1-49CB-B73E-9D7E9DAC2739@fugue.com> <4F5CC81D.3070005@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1251.1) Cc: Ray Bellis , "" , Ted Lemon , Ralph Droms Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 17:25:42 -0000 Suppose that view is on a per-device basis rather than per server? With something like environment variables in front of "classic" DNS = resolution in the host resolver... - Ralph On Mar 11, 2012, at 11:43 AM 3/11/12, Jim Gettys wrote: > On 03/11/2012 11:25 AM, Ted Lemon wrote: >> On Mar 11, 2012, at 11:03 AM, Jim Gettys > > wrote: >>> I think there is an interesting question of whether interior *names* >>> should be automatically published into the global DNS by default or >>> not, which will depend on the security of the devices and systems = and >>> the users' expertise, if only to make it a bit harder for attackers = to >>> discover interior systems to attack (since with IPv6 finding them by >>> brute force address space search is relatively hard). >>=20 >> Doesn't making the zone non-enumerable and disabling zone transfers >> address this problem? I guess you could still do a dictionary = attack >> on the zone and decrease the cost of the search somewhat in the usual >> case, but it's a pretty sketchy way to try to start an attack. =20 >> Having said that, I think it's probably fine to disable propagation = of >> the zone by default, except that then we have to figure out what to >> name the non-propagated zone, and how to deal with the transition = from >> non-propagated to propagated. >>=20 >=20 > Had been thinking more along the line of the multiple "view" stuff in > bind; there would be/is already a public view, and then a private view > only visible internally. > - Jim >=20 From gettysjim@gmail.com Sun Mar 11 10:27:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A7521F8683 for ; Sun, 11 Mar 2012 10:27:15 -0700 (PDT) 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 Mdpv8ZU8MG0n for ; Sun, 11 Mar 2012 10:27:14 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2CDC21F864E for ; Sun, 11 Mar 2012 10:27:12 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3921193vcb.31 for ; Sun, 11 Mar 2012 10:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nj4IGYg3GSWyVG+2GbUy5Xjwuj83okIsbrV9549j2mk=; b=gxatKxR4WHjcWgoclxNYZi7OF33dvTV+paHVfQgeRC7sGPH8gaVJJ5yzKfc4u83/Zj 48/L559lWXfA6xFCF2XZlCASDTxED8g1MxV1YfnmqAfO8xuVtq19BAb3kAAFWPT6xdR4 l7gfq3CVAgf6QbD5ZzZgLdrSbHpmYZf3SK+uM8eFRz4A5K9BOrlQn5DG8GfnBDvjvLXV WNtdIl4N492y9mv3B+4NwaSWKDPru2UWNg6Jo1//szYKb4gMvryj35o9EKkYL5TSnOWC +bPbUtAbes8wtwwUkH3hgXiTMCSmySiOKK9BcCA11MHf10crgxm8c3WpZYpSPzLwelAR K7RA== Received: by 10.52.65.134 with SMTP id x6mr12474705vds.60.1331486832229; Sun, 11 Mar 2012 10:27:12 -0700 (PDT) Received: from [172.30.48.80] (c-50-138-169-248.hsd1.ma.comcast.net. [50.138.169.248]) by mx.google.com with ESMTPS id w6sm22968226vdj.4.2012.03.11.10.27.10 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 10:27:11 -0700 (PDT) Sender: Jim Gettys Message-ID: <4F5CE06D.20405@freedesktop.org> Date: Sun, 11 Mar 2012 13:27:09 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ralph Droms References: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> <4F5CBEC9.90201@freedesktop.org> <167CFE21-22F1-49CB-B73E-9D7E9DAC2739@fugue.com> <4F5CC81D.3070005@freedesktop.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ray Bellis , "" , Ted Lemon Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 17:27:15 -0000 On 03/11/2012 01:25 PM, Ralph Droms wrote: > Suppose that view is on a per-device basis rather than per server? > > With something like environment variables in front of "classic" DNS resolution in the host resolver... What's the use case for such complexity? Otherwise, my answer is KISS... - Jim > > - Ralph > > On Mar 11, 2012, at 11:43 AM 3/11/12, Jim Gettys wrote: > >> On 03/11/2012 11:25 AM, Ted Lemon wrote: >>> On Mar 11, 2012, at 11:03 AM, Jim Gettys >> > wrote: >>>> I think there is an interesting question of whether interior *names* >>>> should be automatically published into the global DNS by default or >>>> not, which will depend on the security of the devices and systems and >>>> the users' expertise, if only to make it a bit harder for attackers to >>>> discover interior systems to attack (since with IPv6 finding them by >>>> brute force address space search is relatively hard). >>> Doesn't making the zone non-enumerable and disabling zone transfers >>> address this problem? I guess you could still do a dictionary attack >>> on the zone and decrease the cost of the search somewhat in the usual >>> case, but it's a pretty sketchy way to try to start an attack. >>> Having said that, I think it's probably fine to disable propagation of >>> the zone by default, except that then we have to figure out what to >>> name the non-propagated zone, and how to deal with the transition from >>> non-propagated to propagated. >>> >> Had been thinking more along the line of the multiple "view" stuff in >> bind; there would be/is already a public view, and then a private view >> only visible internally. >> - Jim >> From tjc@ecs.soton.ac.uk Sun Mar 11 10:27:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EDD21F8657 for ; Sun, 11 Mar 2012 10:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 J1ZIC5wTUuQh for ; Sun, 11 Mar 2012 10:27:13 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 3823821F8648 for ; Sun, 11 Mar 2012 10:27:04 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2BHR1RG020568 for ; Sun, 11 Mar 2012 17:27:01 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2BHR1RG020568 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1331486821; bh=mb9GJ/cBTsvPSZ3/WsrFuARl0yA=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=v4S+DUQyIktH8WHuKmyH86Zvzq9ZzVGq0K6rA7Sz2S3zmAYjRXrUqTxfaNaz9S8Zp 74hihXJDAI6z/OZheW60uGnUNRd7UimfOSEl6OP3O0EXId2NjkNELO7jYx/FUqc+mm i3aG2WZ9c7aFHhEcrpOn0S94kxdTyAWyVgxQS9oE= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o2AHR10543727541LU ret-id none; Sun, 11 Mar 2012 17:27:01 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2BHPdHc005000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 11 Mar 2012 17:25:39 GMT From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_E9797B6F-3ED3-4CFE-95B1-C5D21C24F34B" Date: Sun, 11 Mar 2012 17:25:39 +0000 In-Reply-To: To: "homenet@ietf.org Group" References: Message-ID: X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2AHR1054372754100; tid=o2AHR10543727541LU; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2BHR1RG020568 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 17:27:15 -0000 --Apple-Mail=_E9797B6F-3ED3-4CFE-95B1-C5D21C24F34B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 11 Mar 2012, at 05:28, Cameron Byrne wrote: > On Mar 10, 2012 5:05 PM, "Tim Chown" wrote: > > > > a) An assumption of "Simple Security" with default deny on the CER. > > This implies PCP or uPnP to support punching holes. The text > > also talks about addressability vs reachability. >=20 > I still disagree with this premise that we must default deny and have = a mess of inadequate and complex signalling to compensate . Can someone = articulate a threat model that requires this default deny and state = tracking ? Or must we put the cart before the horse without facts = presented (maybe I missed that detailed presentation of threats) ? = Because win2k required a network based firewall, we must always cripple = e2e? >=20 > Or, can homenet simply say home devices must be independently secure, = may have host based firewalls, or they must be placed in a properly = screened subnet of fundamentally flawed devices that require network = security controls and multi device port coordination ? >=20 >=20 The -02 that is coming soon still has "simple security" as a default = position, but also states a requirement for support of RFC 6092's = transparent mode. That should be something a residential user can = enable simply, if they choose to do so. Tim --Apple-Mail=_E9797B6F-3ED3-4CFE-95B1-C5D21C24F34B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Mar 10, 2012 5:05 PM, "Tim Chown" <tjc@ecs.soton.ac.uk> = wrote:
>
> a) An assumption of "Simple Security" with default deny on the = CER.
>    This implies PCP or uPnP to support punching holes. =  The text
>     also talks about addressability vs = reachability.

I still disagree with this premise that we must = default deny and have a mess of inadequate and complex  signalling = to compensate . Can someone articulate a threat model that requires this = default deny and state tracking ? Or must we put the cart before the = horse without facts presented (maybe I missed that detailed presentation = of threats) ? Because win2k required a network based firewall, we must = always cripple e2e?

Or, can homenet simply say home devices must = be independently secure, may have host based firewalls, or they must be = placed in a properly screened subnet of fundamentally flawed devices = that require network security controls and multi device port = coordination ?



The -02 that is coming = soon still has "simple security" as a default position, but also states = a requirement for support of RFC 6092's transparent mode.  That = should be something a residential user can enable simply, if they choose = to do so.

Tim

= --Apple-Mail=_E9797B6F-3ED3-4CFE-95B1-C5D21C24F34B-- From rdroms.ietf@gmail.com Sun Mar 11 10:30:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13F721F86EC for ; Sun, 11 Mar 2012 10:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 VhCJj6anRY5C for ; Sun, 11 Mar 2012 10:30:42 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4346A21F8697 for ; Sun, 11 Mar 2012 10:30:42 -0700 (PDT) Received: by yenm5 with SMTP id m5so2159906yen.31 for ; Sun, 11 Mar 2012 10:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uF7CCmpDBz5mFXIVCQvbDZ57OuEvlCAHxd5t81+w/AY=; b=D80k32OOXuPrcp5KwW1mCg6ZH0sWtGP9ctyzwgxCsdJQVnoZX7zS5zUu+L71hTDLJO uPWJbz1Y8a+IbgZHwgBl8CsQif1s6K8XkkDPwiiDAYtFUvAZraaQNaZKWgSEB/lNgkq0 t9oWpo4VeLGgyJwNyfHKqEm3R0ueNnLp1Newk84l37q/kSNxkDjyfYpNBmBLV1En+/Bh A0eTXxqcNuIq3zS8152kWkqWYpQuA2YPhVv4vaHOiZTK5XAK3xklIKd7yIZ+XZB0ax21 WnIGTelUrixqrfZHZn85FKXk9KM97Awm+40oZSM5YU+k1kg9pshqO5h/X0FZ2+v1b0hr Fl9A== Received: by 10.229.137.16 with SMTP id u16mr1694431qct.146.1331487041884; Sun, 11 Mar 2012 10:30:41 -0700 (PDT) Received: from rtp-rdroms-89113.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id h11sm22922254qae.3.2012.03.11.10.30.40 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 10:30:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: <4F5CE06D.20405@freedesktop.org> Date: Sun, 11 Mar 2012 13:30:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3EDD90D7-4329-45CE-8D07-6E72A664B5F8@gmail.com> References: <5ED03AA5-B52D-41E2-9F28-F4589679FA60@fugue.com> <4F5CBEC9.90201@freedesktop.org> <167CFE21-22F1-49CB-B73E-9D7E9DAC2739@fugue.com> <4F5CC81D.3070005@freedesktop.org> <4F5CE06D.20405@freedesktop.org> To: Jim Gettys X-Mailer: Apple Mail (2.1251.1) Cc: Ray Bellis , "" , Ted Lemon , Ralph Droms Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 17:30:42 -0000 On Mar 11, 2012, at 1:27 PM 3/11/12, Jim Gettys wrote: > On 03/11/2012 01:25 PM, Ralph Droms wrote: >> Suppose that view is on a per-device basis rather than per server? >>=20 >> With something like environment variables in front of "classic" DNS = resolution in the host resolver... >=20 > What's the use case for such complexity? Otherwise, my answer is = KISS... I think a device will want multiple views... * network it's currently attached to * "home" network it's usually attached to * (OK, so it's Sunday afternoon; I'm busy with other stuff and ran out = of other contexts. Anyone? Buehler?) ...and avoid split views in the DNS itself and avoid all the questions = about what gets published where. - Ralph > - Jim >=20 >=20 >>=20 >> - Ralph >>=20 >> On Mar 11, 2012, at 11:43 AM 3/11/12, Jim Gettys wrote: >>=20 >>> On 03/11/2012 11:25 AM, Ted Lemon wrote: >>>> On Mar 11, 2012, at 11:03 AM, Jim Gettys >>> > wrote: >>>>> I think there is an interesting question of whether interior = *names* >>>>> should be automatically published into the global DNS by default = or >>>>> not, which will depend on the security of the devices and systems = and >>>>> the users' expertise, if only to make it a bit harder for = attackers to >>>>> discover interior systems to attack (since with IPv6 finding them = by >>>>> brute force address space search is relatively hard). >>>> Doesn't making the zone non-enumerable and disabling zone transfers >>>> address this problem? I guess you could still do a dictionary = attack >>>> on the zone and decrease the cost of the search somewhat in the = usual >>>> case, but it's a pretty sketchy way to try to start an attack. =20 >>>> Having said that, I think it's probably fine to disable propagation = of >>>> the zone by default, except that then we have to figure out what to >>>> name the non-propagated zone, and how to deal with the transition = from >>>> non-propagated to propagated. >>>>=20 >>> Had been thinking more along the line of the multiple "view" stuff = in >>> bind; there would be/is already a public view, and then a private = view >>> only visible internally. >>> - Jim >>>=20 >=20 From mcr@sandelman.ca Sun Mar 11 10:36:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8CF21F8540 for ; Sun, 11 Mar 2012 10:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_05=-1.11, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 rpvu6dgBkh-p for ; Sun, 11 Mar 2012 10:36:36 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 14D9E21F8532 for ; Sun, 11 Mar 2012 10:36:35 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 19AB13448A for ; Sun, 11 Mar 2012 13:33:52 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 000AC98282; Sun, 11 Mar 2012 13:36:24 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id E9CF198281 for ; Sun, 11 Mar 2012 13:36:24 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Sun, 11 Mar 2012 13:36:24 -0400 Message-ID: <13119.1331487384@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 17:36:37 -0000 >>>>> "Tim" == Tim Chown writes: Tim> It's good to see some traction in service discovery and naming. Tim> We also have a fifth area, security. The text as it stands Tim> says a few things that apply to this area, e.g. There are two categories: security services provided by homenet. (Your a-d). And security required by homenet. (Your (e)). Let's keep those two sections seperate! I think we need a 3.3.4. Security Considerations for security required by homenet. It is here that we need to put the limits on what a solution can demand. Parts (a-d), belongs in 3.4. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Sun Mar 11 10:40:54 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4F021F85C2 for ; Sun, 11 Mar 2012 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=1.288, BAYES_00=-2.599, GB_I_LETTER=-2, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 8CHr13QwgHfS for ; Sun, 11 Mar 2012 10:40:53 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id DBDAE21F85C0 for ; Sun, 11 Mar 2012 10:40:53 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id DBBC6344DF for ; Sun, 11 Mar 2012 13:38:19 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id CC31C98282; Sun, 11 Mar 2012 13:40:52 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C53B998281 for ; Sun, 11 Mar 2012 13:40:52 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 11 Mar 2012 13:40:52 -0400 Message-ID: <13941.1331487652@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 17:40:54 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Cameron" =3D=3D Cameron Byrne writes: >> It's good to see some traction in service discovery and naming. >>=20 >> We also have a fifth area, security. The text as it stands says >> a few things that apply to this area, e.g. >>=20 >> a) An assumption of "Simple Security" with default deny on the >> CER. This implies PCP or uPnP to support punching holes. The >> text also talks about addressability vs reachability. >>=20 Cameron> I still disagree with this premise that we must default Cameron> deny and have a mess of inadequate and complex signalling Cameron> to compensate . Can someone articulate a threat model that Cameron> requires this default deny and state tracking ? Or must we Cameron> put the cart before the horse without facts presented +1 I think that the question as to whether or not "Simple Security" defaults to on is a seperate question as to whether or not "Simple Security" MUST be available to be turned on. Cameron> Or, can homenet simply say home devices must be Cameron> independently secure, may have host based firewalls, or Cameron> they must be placed in a properly screened subnet of Cameron> fundamentally flawed devices that require network security Cameron> controls and multi device port coordination ? so, if such a subnet is to exist (and it could be virtual thanks to things like NEA), then Simple Security still needs to be implemented. In my mind, to get around the "NAT is security, e2e is bad" CROWD, which is ALL OVER THE PLACE out there (not here at the IETF, where we are much more clueful. I'm talking about people with phony letters after their titles who have never heard of the IETF), we need to have an answer, and that answer must be very clearly labelled, such that it can be turned off by people who want it. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT1zjpIqHRg3pndX9AQIBfAQArqHHXklkNxm0kZ/9lJtkk3ysYA2U2fEr i91oyDptWK4vWMYF1ILxRRiGevzpbh3rGRssdTcg6qxSmaKp/8sOFWfsLpj55+ET Eh8M3oDBhync0mizCn2YsGg1BDD7XrPqnCt/+VK7xoZVk2PXGoGTMlBpvlffCsWB zC4/AKJnBJI= =e29x -----END PGP SIGNATURE----- --=-=-=-- From tjc@ecs.soton.ac.uk Sun Mar 11 11:07:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B20F21F86E2 for ; Sun, 11 Mar 2012 11:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] 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 lxbD8InEL0kG for ; Sun, 11 Mar 2012 11:07:04 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5923021F8495 for ; Sun, 11 Mar 2012 11:06:52 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2BI6oso027111; Sun, 11 Mar 2012 18:06:50 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2BI6oso027111 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1331489210; bh=UnawOBfAE8wJUlX/m3A6wZbfHfw=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=WGc+P7TrSEx7IbVYEAb8bvW5jetn+uuWvkFxgvICp/bHPs17D2XQpA8ooky0CGV9J iKKip/+VWKKyH0jAKoMZbDtkOGWf31S5ifqVJH4LbWYyjnL5U49/yjm6g7fS9Yq7Sb HDdvPJJqt5FpgIrR6F/E8wUUNUM+kdbE3tDp1rPY= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id o2AI6o0543727665qX ret-id none; Sun, 11 Mar 2012 18:06:50 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2BI6jV6012485 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Mar 2012 18:06:45 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Chown In-Reply-To: Date: Sun, 11 Mar 2012 18:06:44 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <9B12A77F-91FE-4FAC-B4F9-36E0639B9069@dlink.com.tw> <5442.1331062687@marajade.sandelman.ca> <0B5081A3-DF7C-4628-A16D-F9EAF9C351AC@ecs.soton.ac.uk> To: Randy Turner X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2AI6o054372766500; tid=o2AI6o0543727665qX; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2BI6oso027111 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "homenet@ietf.org Group" , Mark Townsley , Michael Richardson Subject: Re: [homenet] Framing homenet borders and default policies X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 18:07:05 -0000 The -02 coming soon makes it clear the examples are just that. Tim On 6 Mar 2012, at 20:19, Randy Turner wrote: > After a 2nd reading of the current arch doc, I'm still not sure where = the "bounding box" is around our work - seems like the language in = section 3 should be tightened up - or rephrased to emphasize that the = list of topology support is normative and not a set of examples >=20 > Randy >=20 >=20 >=20 > On Mar 6, 2012, at 11:38 AM, Michael Richardson = wrote: >=20 >>=20 >> {I was cleaning out email that I felt I SHOULD read} >>=20 >>>>>>> "Mark" =3D=3D Mark Townsley writes: >> Mark> For the 3 base cases listed above (Local, Internet, Guest) If >> Mark> we can solidly answer the 5 (6) questions below, we've >> Mark> accomplished well what is within our scope: >>=20 >> Mark> 1. Do we share or accept assigned prefixes over this link? >> Mark> 2. Do we share or accept routing information over this link? >> Mark> 3. Do we share or accept services information over this link? >> Mark> 4. Do we share or accept naming information over this link? >> Mark> 5. Do we allow application traffic to flow over this link? If >> Mark> so, do we apply a firewall function? (6.) Do we allow >> Mark> troubleshooting protocols over this link (ping, traceroute - >> Mark> could be part of the FW question in #5)? >>=20 >> What are we going to do with this? >> Does this discussion go into the architecture document? >>=20 >> --=20 >> ] He who is tired of Weird Al is tired of life! | = firewalls [ >> ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net = architect[ >> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ = |device driver[ >> Kyoto Plus: watch the video = >> then sign the petition.=20 >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >>=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From dave.taht@gmail.com Sun Mar 11 11:15:13 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F05E21F86DD for ; Sun, 11 Mar 2012 11:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FM_IS_IT_OUR_ACCOUNT=4.2, GB_I_LETTER=-2, 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 Tr4cxphhyH1M for ; Sun, 11 Mar 2012 11:15:12 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E16D321F84B8 for ; Sun, 11 Mar 2012 11:15:11 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2132811wib.13 for ; Sun, 11 Mar 2012 11:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=purhBYYCV1Bmdcbiwdy572xLkzN/j+rmYbxlQUg7KwY=; b=0HWiRUAG2/6XESebbs/I+P2y1nVv0ibvMIJIFbowur6bYNzLcU9im7WlFoHDU4p6rB ybCcrBVGBuxtF+s8a+wb9NUcAQC6xMLD0FBvt4llOBxwBF30oSpU3djBlsiLNX42CZNv VH6tG3Fj87anaQ8JGxQ95+ytaVCSkun1zhHK7CmIGaAZQLdtTwbx2UnqgV+fr0vLJWCy eZLApHTBiOlB84LHKk0apfYQJn1A6SPcBrOpRqGdMbpWj3C9QUTot2IbcEqIlhgopgBP sHDfPlKv+S2KR0nLQdUTjNkDsL/+6akuEEflsPmxp4GHnnlXm1PlNM0ZBnoB0Qk34lsH HVcA== MIME-Version: 1.0 Received: by 10.180.80.104 with SMTP id q8mr20956619wix.14.1331489711105; Sun, 11 Mar 2012 11:15:11 -0700 (PDT) Received: by 10.223.151.8 with HTTP; Sun, 11 Mar 2012 11:15:11 -0700 (PDT) In-Reply-To: <13941.1331487652@marajade.sandelman.ca> References: <13941.1331487652@marajade.sandelman.ca> Date: Sun, 11 Mar 2012 18:15:11 +0000 Message-ID: From: Dave Taht To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 18:15:13 -0000 On Sun, Mar 11, 2012 at 5:40 PM, Michael Richardson wrot= e: > >>>>>> "Cameron" =3D=3D Cameron Byrne writes: > =A0 =A0>> It's good to see some traction in service discovery and naming. > =A0 =A0>> > =A0 =A0>> We also have a fifth area, security. =A0The text as it stands s= ays > =A0 =A0>> a few things that apply to this area, e.g. > =A0 =A0>> > =A0 =A0>> a) An assumption of "Simple Security" with default deny on the > =A0 =A0>> CER. =A0This implies PCP or uPnP to support punching holes. =A0= The > =A0 =A0>> text also talks about addressability vs reachability. > =A0 =A0>> > > =A0 =A0Cameron> I still disagree with this premise that we must default > =A0 =A0Cameron> deny and have a mess of inadequate and complex signalling > =A0 =A0Cameron> to compensate . Can someone articulate a threat model tha= t > =A0 =A0Cameron> requires this default deny and state tracking ? Or must w= e > =A0 =A0Cameron> put the cart before the horse without facts presented > > +1 > > I think that the question as to whether or not "Simple Security" > defaults to on is a seperate question as to whether or not "Simple > Security" MUST be available to be turned on. > > =A0 =A0Cameron> Or, can homenet simply say home devices must be > =A0 =A0Cameron> independently secure, may have host based firewalls, or > =A0 =A0Cameron> they must be placed in a properly screened subnet of > =A0 =A0Cameron> fundamentally flawed devices that require network securit= y > =A0 =A0Cameron> controls and multi device port coordination ? > > so, if such a subnet is to exist (and it could be virtual thanks to > things like NEA), then Simple Security still needs to be implemented. > > In my mind, to get around the "NAT is security, e2e is bad" CROWD, which > is ALL OVER THE PLACE out there (not here at the IETF, where we are much > more clueful. I'm talking about people with phony letters after their tit= les > who have never heard of the IETF), we need to have an answer, and that > answer must be very clearly labelled, such that it can be turned off by > people who want it. I have a tendency to drag discussions down into implementation details, and I apologize in advance here for not having a high level viewpoint, on what could be, vs what is. I recently sat down with jg to try and implement a useful amount of ipv6, with a useful amount of security. The biggest problem I ran into was that nearly every useful service had an acl that required enabling before it could be used inside the network in the first place. In a dynamically (PD assigned) world, this would mean that trigger scripts would have to be fired off to alter these on every change, and daemons restarted, and there are related problems.... the list: polipo web proxy: acl needed to access it at all via ipv6, needed to be blocked from the outside bind9 - acl needed in order to distinguish between 'us' and 'them' queries, needed a distinct ipv6 address for 'external' queries radvd - dnssl is not widely supported on clients dhcp - helpful to have an autoconfiguration based naming scheme - (assign an ipv4 address, force an ra message, ping6 to see if the device has it, if so, add the autoconfed ipv6 address to dns) mrd6 - specific addresses/interfaces assigned pim - I haven't ever seen pim on ipv4 or ipv6, actually work routing daemon (babel/ospf/whatever) - needs configuration from scratch, al= most web server - things like wpad.domain.wherever should work only on the insid= e web server for router configuration - should only be available inside dhcp-pd - big headache as yet rsync - I LIKE rsync and don't mind it being entirely open bidirectionally. That's me. ssh - I trust ssh, LIKE leaving it open bidirectionally. And the converse was also a problem: Several other services (notably samba/cifs) were open to the world via ipv6 by default. I'm pretty sure these ports shouldn't be open to the world, and the simplest way was to block them via the firewall, and not use acls. In addition to the above cases, the concept of having a 'guest' network in the home complicates matters even further, as by what scheme can you dynamically assign addresses, and retain security. Certain devices (printers for example) should be available inside in all cases, your accounting server or home security webcam system, not so much.... In the polipo case, (I note that a ipv6/ipv4 capable translating web proxy is darn useful) there is presently no way to distinguish between an internal guest network and a normal internal network. So I provide these cases as food for thought only. I too, would like E2E connectivity restored, but there are some services that should not be available out to the wild, woolly internet over ipv6. Requiring that all ipv6 services use PCP or upnp to open an incoming port is also a can of worms. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net From mcr@sandelman.ca Sun Mar 11 13:49:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A5621F85D7 for ; Sun, 11 Mar 2012 13:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 DkLBTizwtrlJ for ; Sun, 11 Mar 2012 13:49:11 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 01F1C21F85D2 for ; Sun, 11 Mar 2012 13:49:10 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id A28313448A; Sun, 11 Mar 2012 16:46:35 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 5F2CF98282; Sun, 11 Mar 2012 16:49:08 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 3791298281; Sun, 11 Mar 2012 16:49:08 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: References: <13941.1331487652@marajade.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 11 Mar 2012 16:49:07 -0400 Message-ID: <17210.1331498947@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Dave Taht Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 20:49:11 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Dave" =3D=3D Dave Taht writes: Dave> The biggest problem I ran into was that nearly every useful Dave> service had an acl that required enabling before it could be Dave> used inside the network in the first place. In a dynamically Dave> (PD assigned) world, this would mean that trigger scripts Dave> would have to be fired off to alter these on every change, and Dave> daemons restarted, and there are related problems.... (thus in the windows world, where you have to reboot all the time) What I think is happening in the Linux-kernel-based desktop world=20 (i.e. GNOME/KDE, which includes man *BSD systems too, of course), is that dbus is being used to announce new addresses. It's less obvious that this should be used for routers/servers, but I think it will become the thing. So, what we actually need from your list of things to be tweaked is a list of what inputs they need for the tweaking. The mechanism for the tweaking could evolve, so long as we can keep the naming of each parameter consistent. Dave> In addition to the above cases, the concept of having a Dave> 'guest' network in the home complicates matters even further, Dave> as by what scheme can you dynamically assign addresses, and Dave> retain security. Certain devices (printers for example) Dave> should be available inside in all cases, your accounting Dave> server or home security webcam system, not so much.... So, this is where the naming and categorization of services is important. The first slide here: http://www.ietf.org/proceedings/81/slides/homenet-5.pdf was bemoaning the lack of anything between local link, and world. And I think the take-home from your list is that there is nor only the "Home", but also the "Trusted home" and "Guest home" =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT10Pw4qHRg3pndX9AQJnRwQApAvnyL67v3PJ/x2s5LlyRz5jzO2C0UUT PO8XmVxX2jrpHrEFUyAwoaIapio8VNN5fL9aFXpw3uE6oQSVVuQhFY6cergMwqlN PcDJBuIcxEV1rKsv/6lpOdjM3lmpKF3efzCxifc2V6SiUoEqoEXH966yaqmTuLYt 3WJYvxXp5dQ= =VV9I -----END PGP SIGNATURE----- --=-=-=-- From fred@cisco.com Sun Mar 11 14:45:43 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518B421F8705 for ; Sun, 11 Mar 2012 14:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.055 X-Spam-Level: X-Spam-Status: No, score=-109.055 tagged_above=-999 required=5 tests=[AWL=1.544, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 vqO8RabXqrax for ; Sun, 11 Mar 2012 14:45:42 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A8E8121F86EE for ; Sun, 11 Mar 2012 14:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1358; q=dns/txt; s=iport; t=1331502342; x=1332711942; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=R9so3gNmdZKHTJ08+OXMCekDFqpOa6P1kc4ni3pULmA=; b=Vk2sXs52AMDb2BKbOFCbap/o0Vh0BFmSdivbz4BwsYM+bgcjA5/eHmsb TZvvaeM2FcKKBoNY5yaySJedREVQBFCpK6e1dB5u8CCm4iQcG6P7w+Mox dXRCboQGv/TW2LN5531BUFbnAb4gSpWL85E8yKn6VWSgHwW47TLcCMziQ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABkcXU+rRDoG/2dsb2JhbABBDrVEgQeCCQEBAQMBEgEnPwULCw44VwY1h2MEDJ9nAZYHkB5jBIhUjHiFaYo6gixX X-IronPort-AV: E=Sophos;i="4.73,568,1325462400"; d="scan'208";a="33056559" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 11 Mar 2012 21:45:42 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2BLjRRB031809; Sun, 11 Mar 2012 21:45:42 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 11 Mar 2012 14:45:42 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 11 Mar 2012 14:45:42 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Sun, 11 Mar 2012 14:44:35 -0700 Message-Id: <0B8FB2ED-E7B8-469E-B76F-26B0A687624E@cisco.com> References: To: Tim Chown X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 21:45:43 -0000 On Mar 10, 2012, at 5:04 PM, Tim Chown wrote: > It's good to see some traction in service discovery and naming. >=20 > We also have a fifth area, security. The text as it stands says a few > things that apply to this area, e.g. >=20 > a) An assumption of "Simple Security" with default deny on the CER. =20= > This implies PCP or uPnP to support punching holes. The text=20 > also talks about addressability vs reachability. > d) Mention of "Advanced Security", which talks about the ability to > install 3rd party policies. Some have suggested removing this > from the initial homenet spec. One of these days I'll figure out what is "advanced" about "advanced = security". I think the point of interest is that it can be expected to = not be maintained (how many people maintain their = norton-or-whatever-firewall contracts?) and will therefore allow a lot = of stuff through. I will be doing a talk in opsawg trying to make the firewall story a = little less "I don't like this and I do like that", more about what a = firewall does and doesn't do and what models one might consider - at = least three of them. If there is interest in homenet, I could comment on = that discussion. http://tools.ietf.org/html/draft-baker-opsawg-firewalls "On Firewalls in Internet Security", Fred Baker, 20-Jan-12 From fred@cisco.com Sun Mar 11 14:55:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4C121F8664 for ; Sun, 11 Mar 2012 14:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.077 X-Spam-Level: X-Spam-Status: No, score=-109.077 tagged_above=-999 required=5 tests=[AWL=1.522, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 UA0Ge7XoPSzi for ; Sun, 11 Mar 2012 14:55:18 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1824221F864E for ; Sun, 11 Mar 2012 14:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1720; q=dns/txt; s=iport; t=1331502918; x=1332712518; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=NkETjKmzz/oB1gsDAHTf2Xsv+nJGRAnEGlf/+rGqcaw=; b=T41TaYF1r3jNsty800b4Y/IUBo61WdKR2xYJfbgz7M/BAA4ucv7kftSX OJgBTQkMe5jgOGC43L6grfwCnziw6NtqqEIM5O/WwoauGg1yfsTeie+k1 Sd4uZeACYuBXknFcMy+tNXz/DjmVnC83e6myKGCwSfmoEO+vI29k/sYTq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANQeXU+rRDoJ/2dsb2JhbABCDrU3gQeCCQEBAQQBAQEPASc0CxALDgouJzAGEyKHZwybVAGdapAeYwSIVIx4hWmKOoIsVw X-IronPort-AV: E=Sophos;i="4.73,568,1325462400"; d="scan'208";a="35524192" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 11 Mar 2012 21:55:17 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2BLtGjx009562; Sun, 11 Mar 2012 21:55:16 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 11 Mar 2012 14:55:16 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 11 Mar 2012 14:55:16 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <0B8FB2ED-E7B8-469E-B76F-26B0A687624E@cisco.com> Date: Sun, 11 Mar 2012 14:55:00 -0700 Message-Id: <580E4244-378D-4123-B76A-B401756099C0@cisco.com> References: <0B8FB2ED-E7B8-469E-B76F-26B0A687624E@cisco.com> To: Tim Chown X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 21:55:18 -0000 Hmm. I just scheduled the agenda, and homenet and opsawg conflict. I may = or may not be able to wander from one meeting to the other. On Mar 11, 2012, at 2:44 PM, Fred Baker wrote: > On Mar 10, 2012, at 5:04 PM, Tim Chown wrote: >> It's good to see some traction in service discovery and naming. >>=20 >> We also have a fifth area, security. The text as it stands says a = few >> things that apply to this area, e.g. >>=20 >> a) An assumption of "Simple Security" with default deny on the CER. =20= >> This implies PCP or uPnP to support punching holes. The text=20 >> also talks about addressability vs reachability. >=20 >> d) Mention of "Advanced Security", which talks about the ability to >> install 3rd party policies. Some have suggested removing this >> from the initial homenet spec. >=20 > One of these days I'll figure out what is "advanced" about "advanced = security". I think the point of interest is that it can be expected to = not be maintained (how many people maintain their = norton-or-whatever-firewall contracts?) and will therefore allow a lot = of stuff through. >=20 > I will be doing a talk in opsawg trying to make the firewall story a = little less "I don't like this and I do like that", more about what a = firewall does and doesn't do and what models one might consider - at = least three of them. If there is interest in homenet, I could comment on = that discussion. >=20 > http://tools.ietf.org/html/draft-baker-opsawg-firewalls > "On Firewalls in Internet Security", Fred Baker, 20-Jan-12 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From rogerj@gmail.com Mon Mar 12 02:44:13 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E5C21F8713 for ; Mon, 12 Mar 2012 02:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 3lvnXZ2DEnkC for ; Mon, 12 Mar 2012 02:44:12 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A11D021F8700 for ; Mon, 12 Mar 2012 02:44:12 -0700 (PDT) Received: by iazz13 with SMTP id z13so7304255iaz.31 for ; Mon, 12 Mar 2012 02:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=xBfs/7ub4YQwKfH9PWcLfkpAFW7Zfms3HKKMa3W2JFw=; b=SgthNSQwTVoDTB0RfPS0669pkyTrkxzmDj5eTKh/48qGMWN20RvcAjtFMzhxnZRp4P OeAWL+NC/0hqq2zRoB/i2TjlvU/f6P4EonHTPgi72/e+Nx53F+Xg4RBo7aguab4fDVEV bt65rHy0C/rsiyqLVeLhNEUWHagXbiXBSBHdBMuJ79jNeJ+m/osavRfPNL0rXQWkX3Ne l/BsmndBBii+htgNQBENimAtDiTiL8QDc3NCPe47Wt7silpuri0fJL66eXJpa4Kbe3s4 O9L7+odme58BIPtUwuUs55CuzLABh17L2g/DB1e8ml+0bnE35pO54eq18zq9BLBN5ow+ WwGw== MIME-Version: 1.0 Received: by 10.50.190.167 with SMTP id gr7mr2467437igc.8.1331545452225; Mon, 12 Mar 2012 02:44:12 -0700 (PDT) Received: by 10.42.117.200 with HTTP; Mon, 12 Mar 2012 02:44:11 -0700 (PDT) In-Reply-To: <13119.1331487384@marajade.sandelman.ca> References: <13119.1331487384@marajade.sandelman.ca> Date: Mon, 12 Mar 2012 10:44:11 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Michael Richardson , "homenet@ietf.org Group" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 09:44:13 -0000 On Sun, Mar 11, 2012 at 6:36 PM, Michael Richardson wrot= e: > >>>>>> "Tim" =3D=3D Tim Chown writes: > =A0 =A0Tim> It's good to see some traction in service discovery and namin= g. > > =A0 =A0Tim> We also have a fifth area, security. =A0The text as it stands > =A0 =A0Tim> says a few things that apply to this area, e.g. > > There are two categories: security services provided by homenet. > (Your a-d). =A0And security required by homenet. (Your (e)). > > Let's keep those two sections seperate! I was about to commenting on the same, that we have two different security settings here. About security for end-users, why should it be deny by default? It don't really rise the security level by much since virus/trojans get in through user initiated action, and out again just as easy in the background. --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From C.Grundemann@CableLabs.com Mon Mar 12 14:44:07 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA0821F8913 for ; Mon, 12 Mar 2012 14:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.173 X-Spam-Level: X-Spam-Status: No, score=0.173 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 nfQYuyyEHMLM for ; Mon, 12 Mar 2012 14:44:06 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7283621F88E1 for ; Mon, 12 Mar 2012 14:43:48 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2CLhO08026936 for ; Mon, 12 Mar 2012 15:43:47 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Mon, 12 Mar 2012 15:43:24 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 12 Mar 2012 15:23:35 -0600 From: Chris Grundemann To: "homenet@ietf.org" Date: Mon, 12 Mar 2012 15:23:38 -0600 Thread-Topic: New Version Notification for draft-gmann-homenet-relay-autoconf-01.txt Thread-Index: Ac0AlmGjASBB88s8T9uHQC68T6gOCA== Message-ID: In-Reply-To: <20120312211442.11082.23703.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: [homenet] FW: New Version Notification for draft-gmann-homenet-relay-autoconf-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:44:07 -0000 Working Group, Forwarded for your information and discussion. This is a new I-D which describes a method to auto configure an IPv6 home network using DHCPv6 relay and DHCP snooping. It references another new I-D which describes a CER_ID DHCPv6 option to identify the CER. We tried to keep it short and as plain language as possible so hopefully the document can speak for itself. In particular, section 3 covers the necessary normative behavior of home routers and section 4 describes the specific provisioning process. Feedback greatly appreciated, questions welcome. Thank you. Cheers, ~Chris On 3/12/12 3:14 PM, "internet-drafts@ietf.org" wrote: >A new version of I-D, draft-gmann-homenet-relay-autoconf-01.txt has been >successfully submitted by Chris Grundemann and posted to the IETF >repository. > >Filename: draft-gmann-homenet-relay-autoconf >Revision: 01 >Title: Home Network Autoconfiguration via DHCPv6 Relay >Creation date: 2012-03-12 >WG ID: Individual Submission >Number of pages: 8 > >Abstract: > This document describes a method for efficiently delegating subnets > of an IPv6 prefix among home routers while simultaneously creating > functional routing tables in all home routers without the need for a > routing protocol. > > > =20 > =20 > > >The IETF Secretariat From internet-drafts@ietf.org Mon Mar 12 15:16:20 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EAB21E80EC; Mon, 12 Mar 2012 15:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 IYFfrmYxdjXt; Mon, 12 Mar 2012 15:16:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67C421E808D; Mon, 12 Mar 2012 15:16:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312221619.9612.79497.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:16:19 -0700 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:16:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Home Networking Working Group of the = IETF. Title : Home Networking Architecture for IPv6 Author(s) : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-02.txt Pages : 36 Date : 2012-03-12 This text describes evolving networking technology within small residential home networks. The goal of this memo is to define the architecture for IPv6-based home networking and the associated principles, considerations and requirements. The text briefly highlights the implications of the introduction of IPv6 for home networking, discusses topology scenarios, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-homenet-arch-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-homenet-arch-02.txt From brian.e.carpenter@gmail.com Mon Mar 12 19:21:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE9821F879E for ; Mon, 12 Mar 2012 19:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.441 X-Spam-Level: X-Spam-Status: No, score=-103.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 z0LcxGAoMuGc for ; Mon, 12 Mar 2012 19:21:53 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C722021F878E for ; Mon, 12 Mar 2012 19:21:53 -0700 (PDT) Received: by yenm5 with SMTP id m5so59841yen.31 for ; Mon, 12 Mar 2012 19:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KHJBsdBUxmjv0moYsly1XB5V4EP0xVEHiiY5D7+LXKA=; b=tevs/qQWRlvZBJ2WPwnl/bLnuVp7IePIpSDz63bYxUQxtXdw8ueN6eZq15XvqAxD6z n9PxsCfONIds52+g1WLAQBERMqxw2qKQfGeOL/OV5LHr4AdukcW4y0J1AIorTluZJhr/ jVkS2KhO/E/dlbX+YyNWABga5B+w5yaEXcQ8LMUgBk2PMom6N/Bp3I2ghP2D886uY3Pp EBOlFKJSy31nhCt3G7bBi1dhUt0sgNUyAhz4Oe1yV1aKkENveQrVrj3kQVmKzuHbRiIT w/BqQIIHr32b5mmHrfy27m/hp238QgeLmJwfV7kFtPttupLnGSpvDTlXaI1MGx8/4owl 3u1g== Received: by 10.236.181.5 with SMTP id k5mr15619503yhm.61.1331605313351; Mon, 12 Mar 2012 19:21:53 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id a24sm25518840ana.10.2012.03.12.19.21.51 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 19:21:52 -0700 (PDT) Message-ID: <4F5EAF3D.2020506@gmail.com> Date: Tue, 13 Mar 2012 15:21:49 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: homenet@ietf.org References: <20120312211442.11082.15266.idtracker@ietfa.amsl.com> In-Reply-To: <20120312211442.11082.15266.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 02:21:55 -0000 Hi, How does this work when there are multiple customer edge routers (CERs), as in a MIF situation for example? Brian On 2012-03-13 10:14, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Home Network Autoconfiguration via DHCPv6 Relay > Author(s) : Chris Grundemann > Chris Donley > Filename : draft-gmann-homenet-relay-autoconf-01.txt > Pages : 8 > Date : 2012-03-12 > > This document describes a method for efficiently delegating subnets > of an IPv6 prefix among home routers while simultaneously creating > functional routing tables in all home routers without the need for a > routing protocol. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-gmann-homenet-relay-autoconf-01.txt From lee.howard@twcable.com Mon Mar 12 19:27:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072BB21F87C8 for ; Mon, 12 Mar 2012 19:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.63 X-Spam-Level: X-Spam-Status: No, score=-0.63 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 AtAPtkKb0-i0 for ; Mon, 12 Mar 2012 19:27:04 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 488C721F87C5 for ; Mon, 12 Mar 2012 19:27:04 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,573,1325480400"; d="scan'208";a="336328505" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 12 Mar 2012 22:26:19 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 12 Mar 2012 22:27:03 -0400 From: "Howard, Lee" To: Fred Baker Date: Mon, 12 Mar 2012 22:27:02 -0400 Thread-Topic: [homenet] Security goals Thread-Index: Ac0AwMZDkreGKFmRQt2gC1dpyBukWw== Message-ID: <854C4D43-EB21-41DF-9DB4-1CCE761358AD@twcable.com> References: <0B8FB2ED-E7B8-469E-B76F-26B0A687624E@cisco.com> In-Reply-To: <0B8FB2ED-E7B8-469E-B76F-26B0A687624E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tim Chown , "homenet@ietf.org Group" Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 02:27:05 -0000 On Mar 11, 2012, at 5:44 PM, Fred Baker wrote: > > On Mar 10, 2012, at 5:04 PM, Tim Chown wrote: > >> It's good to see some traction in service discovery and naming. >> >> We also have a fifth area, security. The text as it stands says a few >> things that apply to this area, e.g. >> >> a) An assumption of "Simple Security" with default deny on the CER. >> This implies PCP or uPnP to support punching holes. The text >> also talks about addressability vs reachability. > >> d) Mention of "Advanced Security", which talks about the ability to >> install 3rd party policies. Some have suggested removing this >> from the initial homenet spec. > > One of these days I'll figure out what is "advanced" about "advanced secu= rity". I think the point of interest is that it can be expected to not be m= aintained (how many people maintain their norton-or-whatever-firewall contr= acts?) and will therefore allow a lot of stuff through. > > I will be doing a talk in opsawg trying to make the firewall story a litt= le less "I don't like this and I do like that", more about what a firewall = does and doesn't do and what models one might consider - at least three of = them. If there is interest in homenet, I could comment on that discussion. > > http://tools.ietf.org/html/draft-baker-opsawg-firewalls > "On Firewalls in Internet Security", Fred Baker, 20-Jan-12 Any chance of having such a conversation in the Security Area WG? I mentio= ned the debate to Sean Turner (Security AD), and he thought it would be an = excellent topic for security experts to discuss. However, since there had = been no discussion on list, I did not get around to writing a draft, so I h= ave nothing to submit for the agenda. Lee > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fred@cisco.com Mon Mar 12 23:05:28 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6B521F8820 for ; Mon, 12 Mar 2012 23:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.115 X-Spam-Level: X-Spam-Status: No, score=-109.115 tagged_above=-999 required=5 tests=[AWL=1.484, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 gFF12XVjlDvL for ; Mon, 12 Mar 2012 23:05:28 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0816D21F881D for ; Mon, 12 Mar 2012 23:05:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=975; q=dns/txt; s=iport; t=1331618728; x=1332828328; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=7Wxjz+mNSla1847MkiBfPQJFbjjvtF1ESI3xc1UmL1M=; b=LRk/q6uaKHJIRc1Vh/C4xIBvAnR2iMhNywoUd86fogUXraHbAjUX/dyo RltKeg+HuU0mEEsdMyyuZd6dTffBjDKzJwny0sEwYbC8y4mzcL+Mljz4y 9jSsQB6A9dOjm8plU6uOsUZXR/57f8w+EYQjVUMg7sDB1GUAjLelfPBW+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADLjXk+rRDoI/2dsb2JhbABDtWGBB4IKAQEEEgEnMQ4QC0ZXBjWHZwydVgGfE5ACYwSIVYx6hWmKOoMF X-IronPort-AV: E=Sophos;i="4.73,575,1325462400"; d="scan'208";a="35743792" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 13 Mar 2012 06:05:27 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2D65QJE014803; Tue, 13 Mar 2012 06:05:27 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 12 Mar 2012 23:05:27 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 12 Mar 2012 23:05:27 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <854C4D43-EB21-41DF-9DB4-1CCE761358AD@twcable.com> Date: Mon, 12 Mar 2012 23:04:35 -0700 Message-Id: References: <0B8FB2ED-E7B8-469E-B76F-26B0A687624E@cisco.com> <854C4D43-EB21-41DF-9DB4-1CCE761358AD@twcable.com> To: "Howard, Lee" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Tim Chown , security-ads@tools.ietf.org, "homenet@ietf.org Group" , opsawg-chairs@tools.ietf.org Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 06:05:28 -0000 On Mar 12, 2012, at 7:27 PM, Howard, Lee wrote: >> http://tools.ietf.org/html/draft-baker-opsawg-firewalls >> "On Firewalls in Internet Security", Fred Baker, 20-Jan-12 >=20 > Any chance of having such a conversation in the Security Area WG? I = mentioned the debate to Sean Turner (Security AD), and he thought it = would be an excellent topic for security experts to discuss. However, = since there had been no discussion on list, I did not get around to = writing a draft, so I have nothing to submit for the agenda. I'm willing to enough to have the conversation there. I'd just like to = have the conversation, as we seem to throw bats around regarding = firewalls with ever really reaching a conclusion beyond "they are a = market requirement regardless of what anyone thinks about them = technically". opsawg chairs, the issue is that homenet and opsawg conflict and I don't = do a very good imitation of myself in a separate working group.= From Ray.Bellis@nominet.org.uk Tue Mar 13 09:16:47 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAEF21E802C for ; Tue, 13 Mar 2012 09:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.254 X-Spam-Level: X-Spam-Status: No, score=-10.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Clm8ShHNtIgc for ; Tue, 13 Mar 2012 09:16:46 -0700 (PDT) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED3621E8025 for ; Tue, 13 Mar 2012 09:16:45 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=YSLMPWmhf3foab7wizFtneVsJis3d3ju839ThVpugJzpTv41uIwYs+1L 2Imy1xMerAbzv2VEBb3di2k8NvGMAuXaUKuxeU6N2NH4pobyDzdLwwnqX xjgDa3bC/FOs9gv; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1331655406; x=1363191406; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20Name=20resolution=20in=20th e=20homenet=20architecture=20document|Date:=20Tue,=2013 =20Mar=202012=2016:16:38=20+0000|Message-ID:=20<5B578E7D- ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk>|To:=20Fred=20 Baker=20|CC:=20Ralph=20Droms=20,=20""=0D=0A=09|MIME-Version:=201.0|Content-Transfer-Encoding:=20 quoted-printable|Content-ID:=20<2c5d8d16-cbc7-4472-bd32-2 9e497b27482>|In-Reply-To:=20<56D070B2-8F60-4222-90FA-ADA8 DAA6C003@cisco.com>|References:=20=0D=0A=20<56D070B2-8F60-4222-90F A-ADA8DAA6C003@cisco.com>; bh=4OuqHRswrtCYcyF6uMs1q3i8uw1LUXd9AWA6dERY8RM=; b=dMZogPEdypuWUBrP+bjpdJK5n8HmmI/KxB5QnDkcbV9ZWTRfrYb+kYQr GlTCEKyIUdfOpxbXU2oeYexSvrrW+sl4oKw/6a8KCG8oJUv4y1cf5yNwP csLGrCszSAekUhM; X-IronPort-AV: E=Sophos;i="4.73,577,1325462400"; d="scan'208";a="31679824" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 13 Mar 2012 16:16:40 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 13 Mar 2012 16:16:39 +0000 From: Ray Bellis To: Fred Baker Thread-Topic: [homenet] Name resolution in the homenet architecture document Thread-Index: AQHM/h9UxKtxAP/z4U64+iJXWlgrSJZlOT8AgAMz2AA= Date: Tue, 13 Mar 2012 16:16:38 +0000 Message-ID: <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> In-Reply-To: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <2c5d8d16-cbc7-4472-bd32-29e497b27482> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Ralph Droms Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 16:16:47 -0000 On 11 Mar 2012, at 15:22, Fred Baker wrote: > ICANN is now selling "dotless" names. A name without dots has a defined b= ehavior in most DNS resolvers; they find a way to further qualify them. Do = we want to humor ICANN, or solve this? AIUI, the problem is more that on some operating systems a dotless name is = first looked up in non-DNS based name spaces (e.g. NetBIOS). Only if those= fail is it considered by DNS, with an optional search suffix. Hence on any particular network one cannot guarantee that the dotless name = won't already exist in some other name space that then masks the (very expe= nsive) DNS-based version. Ray From rdroms.ietf@gmail.com Tue Mar 13 09:23:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290E221F87ED for ; Tue, 13 Mar 2012 09:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 gmGnvBVyk0M0 for ; Tue, 13 Mar 2012 09:23:15 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBEA21F873A for ; Tue, 13 Mar 2012 09:23:15 -0700 (PDT) Received: by eaaq11 with SMTP id q11so415135eaa.31 for ; Tue, 13 Mar 2012 09:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=/2d97BLlUF8KQP0ivo/z/iBc8ZkxQR7dKQI/6oYE9Y8=; b=ConlJ+VTUrI9g8Yl30xOlTwBf+GkiMZ/V5oC9He94qj4gC1lNInEmgdctEGUeV2hil 1XHGwcPOqQo8o24gWqrsDsoTyTyB361osSP+J/RqlF53R1qQKW0NC1kKDPwCwJsK0fT4 LIFoXCP67sAw5PFStxP0Ya2gOOqr9z6zAYEnTzL0PEAiLttlII20jbdYKQh9nZ9ZRQB4 gPJsYfFjOTrvPsMj8jKIcEgM9nD+iSog6M3F2MNUFCvkG3QKI3flNTh876FfDxYw/tvq CcnfyaWhczNlv1u3tQtpunk7J3cCF4QKOm90GSUSfh/snG6NeHQxvBhgNAFUg6Z1fHy1 ySJQ== Received: by 10.229.135.207 with SMTP id o15mr4076807qct.51.1331655793277; Tue, 13 Mar 2012 09:23:13 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id h11sm4022016qae.3.2012.03.13.09.23.11 (version=SSLv3 cipher=OTHER); Tue, 13 Mar 2012 09:23:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> Date: Tue, 13 Mar 2012 12:23:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> To: Ray Bellis X-Mailer: Apple Mail (2.1251.1) Cc: "" , Ralph Droms , Fred Baker Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 16:23:16 -0000 On Mar 13, 2012, at 12:16 PM 3/13/12, Ray Bellis wrote: >=20 > On 11 Mar 2012, at 15:22, Fred Baker wrote: >=20 >> ICANN is now selling "dotless" names. A name without dots has a = defined behavior in most DNS resolvers; they find a way to further = qualify them. Do we want to humor ICANN, or solve this? >=20 > AIUI, the problem is more that on some operating systems a dotless = name is first looked up in non-DNS based name spaces (e.g. NetBIOS). = Only if those fail is it considered by DNS, with an optional search = suffix. "dotless name" =3D=3D "pay-for-play TLDs" ??? - Ralph >=20 > Hence on any particular network one cannot guarantee that the dotless = name won't already exist in some other name space that then masks the = (very expensive) DNS-based version. >=20 > Ray >=20 From daveoran@orandom.net Tue Mar 13 09:26:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E77921E8034 for ; Tue, 13 Mar 2012 09:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] 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 BvkrYCIjP2SE for ; Tue, 13 Mar 2012 09:26:21 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2286721E802F for ; Tue, 13 Mar 2012 09:26:21 -0700 (PDT) Received: from stealth-10-32-245-150.cisco.com (c-66-31-41-8.hsd1.ma.comcast.net [66.31.41.8]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id q2DGQHNx017925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2012 09:26:18 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David R Oran In-Reply-To: Date: Tue, 13 Mar 2012 12:26:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> To: Ralph Droms X-Mailer: Apple Mail (2.1257) Cc: Ray Bellis , "" , Fred Baker Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 16:26:21 -0000 On Mar 13, 2012, at 12:23 PM, Ralph Droms wrote: >=20 > On Mar 13, 2012, at 12:16 PM 3/13/12, Ray Bellis wrote: >=20 >>=20 >> On 11 Mar 2012, at 15:22, Fred Baker wrote: >>=20 >>> ICANN is now selling "dotless" names. A name without dots has a = defined behavior in most DNS resolvers; they find a way to further = qualify them. Do we want to humor ICANN, or solve this? >>=20 >> AIUI, the problem is more that on some operating systems a dotless = name is first looked up in non-DNS based name spaces (e.g. NetBIOS). = Only if those fail is it considered by DNS, with an optional search = suffix. >=20 > "dotless name" =3D=3D "pay-for-play TLDs" ??? >=20 Just remember to dot your I(cann)s and cross your t(LD)s. Sorry, couldn't resist... > - Ralph >=20 >>=20 >> Hence on any particular network one cannot guarantee that the dotless = name won't already exist in some other name space that then masks the = (very expensive) DNS-based version. >>=20 >> Ray >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From fred@cisco.com Tue Mar 13 15:26:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8408E21E8039 for ; Tue, 13 Mar 2012 15:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.004 X-Spam-Level: X-Spam-Status: No, score=-109.004 tagged_above=-999 required=5 tests=[AWL=1.295, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 G+2M3cTFgIps for ; Tue, 13 Mar 2012 15:26:18 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id EFF2521E8037 for ; Tue, 13 Mar 2012 15:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3165; q=dns/txt; s=iport; t=1331677578; x=1332887178; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=EpF5Rvf9ZZw7ALb9uHt8g43l03z1zUcuDibhJcXwAO0=; b=hfW5+OR3HbpxzrHhQfp5fmsKwm3bPcMWVb6IwnlR33gC/A6fY57pjTth s00fVJ71n7HSGw6iDcPyxaCQwXPmemYSSHmeEiP7ocItBYSXBD+sFNLFz gooQsofT024tFrLEC0s3sNMUMLpv3WC+QrJDyGhjGVurw4pWnrGf8DBDd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJ/IX0+rRDoH/2dsb2JhbAA5CrVvgQeCCQEBAQQSAVwKEAsYLlcGNYdnnGIBnnaKKIVrYwSIVYx7hWmKOoMF X-IronPort-AV: E=Sophos;i="4.73,579,1325462400"; d="scan'208";a="35880862" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 13 Mar 2012 22:26:17 +0000 Received: from Freds-Computer.local (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2DMQGwt029536; Tue, 13 Mar 2012 22:26:17 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 13 Mar 2012 15:26:17 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 13 Mar 2012 15:26:17 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Tue, 13 Mar 2012 15:25:34 -0700 Message-Id: References: <13119.1331487384@marajade.sandelman.ca> To: =?iso-8859-1?Q?Roger_J=F8rgensen?= X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 22:26:18 -0000 On Mar 12, 2012, at 2:44 AM, Roger J=F8rgensen wrote: > About security for end-users, why should it be deny by default? It = don't really rise the security level by much since virus/trojans get in = through user initiated action, and out again just as easy in the = background. =46rom my perspective, there is a question of what is being defended and = of defense in depth, and a question of market requirement. I agree that a firewall of any kind doesn't defend the host, since the = vast majority of attacks come from behind the firewall. What a firewall = defends is primarily the bandwidth within the defended domain - which = would be best done if the firewall was at the ISP (before the typical = bottleneck link). However, it does prevent certain kinds of messages from getting to a = host that don't have a reason to get there. The net effect is to make = the attack surface of the host smaller from the perspective of attacks = from the outside - the attack has to thread two needles, not just one. The general argument against "default deny" is that it prevents = legitimate traffic from reaching the host. I'll argue that this is = exactly the right model for traffic that the host has no application to = process - traffic that look legitimate but isn't because of the set of = applications running on the host. Take, for example, a host that is = prepared to operate as an http client but not a server; a packet = directed to an http server on it is going to be refused by the host, and = could be refused anywhere in the path. The problem with something that = is literally "default deny" is that it needs a way to identify and apply = rules like "sending smtp to smtp.example.com is reasonable". I'll argue = that protocols like PCP are reasonable ways to do that; "default deny" = plus PCP does *not* prevent legitimate traffic from getting to the host, = but it does prevent unwanted traffic from arriving at the host. You'll ask why I care. I care for two reasons. First is a personal experience. At my home, I have a standing load of = about 25 (plus or minus) packets per second that are discarded by the = firewall. I don't know what they are, and I don't honestly care. They = don't have my permission to be in my network, and I have to assume that = if they were to get into it, the hosts in my network would have to deal = with them. Second and more importantly, this came up with James Woodyat was = building the Airport Express IPv6 capability for Apple, and is the = reason that he wrote what is now RFC 6092. He released a product that = provided an IPv6 CPE router, and his marketing department came back and = told him that a firewall capability was a market requirement for such a = product - "if you don't build it, we can't sell it." Now, you can argue = that it *shouldn't* be a market requirement; I'll let you tilt at that = windmill if you like. Cisco is building IPv6 firewalls as well, and = various other folks are. The reason is not that we want to run out and = sell folks on the idea. It's that people tell us that they won't buy our = networks without them.= From brian.e.carpenter@gmail.com Tue Mar 13 17:38:26 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C790221E8048 for ; Tue, 13 Mar 2012 17:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.44 X-Spam-Level: X-Spam-Status: No, score=-103.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 wQV-ZIrdaOew for ; Tue, 13 Mar 2012 17:38:26 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99B8121F8540 for ; Tue, 13 Mar 2012 17:38:23 -0700 (PDT) Received: by yenm5 with SMTP id m5so1398237yen.31 for ; Tue, 13 Mar 2012 17:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Vs2J02aVbG2ru/bbtFV950DPisy1AOWXTOoJ9ptNU9A=; b=WjVOr5/e+0bhcSsnCDfoC8m9ap0LA2JY+iwcSHShdJZgHpexC4Gf1g0k5sEfLIYy// Kmc0qOsTJH64vihjJ0k9p7I9ehP/qS/qqwuyrGtbGlED2F9RvvhIfzZ3i4aweYGZUuC4 lQEgXlfvGPzVpfcW88K9vZb9AWl8mQCVZ3FWFnIMnrO2mgJt5Xi4Y9fBhY3BOAGsjUx+ RmhU2V6fkUuJpLf59X7D5PnpKccVjeqVn/vSXywHEFi+1RsRY4JiPeFT9VMhPRcUKnbl JaiDI3gkxobESgMc1ORLgsA33EjIuGgNX3D6cdDYl/PjydV9RqHYb88LSujKNZaQZjYL At3w== Received: by 10.236.182.67 with SMTP id n43mr640509yhm.75.1331685503293; Tue, 13 Mar 2012 17:38:23 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id o41sm4949639yhj.7.2012.03.13.17.38.20 (version=SSLv3 cipher=OTHER); Tue, 13 Mar 2012 17:38:22 -0700 (PDT) Message-ID: <4F5FE875.9040904@gmail.com> Date: Wed, 14 Mar 2012 13:38:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <13119.1331487384@marajade.sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?Um9nZXIgSsO4cmdlbnNlbg==?= , "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 00:38:26 -0000 On 2012-03-14 11:25, Fred Baker wrote: ... > First is a personal experience. At my home, I have a standing load of about 25 (plus or minus) packets per second that are discarded by the firewall. I don't know what they are, and I don't honestly care. They don't have my permission to be in my network, and I have to assume that if they were to get into it, the hosts in my network would have to deal with them. >From time to time I look at TCPView to see what's going on. At this instant, to my knowledge, I'm doing nothing on my machine except typing this email. TCPView tells me I have 63 endpoints (sockets) open, with 18 established TCP connections, and 14 sockets listening. Admittedly some of these sockets are connected to the loopback address, but even so, it's scary. What are all those .exe files listening on a socket all day? Windows Firewall is dropping about 3 UDP packets per second, and that's behind our campus firewall. That's reality, and much as I love the e2e principle I think the ordinary citizen is better off behind default-deny. Personally I haven't run without an on-board firewall since I got my first wireless card (late 1999?). But we can't assume that applies to every home device. Brian From cb.list6@gmail.com Tue Mar 13 18:16:06 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049C721E8015 for ; Tue, 13 Mar 2012 18:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sbvI8rChHuuz for ; Tue, 13 Mar 2012 18:16:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEDC21E8013 for ; Tue, 13 Mar 2012 18:16:05 -0700 (PDT) Received: by mail-yx0-f172.google.com with SMTP id m5so1427806yen.31 for ; Tue, 13 Mar 2012 18:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Pt4MfTsHdyl5IpA9wZDriuAtQpRY+bM/tvd0zo86WEA=; b=KNNG5HPu5LgfZ913VkTDcthISIePNZbysv1l2vz3X1Knq8f69OT7remeRHAxyrQQAa yXhI1QpRJT0nwqf30PasmxsQDv8epHO50pA/Scs0ksMU5+VsX0WPA/v+5a0jkPWsO/SI D0hjUTUY8/TkKHMR6BAzTrFQcrd/9zbm753Pt2OYrxAYcus2nCC29OL+f6qv3FbbkUKk FlzMYorztTWoO6pFyyE3+7tELgWKSGLzrUHLEjHNMuTQkb3dwFyi2rLdVvD1T3QuYIif xe8BLjpJ7NW2oIXf46CYYKkAbVMR2pk/S4HYRwYRe6YiUDBlUdfx9PrnouVl5o/Z5F1x Dsmw== MIME-Version: 1.0 Received: by 10.182.1.4 with SMTP id 4mr617001obi.67.1331687764963; Tue, 13 Mar 2012 18:16:04 -0700 (PDT) Received: by 10.182.192.41 with HTTP; Tue, 13 Mar 2012 18:16:04 -0700 (PDT) Received: by 10.182.192.41 with HTTP; Tue, 13 Mar 2012 18:16:04 -0700 (PDT) In-Reply-To: <4F5FE875.9040904@gmail.com> References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> Date: Tue, 13 Mar 2012 18:16:04 -0700 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d0447a0bd2eb1a604bb29b865 Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , "homenet@ietf.org Group" , Michael Richardson , Fred Baker Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 01:16:06 -0000 --f46d0447a0bd2eb1a604bb29b865 Content-Type: text/plain; charset=ISO-8859-1 On Mar 13, 2012 5:38 PM, "Brian E Carpenter" wrote: > > On 2012-03-14 11:25, Fred Baker wrote: > ... > > First is a personal experience. At my home, I have a standing load of about 25 (plus or minus) packets per second that are discarded by the firewall. I don't know what they are, and I don't honestly care. They don't have my permission to be in my network, and I have to assume that if they were to get into it, the hosts in my network would have to deal with them. > > From time to time I look at TCPView to see what's going on. At this > instant, to my knowledge, I'm doing nothing on my machine except typing > this email. TCPView tells me I have 63 endpoints (sockets) open, with > 18 established TCP connections, and 14 sockets listening. Admittedly > some of these sockets are connected to the loopback address, but even > so, it's scary. What are all those .exe files listening on a socket > all day? > > Windows Firewall is dropping about 3 UDP packets per second, and that's > behind our campus firewall. > > That's reality, and much as I love the e2e principle I think the ordinary > citizen is better off behind default-deny. > I am not trying to be dense, but why? What is the negative scenario of not having a homenet firewall on? Using real examples from the last 5 years .... I would like to know how a cpe firewall protects against real threats to modern software. > Personally I haven't run without an on-board firewall since I got my > first wireless card (late 1999?). But we can't assume that applies to > every home device. > Most PC software has shipped with a firewall on for the last ~10 years Cb > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --f46d0447a0bd2eb1a604bb29b865 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 13, 2012 5:38 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> On 2012-03-14 11:25, Fred Baker wrote:
> ...
> > First is a personal experience. At my home, I have a standing loa= d of about 25 (plus or minus) packets per second that are discarded by the = firewall. I don't know what they are, and I don't honestly care. Th= ey don't have my permission to be in my network, and I have to assume t= hat if they were to get into it, the hosts in my network would have to deal= with them.
>
> From time to time I look at TCPView to see what's going on. At thi= s
> instant, to my knowledge, I'm doing nothing on my machine except t= yping
> this email. TCPView tells me I have 63 endpoints (sockets) open, with<= br> > 18 established TCP connections, and 14 sockets listening. Admittedly > some of these sockets are connected to the loopback address, but even<= br> > so, it's scary. What are all those .exe files listening on a socke= t
> all day?
>
> Windows Firewall is dropping about 3 UDP packets per second, and that&= #39;s
> behind our campus firewall.
>
> That's reality, and much as I love the e2e principle I think the o= rdinary
> citizen is better off behind default-deny.
>

I am not trying to be dense, but why?

What is the negative scenario of not having a homenet firewall on? Using= real examples from the last 5 years .... I would like to know how a cpe fi= rewall protects against real threats to modern software.

> Personally I haven't run without an on-board firewall since I g= ot my
> first wireless card (late 1999?). But we can't assume that applies= to
> every home device.
>

Most PC software has shipped with a firewall on for the last ~10 years

Cb
> =A0 Brian
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.= ietf.org/mailman/listinfo/homenet

--f46d0447a0bd2eb1a604bb29b865-- From therbst@silverspringnet.com Tue Mar 13 18:21:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237AB21F85AC for ; Tue, 13 Mar 2012 18:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 djbeFti52Fv4 for ; Tue, 13 Mar 2012 18:21:51 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 69E3E21F859B for ; Tue, 13 Mar 2012 18:21:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAC/yX08KOQxz/2dsb2JhbAA5CrZ7ggkBAQEEAQEBawEKEgEIDQtVCyUBAQQBDQWIFbstiiiGTgSIIjOTBooYgwU X-IronPort-AV: E=Sophos;i="4.73,580,1325491200"; d="scan'208";a="9902254" Received: from unknown (HELO SFO-EXCA-02.silverspringnet.com) ([10.57.12.115]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 13 Mar 2012 18:21:50 -0700 Received: from IT-EXCA-01.silverspringnet.com (10.200.1.60) by SFO-EXCA-02.silverspringnet.com (10.57.12.101) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 13 Mar 2012 18:21:50 -0700 Received: from IT-RESTORE-01.silverspringnet.com ([::1]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Tue, 13 Mar 2012 18:21:50 -0700 From: Thomas Herbst To: Fred Baker , =?iso-8859-1?Q?Roger_J=F8rgensen?= Date: Tue, 13 Mar 2012 18:21:49 -0700 Thread-Topic: [homenet] Security goals Thread-Index: Ac0BgNQJDnMRNtjETcKQs7mhN/8zLw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 01:21:52 -0000 The Apple marketing department had some external input - http://web.nvd.nist.gov/view/vuln/detail?vulnId=3DCVE-2007-1338 On 3/13/12 3:25 PM, "Fred Baker" wrote: >On Mar 12, 2012, at 2:44 AM, Roger J=F8rgensen wrote: >> About security for end-users, why should it be deny by default? It >>don't really rise the security level by much since virus/trojans get in >>through user initiated action, and out again just as easy in the >>background. > >From my perspective, there is a question of what is being defended and of >defense in depth, and a question of market requirement. > >I agree that a firewall of any kind doesn't defend the host, since the >vast majority of attacks come from behind the firewall. What a firewall >defends is primarily the bandwidth within the defended domain - which >would be best done if the firewall was at the ISP (before the typical >bottleneck link). > >However, it does prevent certain kinds of messages from getting to a host >that don't have a reason to get there. The net effect is to make the >attack surface of the host smaller from the perspective of attacks from >the outside - the attack has to thread two needles, not just one. > >The general argument against "default deny" is that it prevents >legitimate traffic from reaching the host. I'll argue that this is >exactly the right model for traffic that the host has no application to >process - traffic that look legitimate but isn't because of the set of >applications running on the host. Take, for example, a host that is >prepared to operate as an http client but not a server; a packet directed >to an http server on it is going to be refused by the host, and could be >refused anywhere in the path. The problem with something that is >literally "default deny" is that it needs a way to identify and apply >rules like "sending smtp to smtp.example.com is reasonable". I'll argue >that protocols like PCP are reasonable ways to do that; "default deny" >plus PCP does *not* prevent legitimate traffic from getting to the host, >but it does prevent unwanted traffic from arriving at the host. > >You'll ask why I care. I care for two reasons. > >First is a personal experience. At my home, I have a standing load of >about 25 (plus or minus) packets per second that are discarded by the >firewall. I don't know what they are, and I don't honestly care. They >don't have my permission to be in my network, and I have to assume that >if they were to get into it, the hosts in my network would have to deal >with them. > >Second and more importantly, this came up with James Woodyat was building >the Airport Express IPv6 capability for Apple, and is the reason that he >wrote what is now RFC 6092. He released a product that provided an IPv6 >CPE router, and his marketing department came back and told him that a >firewall capability was a market requirement for such a product - "if you >don't build it, we can't sell it." Now, you can argue that it *shouldn't* >be a market requirement; I'll let you tilt at that windmill if you like. >Cisco is building IPv6 firewalls as well, and various other folks are. >The reason is not that we want to run out and sell folks on the idea. >It's that people tell us that they won't buy our networks without them. >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From ashokn@cisco.com Tue Mar 13 20:29:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D24321E805A for ; Tue, 13 Mar 2012 20:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 5P6uUju-rLUV for ; Tue, 13 Mar 2012 20:29:50 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8F61A21E8017 for ; Tue, 13 Mar 2012 20:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ashokn@cisco.com; l=4635; q=dns/txt; s=iport; t=1331695790; x=1332905390; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Fz/rIbdw+wvLcv09M5693gGu/T6gcr0Q5BGSy32m86w=; b=gwLZwoTNUT8fxgWuwQmlTdrBZI5cSMs4tIoyb5+RdDYNkF85csZDvqvG cbsj7AfGbe6KaRj1quUD4RUESp0NfsnzsK0+17HEs3mgtw7CaEuYs3tPI e++rb3Z94RtcBVYohsB7MPilHJUQDIxoXq1TJUk51sayTSt/T4N83t27J 8=; X-IronPort-AV: E=Sophos;i="4.73,580,1325462400"; d="scan'208,217";a="66024866" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2012 03:29:50 +0000 Received: from che-vpn-cluster-1-421.cisco.com (che-vpn-cluster-1-421.cisco.com [10.86.241.166]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2E3TnW4025523; Wed, 14 Mar 2012 03:29:49 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_7C0E3CE1-B6B1-4707-AC25-1BE9277401B7" From: Ashok Narayanan In-Reply-To: Date: Tue, 13 Mar 2012 23:29:48 -0400 Message-Id: References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "homenet@ietf.org Group" , Fred Baker , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 03:29:51 -0000 --Apple-Mail=_7C0E3CE1-B6B1-4707-AC25-1BE9277401B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote: >=20 > > That's reality, and much as I love the e2e principle I think the = ordinary > > citizen is better off behind default-deny. > > >=20 > I am not trying to be dense, but why? >=20 > What is the negative scenario of not having a homenet firewall on? = Using real examples from the last 5 years .... I would like to know how = a cpe firewall protects against real threats to modern software. >=20 It seems hard to predict a priori what a "real threat" is going to be. = And it seems unlikely that "modern software" is all that will be found = in average homes. For example, will the Android version on the = refrigerator display be updated?=20 > > Personally I haven't run without an on-board firewall since I got my > > first wireless card (late 1999?). But we can't assume that applies = to > > every home device. > > >=20 > Most PC software has shipped with a firewall on for the last ~10 years >=20 And these have to be then managed, and the triggers for "should this = flow be allowed" will then transition to the PC as opposed to the CPE. = Did the system become any simpler, really? But the real issue to my mind is _non-PC_ software; the firmware on some = power-line bridge written for the cheapest dollar by pulling together = some version of Linux because the device had to sell for $25. Not only = do all these devices now need firewalls (unlikely), they now need an = easy way to manage these firewalls (next to impossible). -Ashok > Cb > > Brian > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_7C0E3CE1-B6B1-4707-AC25-1BE9277401B7 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1
On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote:


> That's reality, and much as I love the e2e principle I think the ordinary
> citizen is better off behind default-deny.
>

I am not trying to be dense, but why?

What is the negative scenario of not having a homenet firewall on? Using real examples from the last 5 years .... I would like to know how a cpe firewall protects against real threats to modern software.

It seems hard to predict a priori what a "real threat" is going to be. And it seems unlikely that "modern software" is all that will be found in average homes. For example, will the Android version on the refrigerator display be updated? 


> Personally I haven't run without an on-board firewall since I got my
> first wireless card (late 1999?). But we can't assume that applies to
> every home device.
>

Most PC software has shipped with a firewall on for the last ~10 years

And these have to be then managed, and the triggers for "should this flow be allowed" will then transition to the PC as opposed to the CPE. Did the system become any simpler, really?

But the real issue to my mind is _non-PC_ software; the firmware on some power-line bridge written for the cheapest dollar by pulling together some version of Linux because the device had to sell for $25. Not only do all these devices now need firewalls (unlikely), they now need an easy way to manage these firewalls (next to impossible).

-Ashok

Cb
>   Brian
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--Apple-Mail=_7C0E3CE1-B6B1-4707-AC25-1BE9277401B7-- From marka@isc.org Tue Mar 13 21:40:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3870521E805E for ; Tue, 13 Mar 2012 21:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] 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 c14M0LKzi7LK for ; Tue, 13 Mar 2012 21:40:16 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 7D79E21E8050 for ; Tue, 13 Mar 2012 21:40:15 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id A37325F98B1; Wed, 14 Mar 2012 04:39:54 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:913:f6bb:186e:dfdb]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4ABCE216C33; Wed, 14 Mar 2012 04:39:52 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 4F13A1E800C1; Wed, 14 Mar 2012 15:39:31 +1100 (EST) To: Ashok Narayanan From: Mark Andrews References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> In-reply-to: Your message of "Tue, 13 Mar 2012 23:29:48 EDT." Date: Wed, 14 Mar 2012 15:39:30 +1100 Message-Id: <20120314043931.4F13A1E800C1@drugs.dv.isc.org> Cc: Michael Richardson , Cameron Byrne , "homenet@ietf.org Group" , =?iso-8859-1?Q?Roger_J=F8rgensen?= , Fred Baker Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 04:40:18 -0000 In message , Ashok Narayanan wr ites: > On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote: > > >=20 > > > That's reality, and much as I love the e2e principle I think the = > ordinary > > > citizen is better off behind default-deny. > > > > >=20 > > I am not trying to be dense, but why? > >=20 > > What is the negative scenario of not having a homenet firewall on? = > Using real examples from the last 5 years .... I would like to know how = > a cpe firewall protects against real threats to modern software. > >=20 > It seems hard to predict a priori what a "real threat" is going to be. = > And it seems unlikely that "modern software" is all that will be found = > in average homes. For example, will the Android version on the = > refrigerator display be updated?=20 > > > > > Personally I haven't run without an on-board firewall since I got my > > > first wireless card (late 1999?). But we can't assume that applies = > to > > > every home device. > > > > >=20 > > Most PC software has shipped with a firewall on for the last ~10 years > >=20 > And these have to be then managed, and the triggers for "should this = > flow be allowed" will then transition to the PC as opposed to the CPE. = > Did the system become any simpler, really? > > But the real issue to my mind is _non-PC_ software; the firmware on some = > power-line bridge written for the cheapest dollar by pulling together = > some version of Linux because the device had to sell for $25. Not only = > do all these devices now need firewalls (unlikely), they now need an = > easy way to manage these firewalls (next to impossible). And for most of them "drop !RA-ANNOUNCED(source)" would be sufficient and achieves what a default drop at the CPE does. What would be really good would be to add a site prefix length to the RA prefix option. There is room in the option to do this. Knowing this would be useful for source/destination address selection. > -Ashok > > > Cb > > > Brian > > > _______________________________________________ > > > homenet mailing list > > > homenet@ietf.org > > > https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From cb.list6@gmail.com Tue Mar 13 22:11:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8D821F8555 for ; Tue, 13 Mar 2012 22:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 vxRDHfq8URnb for ; Tue, 13 Mar 2012 22:11:20 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 239E621F854E for ; Tue, 13 Mar 2012 22:11:20 -0700 (PDT) Received: by iazz13 with SMTP id z13so2071936iaz.31 for ; Tue, 13 Mar 2012 22:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=83iL16eT5mW1qtJVTF5tXfnVHGXO9X6IGn1sV/KlqGE=; b=z6coFR37zB7LUXl0fsczw++3FakicTuHYksmueVSoivkaexzTvZv0L1Vz+ogdesexL 4UD0xbig3xHqxMZwXa41EGJPD/LoU028pBC7HW/Zv+enXIJjfujoYsToMEqfOf8xbrUT OPL0TOHclpZPqStaiu6zb2Rm7jDE5yBDznfU4kJnm50tz24Whgpyja+FR8qQ42wusSOd I0r5IwozI/B1XFLl21Vg1KSmfwGvBh3GvKBTqDYlt2iTLu49xjyDkmUqLI5CCjGztyey Dx/V8LcecMIA8X1MjkQLM6MJDAZlQ5ZJoDQ9otu8nle2JjmdFlRP0qghysi20Z/iorbr SyLg== MIME-Version: 1.0 Received: by 10.68.242.166 with SMTP id wr6mr1708070pbc.99.1331701879197; Tue, 13 Mar 2012 22:11:19 -0700 (PDT) Received: by 10.142.163.16 with HTTP; Tue, 13 Mar 2012 22:11:19 -0700 (PDT) In-Reply-To: References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> Date: Tue, 13 Mar 2012 22:11:19 -0700 Message-ID: From: Cameron Byrne To: Ashok Narayanan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , "homenet@ietf.org Group" , Fred Baker , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 05:11:21 -0000 On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan wrote: > > On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote: > > >> That's reality, and much as I love the e2e principle I think the ordinar= y >> citizen is better off behind default-deny. >> > > I am not trying to be dense, but why? > > What is the negative scenario of not having a homenet firewall on? Using > real examples from the last 5 years .... I would like to know how a cpe > firewall protects against real threats to modern software. > > It seems hard to predict a priori what a "real threat" is going to be.=A0= And > it seems unlikely that "modern software" is all that will be found in > average homes. For example, will the Android version on the refrigerator > display be updated? > Agreed about a priori. BUT! what else do we have to go on? I am asking for a baseline to justify why a CPE firewall is required. In fact, i have asked for it multiple times on this thread, and all i get back is anecdotal hand waving, not technical reasons. Putting the E back in IETF, let's see some data about why this function of the system must exist. My cursory research says you are not going to be able to present a convincing amount of data to support the fact that a stateful inspection firewall should be applied in a contemporary home environment. I believe the spirit of Homenet is moving the internet forward without being beholden to the Morris worm and X.25 You mention Android running on the refrigerator, as if i am supposed to be concerned about that? Can you cite an example of an Android security flaw that a CPE firewall would have ever prevented? My guess is no, android does not listen on any ports (default non-root)... thus no inbound connections... thus... stateful firewall does not have a technical justification for obstructing e2e flows. If you want to talk about rooted devices running BIND 4.0, well... that person that is wise enough to manually do that i likely wise enough to allow the relevant firewall rules or PCP interactions to allow the bad guys in as well. > >> Personally I haven't run without an on-board firewall since I got my >> first wireless card (late 1999?). But we can't assume that applies to >> every home device. >> > > Most PC software has shipped with a firewall on for the last ~10 years > > And these have to be then managed, and the triggers for "should this flow= be > allowed" will then transition to the PC as opposed to the CPE. Did the > system become any simpler, really? > I think there is some 3rd party off the shelf software that does these pop-ups.... but the PCs i run with native firewalls have never popped up to me like that. But, i agree... pop ups are not helpful. As an end user, i can proudly say i have a host based firewalls, but i have not once ever administered one (except sometimes i turn off the FW so i can ping my PC) > But the real issue to my mind is _non-PC_ software; the firmware on some > power-line bridge written for the cheapest dollar by pulling together som= e > version of Linux because the device had to sell for $25. Not only do all > these devices now need firewalls (unlikely), they now need an easy way to > manage these firewalls (next to impossible). > power-line bridge? Once again, please paint for me a realistic scenario of how a CPE firewall will protect this device? My first statement is that this device should not have a globally routable address, and therefore is not exposed to the internet, and does not need the CPE to filter for it. This is a good case for ULA in IPv6. Second, crappy software should not be tolerated or compensated for in Homenet. Setting the president that flawed software is acceptable is a slippery slope to somewhere bad. If it takes making application and host security requirements for endpoint, so be it. Passing the buck to the CPE/Firewall to give the illusion of security is not the right path. Tolerating broken software is also not the right path. Homenet is a unique opportunity to restore end to end ... or as some would say... the internet model.. Smart end points, dumb network. If we need a smart network, then lets make a real solid fact based exploration of threats and then we can select the appropriate compensating security controls. CB > -Ashok > > Cb >> =A0 Brian >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > From rturner@amalfisystems.com Tue Mar 13 22:20:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C3021F85DB for ; Tue, 13 Mar 2012 22:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 lRIE6FXmhrcw for ; Tue, 13 Mar 2012 22:20:41 -0700 (PDT) Received: from omr9.networksolutionsemail.com (omr9.networksolutionsemail.com [205.178.146.59]) by ietfa.amsl.com (Postfix) with ESMTP id 4016B21F85D3 for ; Tue, 13 Mar 2012 22:20:41 -0700 (PDT) Received: from cm-omr2 (mail.networksolutionsemail.com [205.178.146.50]) by omr9.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q2E5KdJr021424 for ; Wed, 14 Mar 2012 01:20:39 -0400 Authentication-Results: cm-omr2 smtp.user=rturner@amalfisystems.com; auth=pass (CRAM-MD5) X-Authenticated-UID: rturner@amalfisystems.com Received: from [98.151.18.158] ([98.151.18.158:63416] helo=[192.168.1.114]) by cm-omr2 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPSA (cipher=AES128-SHA) id C5/90-09323-7AA206F4; Wed, 14 Mar 2012 01:20:39 -0400 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) From: Randy Turner In-Reply-To: Date: Tue, 13 Mar 2012 22:20:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8382ADD0-B3B1-4B66-9C6A-7DFCB8158603@amalfisystems.com> References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1257) Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 05:20:42 -0000 You can have real e2e even with a middlebox performing some type of = security, so e2e and CPE-firewall are not mutually exclusive. The CPE firewall (we really need to decide the functionality of what = we're calling a firewall here) would be a way to centralize some amount of security policy for the home network. Having every device on the = home network support a complete security solution is not realistic. = Seems like the CPE will be involved for some aspects of security that are common to = the home network, and then there would be devices on the home network = that are also "secured", possibly depending upon the application or = functionality of the device. Consumers are not going to want to manage security policy in 20 = different ways on the home network for 20 different devices. I think at = a minimum, the ISP (or NSP) may want to offer a "managed security" = service for the CPE to take over the burden of the average consumer = having to know what the details of security policy. Randy On Mar 13, 2012, at 10:11 PM, Cameron Byrne wrote: > On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan = wrote: >>=20 >> On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote: >>=20 >>=20 >>> That's reality, and much as I love the e2e principle I think the = ordinary >>> citizen is better off behind default-deny. >>>=20 >>=20 >> I am not trying to be dense, but why? >>=20 >> What is the negative scenario of not having a homenet firewall on? = Using >> real examples from the last 5 years .... I would like to know how a = cpe >> firewall protects against real threats to modern software. >>=20 >> It seems hard to predict a priori what a "real threat" is going to = be. And >> it seems unlikely that "modern software" is all that will be found in >> average homes. For example, will the Android version on the = refrigerator >> display be updated? >>=20 >=20 > Agreed about a priori. BUT! what else do we have to go on? I am > asking for a baseline to justify why a CPE firewall is required. In > fact, i have asked for it multiple times on this thread, and all i get > back is anecdotal hand waving, not technical reasons. >=20 > Putting the E back in IETF, let's see some data about why this > function of the system must exist. >=20 > My cursory research says you are not going to be able to present a > convincing amount of data to support the fact that a stateful > inspection firewall should be applied in a contemporary home > environment. I believe the spirit of Homenet is moving the internet > forward without being beholden to the Morris worm and X.25 >=20 > You mention Android running on the refrigerator, as if i am supposed > to be concerned about that? Can you cite an example of an Android > security flaw that a CPE firewall would have ever prevented? My > guess is no, android does not listen on any ports (default > non-root)... thus no inbound connections... thus... stateful firewall > does not have a technical justification for obstructing e2e flows. >=20 > If you want to talk about rooted devices running BIND 4.0, well... > that person that is wise enough to manually do that i likely wise > enough to allow the relevant firewall rules or PCP interactions to > allow the bad guys in as well. >=20 >>=20 >>> Personally I haven't run without an on-board firewall since I got my >>> first wireless card (late 1999?). But we can't assume that applies = to >>> every home device. >>>=20 >>=20 >> Most PC software has shipped with a firewall on for the last ~10 = years >>=20 >> And these have to be then managed, and the triggers for "should this = flow be >> allowed" will then transition to the PC as opposed to the CPE. Did = the >> system become any simpler, really? >>=20 >=20 > I think there is some 3rd party off the shelf software that does these > pop-ups.... but the PCs i run with native firewalls have never popped > up to me like that. But, i agree... pop ups are not helpful. >=20 > As an end user, i can proudly say i have a host based firewalls, but i > have not once ever administered one (except sometimes i turn off the > FW so i can ping my PC) >=20 >> But the real issue to my mind is _non-PC_ software; the firmware on = some >> power-line bridge written for the cheapest dollar by pulling together = some >> version of Linux because the device had to sell for $25. Not only do = all >> these devices now need firewalls (unlikely), they now need an easy = way to >> manage these firewalls (next to impossible). >>=20 >=20 > power-line bridge? >=20 > Once again, please paint for me a realistic scenario of how a CPE > firewall will protect this device? >=20 > My first statement is that this device should not have a globally > routable address, and therefore is not exposed to the internet, and > does not need the CPE to filter for it. This is a good case for ULA > in IPv6. >=20 > Second, crappy software should not be tolerated or compensated for in > Homenet. Setting the president that flawed software is acceptable is > a slippery slope to somewhere bad. If it takes making application and > host security requirements for endpoint, so be it. Passing the buck > to the CPE/Firewall to give the illusion of security is not the right > path. Tolerating broken software is also not the right path. >=20 > Homenet is a unique opportunity to restore end to end ... or as some > would say... the internet model.. Smart end points, dumb network. >=20 > If we need a smart network, then lets make a real solid fact based > exploration of threats and then we can select the appropriate > compensating security controls. >=20 > CB >=20 >> -Ashok >>=20 >> Cb >>> Brian >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >>=20 >>=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 From mr.r.a.hunter@gmail.com Wed Mar 14 04:04:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE97E21F86C1 for ; Wed, 14 Mar 2012 04:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 aVS4+jzFX0NW for ; Wed, 14 Mar 2012 04:04:41 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 431A121F86B3 for ; Wed, 14 Mar 2012 04:04:41 -0700 (PDT) Received: by bkuw5 with SMTP id w5so1376184bku.31 for ; Wed, 14 Mar 2012 04:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=CqgHu4Sk5KD3x62WaqJWI2zdDcUEN10bB68KHkPSU2s=; b=TL4qy1P74qttg55vFkAcSTQY5Tne4EeHPSlFX0ySyEBPJB8VDytwKppqRHl6aXAgMp p3h6MjAPnvRssy6bmYTgp3Twp/RBPlAgp6AHJcD0RCc9tDRdxVyUu3FujEklG/JDo5sK 64f02ink2F8EbuM7zczrTd57xSM+q/cfaIE9+ppwOTrn5aqR2PuoyCSfqP8NKzbzmhGt pepXPe/jOE8/4zJYIP4irHzR4+w6m40o6ft3BkIYLvQzyfBEwRsJFJNxvvmwjrcUSNnx i4IRngFiWYqX2hEAYfw5FxgiWTjJr1WcjEs27NwsV75EKh0h56hNH2pUidJskYUmQcgi RzpQ== Received: by 10.204.150.82 with SMTP id x18mr812796bkv.10.1331723080254; Wed, 14 Mar 2012 04:04:40 -0700 (PDT) Received: from Rays-iMac.local (machine.globis.net. [2001:470:d38c:2::4]) by mx.google.com with ESMTPS id f6sm7120886bkg.10.2012.03.14.04.04.38 (version=SSLv3 cipher=OTHER); Wed, 14 Mar 2012 04:04:39 -0700 (PDT) Message-ID: <4F607B45.6010908@gmail.com> Date: Wed, 14 Mar 2012 12:04:37 +0100 From: "Mr.R.A.Hunter" User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Cameron Byrne References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090705040608060706010008" X-Mailman-Approved-At: Wed, 14 Mar 2012 04:25:24 -0700 Cc: =?ISO-8859-1?Q?Roger?= =?ISO-8859-1?Q?_J=F8rgensen?= , "homenet@ietf.org Group" , Fred Baker , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 11:04:42 -0000 This is a multi-part message in MIME format. --------------090705040608060706010008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit My personal take on the situation is that security threats and tolerance levels vary per organization and per individual. There's no point in the IETF trying to perform a Business Impact Analysis and then attempting to generate the appropriate Security Norms as defined in the ISO27000 series on behalf of all Internet users. It simply can't be done. Suggested Homenet Security Goal: Provide feature equivalence to today's IPv4 solutions that are already widely deployed in the home. Simple, clear, and addresses the concerns expressed in the NIST advisory CVE-2007-1338 and the marketing department. Or would you like to swim against the tide of operational expectations and huge installed base of devices inherited from IPv4? That would seem to me like a very bad idea to deploy as default behavior in a dual stack World where IPv4 and IPv6 run in parallel over the same devices and links. Equally, choosing for a security model based on equivalence with existing IPv4-functionality would at first glance seem to place draft-vyncke-advanced-ipv6-security-03 out of reach until the devices were IPv6 only. But to me that draft just seems like too radical a step towards an IDP type approach to be able to gain traction quickly in the home, at least as default behavior. Who's going to want to pay for maintaining attack signatures? One useful compromise would be for Homenet to explicitly add the option for a user to be able to completely disable the default stateful packet filtering firewall of RFC6092 (ask a grown up before selecting this option), so that the user could deploy the model described in draft-vyncke-advanced-ipv6-security-03 using their favorite open-source IDP with attack signatures, or other security model, should they really want to. Intentionally disabling /bypassing NAT and the built in firewall in IPv4 devices was really hard. IMHO We should at least make that easy in Homenet devices for those who really want non-default behavior (via PCP and manual configuration options). regards, RayH Cameron Byrne wrote: > > > On Mar 13, 2012 5:38 PM, "Brian E Carpenter" > > wrote: > > > > On 2012-03-14 11:25, Fred Baker wrote: > > ... > > > First is a personal experience. At my home, I have a standing load > of about 25 (plus or minus) packets per second that are discarded by > the firewall. I don't know what they are, and I don't honestly care. > They don't have my permission to be in my network, and I have to > assume that if they were to get into it, the hosts in my network would > have to deal with them. > > > > From time to time I look at TCPView to see what's going on. At this > > instant, to my knowledge, I'm doing nothing on my machine except typing > > this email. TCPView tells me I have 63 endpoints (sockets) open, with > > 18 established TCP connections, and 14 sockets listening. Admittedly > > some of these sockets are connected to the loopback address, but even > > so, it's scary. What are all those .exe files listening on a socket > > all day? > > > > Windows Firewall is dropping about 3 UDP packets per second, and that's > > behind our campus firewall. > > > > That's reality, and much as I love the e2e principle I think the > ordinary > > citizen is better off behind default-deny. > > > > I am not trying to be dense, but why? > > What is the negative scenario of not having a homenet firewall on? > Using real examples from the last 5 years .... I would like to know > how a cpe firewall protects against real threats to modern software. > > > Personally I haven't run without an on-board firewall since I got my > > first wireless card (late 1999?). But we can't assume that applies to > > every home device. > > > > Most PC software has shipped with a firewall on for the last ~10 years > > Cb > > Brian > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > --------------090705040608060706010008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit My personal take on the situation is that security threats and tolerance levels vary per organization and per individual. There's no point in the IETF trying to perform a Business Impact Analysis and then attempting to generate the appropriate Security Norms as defined in the ISO27000 series on behalf of all Internet users. It simply can't be done.

Suggested Homenet Security Goal: Provide feature equivalence to today's IPv4 solutions that are already widely deployed in the home.

Simple, clear, and addresses the concerns expressed in the NIST advisory CVE-2007-1338 and the marketing department.

Or would you like to swim against the tide of operational expectations and huge installed base of devices inherited from IPv4? That would seem to me like a very bad idea to deploy as default behavior in a dual stack World where IPv4 and IPv6 run in parallel over the same devices and links.

Equally, choosing for a security model based on equivalence with existing IPv4-functionality would at first glance seem to place draft-vyncke-advanced-ipv6-security-03 out of reach until the devices were IPv6 only. But to me that draft just seems like too radical a step towards an IDP type approach to be able to gain traction quickly in the home, at least as default behavior. Who's going to want to pay for maintaining attack signatures?

One useful compromise would be for Homenet to explicitly add the option for a user to be able to completely disable the default stateful packet filtering firewall of RFC6092 (ask a grown up before selecting this option), so that the user could deploy the model described in draft-vyncke-advanced-ipv6-security-03 using their favorite open-source IDP with attack signatures, or other security  model, should they really want to.

Intentionally disabling /bypassing NAT and the built in firewall in IPv4 devices was really hard. IMHO We should at least make that easy in Homenet devices for those who really want non-default behavior (via PCP and manual configuration options).

regards,
RayH

Cameron Byrne wrote:


On Mar 13, 2012 5:38 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>
> On 2012-03-14 11:25, Fred Baker wrote:
> ...
> > First is a personal experience. At my home, I have a standing load of about 25 (plus or minus) packets per second that are discarded by the firewall. I don't know what they are, and I don't honestly care. They don't have my permission to be in my network, and I have to assume that if they were to get into it, the hosts in my network would have to deal with them.
>
> From time to time I look at TCPView to see what's going on. At this
> instant, to my knowledge, I'm doing nothing on my machine except typing
> this email. TCPView tells me I have 63 endpoints (sockets) open, with
> 18 established TCP connections, and 14 sockets listening. Admittedly
> some of these sockets are connected to the loopback address, but even
> so, it's scary. What are all those .exe files listening on a socket
> all day?
>
> Windows Firewall is dropping about 3 UDP packets per second, and that's
> behind our campus firewall.
>
> That's reality, and much as I love the e2e principle I think the ordinary
> citizen is better off behind default-deny.
>

I am not trying to be dense, but why?

What is the negative scenario of not having a homenet firewall on? Using real examples from the last 5 years .... I would like to know how a cpe firewall protects against real threats to modern software.

> Personally I haven't run without an on-board firewall since I got my
> first wireless card (late 1999?). But we can't assume that applies to
> every home device.
>

Most PC software has shipped with a firewall on for the last ~10 years

Cb
>   Brian
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet


--------------090705040608060706010008-- From ashokn@cisco.com Wed Mar 14 07:04:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E76021F8656 for ; Wed, 14 Mar 2012 07:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 WQ0OafbIQG9b for ; Wed, 14 Mar 2012 07:04:39 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 525BC21F87A4 for ; Wed, 14 Mar 2012 07:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ashokn@cisco.com; l=7274; q=dns/txt; s=iport; t=1331733872; x=1332943472; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Vm9o2llnFO2jeu4AQDfvWvIJN/eFYUorHEinZ6lsd48=; b=m259/DziNeNRSKBlmJqey0IDOePyofP1sDV79VLS7C1Gc2kObRXjIKqv atpzBCKsW/Nsaz2NIvX324GTFLdYWF7xNQnkjALU/UXefWQqqjA1Fkw3t 8pXoz3mbDJ/EJ4Z+e58zmmGLtgqPwiwZLI9XC8Xw7XRDSZ9rZfPQvj4DK o=; X-IronPort-AV: E=Sophos;i="4.73,584,1325462400"; d="scan'208";a="66362448" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 14 Mar 2012 14:04:32 +0000 Received: from dhcp-161-44-183-67.cisco.com (dhcp-161-44-183-67.cisco.com [161.44.183.67]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2EE4VTd004216; Wed, 14 Mar 2012 14:04:31 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Ashok Narayanan In-Reply-To: Date: Wed, 14 Mar 2012 10:04:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <655AF962-6212-45B1-A685-E4489800CD29@cisco.com> References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1257) Cc: =?iso-8859-1?Q?Roger_J=F8rgensen?= , "homenet@ietf.org Group" , Fred Baker , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:04:40 -0000 On Mar 14, 2012, at 3/14 1:11 AM, Cameron Byrne wrote: > On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan = wrote: >>=20 >> On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote: >>=20 >>=20 >>> That's reality, and much as I love the e2e principle I think the = ordinary >>> citizen is better off behind default-deny. >>>=20 >>=20 >> I am not trying to be dense, but why? >>=20 >> What is the negative scenario of not having a homenet firewall on? = Using >> real examples from the last 5 years .... I would like to know how a = cpe >> firewall protects against real threats to modern software. >>=20 >> It seems hard to predict a priori what a "real threat" is going to = be. And >> it seems unlikely that "modern software" is all that will be found in >> average homes. For example, will the Android version on the = refrigerator >> display be updated? >>=20 >=20 > Agreed about a priori. BUT! what else do we have to go on? I am > asking for a baseline to justify why a CPE firewall is required. In > fact, i have asked for it multiple times on this thread, and all i get > back is anecdotal hand waving, not technical reasons. >=20 > Putting the E back in IETF, let's see some data about why this > function of the system must exist. >=20 > My cursory research says you are not going to be able to present a > convincing amount of data to support the fact that a stateful > inspection firewall should be applied in a contemporary home > environment. I believe the spirit of Homenet is moving the internet > forward without being beholden to the Morris worm and X.25 So as a thought experiment, does your hypothesis hold for any sort of = {firewall|NAT|blocking-device}? In other words, are you unconvinced that = any sort of centralized connection-management/protection device at the = home edge is not required? Or are you specifically unhappy about a SPI = firewall? >=20 > You mention Android running on the refrigerator, as if i am supposed > to be concerned about that? Can you cite an example of an Android > security flaw that a CPE firewall would have ever prevented? My > guess is no, android does not listen on any ports (default > non-root)... thus no inbound connections... thus... stateful firewall > does not have a technical justification for obstructing e2e flows. Doesn't that translate to "I haven't seen any security flaws in Software = X so far, so it is inconceivable that it would ever occur". This is = proof by example. >=20 > If you want to talk about rooted devices running BIND 4.0, well... > that person that is wise enough to manually do that i likely wise > enough to allow the relevant firewall rules or PCP interactions to > allow the bad guys in as well. No, I don't agree. The customer may well not even know that a device in = his home is running old/compromised software. This is a classic separation-of-costs problem. The product developer has = to weigh off security of his firmware (audits, continuous updates, etc) = against development cost. The thing that is most visible to the consumer = is cost, with security being a nebulous "nice-to-have". Hence, the = product developer is incentivized to cut costs by not doing the things = he needs. This is not universal, but common enough. >=20 >>=20 >>> Personally I haven't run without an on-board firewall since I got my >>> first wireless card (late 1999?). But we can't assume that applies = to >>> every home device. >>>=20 >>=20 >> Most PC software has shipped with a firewall on for the last ~10 = years >>=20 >> And these have to be then managed, and the triggers for "should this = flow be >> allowed" will then transition to the PC as opposed to the CPE. Did = the >> system become any simpler, really? >>=20 >=20 > I think there is some 3rd party off the shelf software that does these > pop-ups.... but the PCs i run with native firewalls have never popped > up to me like that. But, i agree... pop ups are not helpful. >=20 > As an end user, i can proudly say i have a host based firewalls, but i > have not once ever administered one (except sometimes i turn off the > FW so i can ping my PC) Again, proof by example. Can you make the same statement about = not-as-clueful family members? I for one get phone calls from my mom (in = Washington DC) every time her Norton firewall pops up a window.=20 But that's not the point, really, since the issue of permissions exists = for firewalls anywhere. The protection role of a NAT/firewall is not so = much to protect home computers (since they are capable of protecting = themselves). It's to protect non-computer networked devices.=20 =20 >=20 >> But the real issue to my mind is _non-PC_ software; the firmware on = some >> power-line bridge written for the cheapest dollar by pulling together = some >> version of Linux because the device had to sell for $25. Not only do = all >> these devices now need firewalls (unlikely), they now need an easy = way to >> manage these firewalls (next to impossible). >>=20 >=20 > power-line bridge? >=20 > Once again, please paint for me a realistic scenario of how a CPE > firewall will protect this device? By blocking connections to a management port left open by a careless = coder that might allow a remote exploit to install DDoS software on it? It doesn't solve all problems, but removes at least one attack surface. >=20 > My first statement is that this device should not have a globally > routable address, and therefore is not exposed to the internet, and > does not need the CPE to filter for it. This is a good case for ULA > in IPv6. Sure, and that would be a nice solution to this problem at least in my = mind - simple and mostly effective. But there are other discussions on = these lists that specifically talk about _not_ doing this, as a way to = get around issues seen with NAT today. >=20 > Second, crappy software should not be tolerated or compensated for in > Homenet. Setting the president that flawed software is acceptable is > a slippery slope to somewhere bad. If it takes making application and > host security requirements for endpoint, so be it. Passing the buck > to the CPE/Firewall to give the illusion of security is not the right > path. Tolerating broken software is also not the right path. A worthy goal, but kinda like saying "airbags give an illusion of = security. Speeding should not be tolerated". IOW, not gonna happen. >=20 > Homenet is a unique opportunity to restore end to end ... or as some > would say... the internet model.. Smart end points, dumb network. >=20 > If we need a smart network, then lets make a real solid fact based > exploration of threats and then we can select the appropriate > compensating security controls. >=20 > CB >=20 >> -Ashok >>=20 >> Cb >>> Brian >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >>=20 >>=20 From mcr@sandelman.ca Wed Mar 14 08:17:02 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F9A21E805F for ; Wed, 14 Mar 2012 08:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.536 X-Spam-Level: X-Spam-Status: No, score=-1.536 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 Wvqt9-bulKX1 for ; Wed, 14 Mar 2012 08:17:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4418321F87EF for ; Wed, 14 Mar 2012 08:16:59 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id 690C3344DA for ; Wed, 14 Mar 2012 11:14:20 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id BDCB5983B9; Wed, 14 Mar 2012 11:16:54 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id B805398281 for ; Wed, 14 Mar 2012 11:16:54 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org Group" In-Reply-To: <7D6717D7-9AEE-4C69-AFF5-BD4927B5A126@mbaugher.com> References: <13119.1331487384@marajade.sandelman.ca> <7D6717D7-9AEE-4C69-AFF5-BD4927B5A126@mbaugher.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 14 Mar 2012 11:16:54 -0400 Message-ID: <13475.1331738214@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:17:02 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mark" =3D=3D Mark Baugher writes: Mark> IETF Homenet will have a default policy for security and Mark> protocol operation, etc. Future vendors who ship Homenet may Mark> choose to change the default policy, and users who use Homenet Mark> may want to change the policy that the vendors ship. So I Mark> would expect that there may be policies that are required for Mark> compliance and many others that are recommended. Why can't Assuming that we get over the hurdle of having vendors and ISP implement and deploy homenet, and homenet security, whatever we set as the recommended default will be what is there for 99% of users, and therefore what anyone writing an application that has to live in the home is going to have to deal with. (That you and I can change our policies is great, but doesn't help=20 someone selling a new application to grandma) So, if we recommend something which does not facilitate e2e, including incoming connections, then we have killed e2e. While I'm not happy about Simple Security + PCP, I prefer that to killing e2e. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT2C2ZoqHRg3pndX9AQJK4QP+PUtQkNenEcMKqSuluNoQeByzikte+Rm2 Q7LBv7kJyDIXouhIbDVu6hgG49vRpCzw5+qVBbj0zDT4v2khz3Tiq/Zq+Lwe1IUi PJqUvkfOxZgi9fJkAY3I8nyBzQ9MRPfcCewld9ZmHWaFTplrRQbNf9yc1QJ3eo0A EDmj5nR1Tiw= =8Dp7 -----END PGP SIGNATURE----- --=-=-=-- From tjc@ecs.soton.ac.uk Wed Mar 14 08:47:30 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B54A21F879C for ; Wed, 14 Mar 2012 08:47:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP3YAQ8sLnqU for ; Wed, 14 Mar 2012 08:47:30 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id DACF521F8798 for ; Wed, 14 Mar 2012 08:47:28 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2EFlM5t000435 for ; Wed, 14 Mar 2012 15:47:22 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2EFlM5t000435 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1331740042; bh=lagHI4baFwS6FrhqR0cZEp0KLJc=; h=Subject:References:From:In-Reply-To:Date:To:Mime-Version; b=hSg52ekkxt9woOc260i3Nuf6xlwFteNi6dGoKN/VrFSbb84hYGJt7HYs7QRUL8QPr /vfF9Z+fMeiJsNoY7hgo1guIHTK2gE0k5R91DB3o8+/l3fKOEIw7b6DVTMy0gouRI1 l1XaBWhRLszVsojxFgIX3/Fpi6tauBT3VMZPmwZY= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o2DFlM0543753018g4 ret-id none; Wed, 14 Mar 2012 15:47:22 +0000 Received: from [152.78.204.236] (ip-204-236.eduroam.soton.ac.uk [152.78.204.236]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2EFlHsl004640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 14 Mar 2012 15:47:18 GMT References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> From: Tim Chown Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (9A405) In-Reply-To: Message-ID: Date: Wed, 14 Mar 2012 15:47:07 +0000 To: "homenet@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2DFlM054375301800; tid=o2DFlM0543753018g4; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2EFlM5t000435 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 15:47:30 -0000 On 13 Mar 2012, at 16:26, David R Oran wrote: > > On Mar 13, 2012, at 12:23 PM, Ralph Droms wrote:. >> >> "dotless name" == "pay-for-play TLDs" ??? >> > Just remember to dot your I(cann)s and cross your t(LD)s. > > Sorry, couldn't resist... Well let's hope ICANN don't cash in on .site while xmdns is being defined... Tim From fred@cisco.com Wed Mar 14 09:07:37 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5C21F8705 for ; Wed, 14 Mar 2012 09:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.308 X-Spam-Level: X-Spam-Status: No, score=-110.308 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 MSnziPspptvX for ; Wed, 14 Mar 2012 09:07:36 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id EDC2721F873A for ; Wed, 14 Mar 2012 09:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1863; q=dns/txt; s=iport; t=1331741256; x=1332950856; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=JpxBMkLqGf3+O26NAAibqL39nKwhN+3EB9bDBKkfLoM=; b=PUp4LJcFY1fxKSTJIOE+ug7wQG0JRcIe5QmUe/senccTq8sBxr6AF9gQ USRPLFI7vYW55RrEiGB6OmBI4qPsSjiVh2MoUMVrQHUnR1mjgbvuuuNN4 Wi/RJHIUEkmmho+UNd/FmRC0PPeKuim0H2RhqWtkInBaV/+24nSccVFd7 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMLBYE+tJXG9/2dsb2JhbABDtiyBB4IJAQEBAwESAWYFCwsEAUFXBjWHYwWca58rkBtjBIhXjH+Fa4hVgWiDBg X-IronPort-AV: E=Sophos;i="4.73,584,1325462400"; d="scan'208,217";a="66197770" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2012 16:07:35 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2EG7VGK009291; Wed, 14 Mar 2012 16:07:34 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 14 Mar 2012 09:07:35 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 14 Mar 2012 09:07:35 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4F607B45.6010908@gmail.com> Date: Wed, 14 Mar 2012 09:07:34 -0700 Message-Id: <2F66659B-C381-419C-B5F4-3F48EF4A6B93@cisco.com> References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F607B45.6010908@gmail.com> To: "Mr.R.A.Hunter" X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-65--900747436 Cc: Cameron Byrne , "homenet@ietf.org Group" , =?iso-8859-1?Q?Roger_J=F8rgensen?= , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 16:07:37 -0000 --Apple-Mail-65--900747436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 14, 2012, at 4:04 AM, Mr.R.A.Hunter wrote: > One useful compromise would be for Homenet to explicitly add the = option for a user to be able to completely disable the default stateful = packet filtering firewall of RFC6092=20 I suspect that they have it in any product, but it may be useful to say = that it is a requirement. --Apple-Mail-65--900747436 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
One useful = compromise would be for Homenet to explicitly add the option for a user = to be able to completely disable the default stateful packet filtering = firewall of RFC6092 
I suspect that they have it in any product, but it may be useful = to say that it is a requirement.

= --Apple-Mail-65--900747436-- From mcr@sandelman.ca Wed Mar 14 12:01:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E919121E8010 for ; Wed, 14 Mar 2012 12:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=1.213, BAYES_00=-2.599, GB_I_LETTER=-2, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 D2IopZr1pkbb for ; Wed, 14 Mar 2012 12:01:02 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA6321E800E for ; Wed, 14 Mar 2012 12:01:01 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id D9C1AA0080 for ; Wed, 14 Mar 2012 14:58:22 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id A70AE983B9; Wed, 14 Mar 2012 15:00:57 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 9B34C98281 for ; Wed, 14 Mar 2012 15:00:57 -0400 (EDT) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Wed, 14 Mar 2012 15:00:57 -0400 Message-ID: <11090.1331751657@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:01:04 -0000 >>>>> "Tim" == Tim Chown writes: >> Sorry, couldn't resist... Tim> Well let's hope ICANN don't cash in on .site while xmdns is Tim> being defined... That was my major comment about the document. I don't like .site. Yeah, it's generic enough to work everywhere. But, I think it will be confusing to the public. I think that .home would be better, but all of these are also rather english specific. Maybe there is an esperanto or lojban speaker that could give us a better four letter word. (cause, you know, it will be used in the context of my f#(#$ .*#$@# is busted!) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From dave.taht@gmail.com Wed Mar 14 12:18:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1285621F8677 for ; Wed, 14 Mar 2012 12:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 7dc+dRGtNR-j for ; Wed, 14 Mar 2012 12:18:57 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A87A121F8674 for ; Wed, 14 Mar 2012 12:18:56 -0700 (PDT) Received: by werb10 with SMTP id b10so2518838wer.31 for ; Wed, 14 Mar 2012 12:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KzuDPU6U652UKbt9V+UnkZNc4P0fp+DNoSdXULTzBBY=; b=iUMrwIjOhUkkmhpAwCW7jPYkQrFPz2KADwMGKC7OwyCGILC0q5jpnNT9Jl4VaTwCYF em+Zwn4RifV7Ns0Z3yw2cw98GJ8yMHQASQ6FmqYIEcrn8uNPtsdPAAH7RZSi+NjFNd8u XsmQCPxvM+QJPTs1kgApaDvE39H/690H8t0pL6K1S5/fYJLHGH8QPFJnmtR3vqsADUCK 5ckPV++mRocvh6UWjwnA/kwXerNfDdYSwA43PoE2knkuZG/TLmeA+7MwEAP1fmWnUhzw o2HrFREsGae+X4WnEb7Pu+oxzz5VHAsImQkrqdwD90PNriNuy8HwY8HaGPWOKfhWehnh jb2g== MIME-Version: 1.0 Received: by 10.180.98.8 with SMTP id ee8mr9098054wib.14.1331752735743; Wed, 14 Mar 2012 12:18:55 -0700 (PDT) Received: by 10.223.151.8 with HTTP; Wed, 14 Mar 2012 12:18:55 -0700 (PDT) In-Reply-To: <11090.1331751657@marajade.sandelman.ca> References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> Date: Wed, 14 Mar 2012 12:18:55 -0700 Message-ID: From: Dave Taht To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:18:58 -0000 On Wed, Mar 14, 2012 at 12:00 PM, Michael Richardson wro= te: > >>>>>> "Tim" =3D=3D Tim Chown writes: > =A0 =A0>> Sorry, couldn't resist... > > =A0 =A0Tim> Well let's hope ICANN don't cash in on .site while xmdns is > =A0 =A0Tim> being defined... > > That was my major comment about the document. > I don't like .site. =A0Yeah, it's generic enough to work everywhere. > But, I think it will be confusing to the public. =A0I think that .home > would be better, but all of these are also rather english specific. > > Maybe there is an esperanto or lojban speaker that could give us a > better four letter word. =A0(cause, you know, it will be used in the > context of my f#(#$ .*#$@# is busted!) What I have been using has been '.lan'. I've seen it used elsewhere, too, on private nets, but I have no idea how common it is. I was surprised to see it was what was used in the http://www.air-stream.org.au/ wireless net > > -- > ] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 = =A0 =A0 | =A0firewalls =A0[ > ] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|ne= t architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device d= river[ > =A0 Kyoto Plus: watch the video > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition. > > > > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net From fred@cisco.com Wed Mar 14 12:19:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 498F721F87DF for ; Wed, 14 Mar 2012 12:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.19 X-Spam-Level: X-Spam-Status: No, score=-110.19 tagged_above=-999 required=5 tests=[AWL=2.409, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 BvBcGcj1BqOE for ; Wed, 14 Mar 2012 12:19:26 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B97D421F87DE for ; Wed, 14 Mar 2012 12:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=310; q=dns/txt; s=iport; t=1331752767; x=1332962367; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=/NFxAgQJ0vv/9q25QHGSWuUqHqTbR/6Zu/JRsjtzqac=; b=ivJVODLQpGXSpY24NzJ/4KzjRQ9g4A393vU2VVIxNCE4PlIdexNVjZoM pu0Ww466txgkXDY1Yw55VT/1ERb9PSUbr1rXcs2qbumG+OpeSmxmgTzuo 061LLGxZEyvMgYCB5nc2RAyAa6i+rtzkHUBTY88g34z/Cc0bgwGo18lb8 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGbuYE+rRDoJ/2dsb2JhbABDti6BB4IJAQEBAwESASc/BQsLDgQ0SQ4GNYdjBJtXnzSQG2MEiFeMf4VriFWBaIMG X-IronPort-AV: E=Sophos;i="4.73,585,1325462400"; d="scan'208";a="33562028" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 14 Mar 2012 19:19:26 +0000 Received: from Freds-Computer.local (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2EJJJ3Z009690; Wed, 14 Mar 2012 19:19:26 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 14 Mar 2012 12:19:26 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 14 Mar 2012 12:19:26 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <11090.1331751657@marajade.sandelman.ca> Date: Wed, 14 Mar 2012 12:18:29 -0700 Message-Id: <5C23811B-D1D9-4F56-965B-EAB4594548F2@cisco.com> References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:19:27 -0000 On Mar 14, 2012, at 12:00 PM, Michael Richardson wrote: > Maybe there is an esperanto or lojban speaker that could give us a > better four letter word. (cause, you know, it will be used in the > context of my f#(#$ .*#$@# is busted!) You want four letter words? I can give you four letter words... From brian.e.carpenter@gmail.com Wed Mar 14 12:41:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541E521F85D3 for ; Wed, 14 Mar 2012 12:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 RODX+m9rMOVK for ; Wed, 14 Mar 2012 12:41:26 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9E21F85B9 for ; Wed, 14 Mar 2012 12:41:26 -0700 (PDT) Received: by eeke51 with SMTP id e51so1385900eek.31 for ; Wed, 14 Mar 2012 12:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=c5lZ8gMhkpnoKytYFAaHDwzL4/i/Xm6SP635vFCYygE=; b=r9rWpdShgFABciXOvvtmrsQa8ysgUdgsbvG9dayg/KS8aHoN9/SH6XJi95u9OC4mdb odWW2fpJ3UJC6EUR1aOs65HeD5tx76PydBDgjFTD/GnBGuNz38Q6/OZFOpspQFAPLlOr 9Ie0RtQUknjbrFgbxv8UBGHIry2nLIBSkMogdVwK9lk1weI6QNX+nuMKlV2Lru5GZOch T07VdT19lZbgDbhnqqc14NxYr4ML2xPBhyVFWPD6NwKvc3eOG9/VH0eeESrIBAqcwuOK 3OayEq79gpHMipMy/F/KbiSNBgBI5wWz3KiKvLfXNZZ5vVXTyk27ZA53Jvr18cCJ3mjz elLg== Received: by 10.14.204.70 with SMTP id g46mr564256eeo.117.1331754085538; Wed, 14 Mar 2012 12:41:25 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id q45sm8385079eem.7.2012.03.14.12.41.20 (version=SSLv3 cipher=OTHER); Wed, 14 Mar 2012 12:41:24 -0700 (PDT) Message-ID: <4F60F458.4080403@gmail.com> Date: Thu, 15 Mar 2012 08:41:12 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ashok Narayanan , =?UTF-8?B?Um9nZXIgSsO4cmdlbnNlbg==?= , Fred Baker , "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:41:27 -0000 On 2012-03-14 18:11, Cameron Byrne wrote: > On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan wrote: >> On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote: >> >> >>> That's reality, and much as I love the e2e principle I think the ordinary >>> citizen is better off behind default-deny. >>> >> I am not trying to be dense, but why? >> >> What is the negative scenario of not having a homenet firewall on? Using >> real examples from the last 5 years .... I would like to know how a cpe >> firewall protects against real threats to modern software. >> >> It seems hard to predict a priori what a "real threat" is going to be. And >> it seems unlikely that "modern software" is all that will be found in >> average homes. For example, will the Android version on the refrigerator >> display be updated? >> > > Agreed about a priori. BUT! what else do we have to go on? I am > asking for a baseline to justify why a CPE firewall is required. In > fact, i have asked for it multiple times on this thread, and all i get > back is anecdotal hand waving, not technical reasons. > > Putting the E back in IETF, let's see some data about why this > function of the system must exist. > > My cursory research says you are not going to be able to present a > convincing amount of data to support the fact that a stateful > inspection firewall should be applied in a contemporary home > environment. I believe the spirit of Homenet is moving the internet > forward without being beholden to the Morris worm and X.25 Fred and I provided factual but local evidence of background radiation of unwanted UDP packets. Actually there is a lot more systematic evidence of this too. For example, this week at the PAM conference in Vienna there's a paper "One-way traffic monitoring with iatmon" by Nevil Brownlee that gives a detailed analysis of observed unwanted traffic, both UDP and TCP SYN. See http://www.caida.org/publications/papers/2012/one_way_traffic_iatmon/ Can you assert that all low-end homenet devices will be internally protected against such traffic? Bian From paduffy@cisco.com Wed Mar 14 12:55:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E615F21F87CD for ; Wed, 14 Mar 2012 12:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] 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 aRl98opBr5O1 for ; Wed, 14 Mar 2012 12:55:52 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 39C5A21F87CA for ; Wed, 14 Mar 2012 12:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=793; q=dns/txt; s=iport; t=1331754952; x=1332964552; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MXhW4oj7LYFErBM3YZhHZWDl8oq+HSMkKXtg6SIDuPo=; b=h17SN5G4Qf3gE6ud2249NKnp45W8aykTKP3f40FFLL2/31kqg19NIGtm 2BwRFDgJa36Q6Xf7V/krXN9K3TMAm1HUdTgstrl+teU1leZAHxDtBZYHw eq1woayebUFadUgZGLJ7v4vWTqVgL3J35moYuraUtCI7LaDBPxpOjyKEJ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPP2YE+tJXG8/2dsb2JhbABDti2BB4IJAQEBBBIBAiNAARALDgQGCRYPCQMCAQIBNw4GDQEFAgEBHodom0mDPBCbZpB/BJVWhWuIVYECZoMC X-IronPort-AV: E=Sophos;i="4.73,586,1325462400"; d="scan'208";a="66268112" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 14 Mar 2012 19:55:51 +0000 Received: from [161.44.66.230] (dhcp-161-44-66-230.cisco.com [161.44.66.230]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2EJtpGk006384; Wed, 14 Mar 2012 19:55:51 GMT Message-ID: <4F60F7C7.2070309@cisco.com> Date: Wed, 14 Mar 2012 15:55:51 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Michael Richardson References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> In-Reply-To: <11090.1331751657@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:55:53 -0000 .premise would provide wiggle room for consumer, commercial, or industrial sites On 3/14/2012 3:00 PM, Michael Richardson wrote: >>>>>> "Tim" == Tim Chown writes: > >> Sorry, couldn't resist... > > Tim> Well let's hope ICANN don't cash in on .site while xmdns is > Tim> being defined... > > That was my major comment about the document. > I don't like .site. Yeah, it's generic enough to work everywhere. > But, I think it will be confusing to the public. I think that .home > would be better, but all of these are also rather english specific. > > Maybe there is an esperanto or lojban speaker that could give us a > better four letter word. (cause, you know, it will be used in the > context of my f#(#$ .*#$@# is busted!) > From jhw@apple.com Wed Mar 14 12:56:48 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FBB21F87D0 for ; Wed, 14 Mar 2012 12:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.307 X-Spam-Level: X-Spam-Status: No, score=-110.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 yM++qjoT+llt for ; Wed, 14 Mar 2012 12:56:48 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 724B621F87CA for ; Wed, 14 Mar 2012 12:56:48 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M0W00E9U3OL2LU1@mail-out.apple.com> for homenet@ietf.org; Wed, 14 Mar 2012 12:56:47 -0700 (PDT) X-AuditID: 11807137-b7c82ae000007218-43-4f60f7fe2fef Received: from ba0301a-dhcp20.apple.com (ba0301a-dhcp20.apple.com [17.193.14.148]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 6C.7E.29208.FF7F06F4; Wed, 14 Mar 2012 12:56:47 -0700 (PDT) From: james woodyatt In-reply-to: <13475.1331738214@marajade.sandelman.ca> Date: Wed, 14 Mar 2012 12:56:46 -0700 Message-id: References: <13119.1331487384@marajade.sandelman.ca> <7D6717D7-9AEE-4C69-AFF5-BD4927B5A126@mbaugher.com> <13475.1331738214@marajade.sandelman.ca> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1443) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42IRPMg3Rff/9wR/g8e3pSzeLzrE4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNnbzrEXnOCsaFzwn7WB8RB7FyMnh4SAiUTLxsMsELaYxIV7 69m6GLk4hARWMEkc+bIKrIhZQFti0twJQAkODl4BPYkpc4VAwsICqhIPrl5nBbHZBFQkvl2+ ywRicwqYShy8vp4FpJwFqGbZcgOYKcsWvmYGsXkFbCTm9i5khVi1nVli0rMtbCAJEQF9iadH frFB3CMrcWzLY5YJjHyzkFwxC+GKWUjGLmBkXsUoWJSak1hpaKaXWFCQk6qXnJ+7iREURg2F 5jsYt/+VO8QowMGoxMObWR/vL8SaWFZcmXuIUYKDWUmEN+VDgr8Qb0piZVVqUX58UWlOavEh RmkOFiVx3vSDQNUC6YklqdmpqQWpRTBZJg5OqQbGrF8XYzIa58hrfjvSmCKX3sTdpNCjfLMj piKyxGFq0e2JQem3FHmOKD474i8iK+6yckbqBOsIr5kpJq1KBUnLPi4stZmy9YeC5c1KhoTy nAtp25wvqKm47A3PNX505oVxuoe645r1Sf9blN839Ipsz2y15/kd8/FgZeHHq5zL6wtylNRd 6pRYijMSDbWYi4oTAfWYEAEfAgAA Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:56:49 -0000 On Mar 14, 2012, at 08:16 , Michael Richardson wrote: > whatever we set as the recommended default will be what is there for 99% of users, and therefore what anyone writing an application that has to live in the home is going to have to deal with. A point I have been trying to make for several years now is that we have already set a recommended default in many places for "block all incoming connections" at unmanaged Internet gateways. We probably had a chance to reverse course on this for IPv6 in the middle of the last decade, but not anymore. We now have a strategic direction we have been following for quite some time now, and we have too much invested in it to turn back. I think the credit for preserving the continuity of the IPv4/NAT experience with the transition to IPv6 should go to the IAB and the IESG. The HOMENET architecture should throw in the towel on E2E and go with RFC 6092 on by default at the border gateway. It should be silent about PCP until something can be done about its lack of explicit support for nested security domains. -- james woodyatt member of technical staff, core os networking From cb.list6@gmail.com Wed Mar 14 12:57:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3A821F87CD for ; Wed, 14 Mar 2012 12:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 DIRnoDSOTn4k for ; Wed, 14 Mar 2012 12:57:14 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B547621F87CA for ; Wed, 14 Mar 2012 12:57:14 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2288pbb.31 for ; Wed, 14 Mar 2012 12:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=cDTKJNxMyE3NUVgtq+DZbEHjpr8BEfiDYNv2D3XRYJs=; b=lcHqU7z8n7ydYkrQAhmQwFAj5UyxW9jXNH8wcv0TNMZNAWnSHnKtzY2GW5ussL8SxL nO2kAnxCuhHYH5soXseize3aEkh1B23VdMgLm0bbbC9bzZn1djrda9rz6zfXMMUDo/uK EwNCNdZeaG+fYYPyaplElgbGHZkTy/lSSbkEVeKSS+VtdrHY98AHyRYS1CjPRAJ3slG6 fD3Wz3NdsXE3vIy2W9mvjGz/V2klXDUonfvUMmSk9qyrz6G1KAPE68ZjQ/rLYcyD7lbW d34kgJXSdllRwLxEYWogLXCY6COCVymCMpc73wyVcQX75esq+pBetXq4PnfzEGy6lUJe 7THg== MIME-Version: 1.0 Received: by 10.68.129.195 with SMTP id ny3mr4486827pbb.88.1331755034383; Wed, 14 Mar 2012 12:57:14 -0700 (PDT) Received: by 10.142.163.16 with HTTP; Wed, 14 Mar 2012 12:57:14 -0700 (PDT) In-Reply-To: <4F60F458.4080403@gmail.com> References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F60F458.4080403@gmail.com> Date: Wed, 14 Mar 2012 12:57:14 -0700 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ashok Narayanan , =?ISO-8859-1?Q?Roger_J=F8rgensen?= , Fred Baker , "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:57:15 -0000 On Wed, Mar 14, 2012 at 12:41 PM, Brian E Carpenter wrote: > On 2012-03-14 18:11, Cameron Byrne wrote: >> On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan wrot= e: >>> On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote: >>> >>> >>>> That's reality, and much as I love the e2e principle I think the ordin= ary >>>> citizen is better off behind default-deny. >>>> >>> I am not trying to be dense, but why? >>> >>> What is the negative scenario of not having a homenet firewall on? Usin= g >>> real examples from the last 5 years .... I would like to know how a cpe >>> firewall protects against real threats to modern software. >>> >>> It seems hard to predict a priori what a "real threat" is going to be. = And >>> it seems unlikely that "modern software" is all that will be found in >>> average homes. For example, will the Android version on the refrigerato= r >>> display be updated? >>> >> >> Agreed about a priori. =A0BUT! what else do we have to go on? =A0I am >> asking for a baseline to justify why a CPE firewall is required. =A0In >> fact, i have asked for it multiple times on this thread, and all i get >> back is anecdotal hand waving, not technical reasons. >> >> Putting the E back in IETF, let's see some data about why this >> function =A0of the system must exist. >> >> My cursory research says you are not going to be able to present a >> convincing amount of data to support the fact that a stateful >> inspection firewall should be applied in a contemporary home >> environment. =A0I believe the spirit of Homenet is moving the internet >> forward without being beholden to the Morris worm and X.25 > > Fred and I provided factual but local evidence of background radiation > of unwanted UDP packets. Actually there is a lot more systematic evidence > of this too. For example, this week at the PAM conference in Vienna > there's a paper "One-way traffic monitoring with iatmon" by Nevil Brownle= e > that gives a detailed analysis of observed unwanted traffic, both UDP and= TCP SYN. > See http://www.caida.org/publications/papers/2012/one_way_traffic_iatmon/ > > Can you assert that all low-end homenet devices will be internally > protected against such traffic? > "If a tree falls in a forest and no one is around to hear it, does it make a sound?" I can assert that if the low-end homenet device is not listening on TCP port 80, the TCP SYN to port 80 will cause no new harm, firewall or not. Now, if there is 80mb/s of TCP SYN coming in, maybe it is a DOS .... and the link is saturated, firewall or not. Alternatively, if there is 1 mb/s of TCP SYN coming in, and the firewall is doing SPI, the firewall will likely choke on session per second creation.... Thus the DOS is cheaper and easier to achieve. In my operational experience, session overloading and misconfiguration of firewalls has created more problems than hacks prevented by firewalls. If you are running a a 10 year old version of IIS, and you are hosting an internet web page, and you have port 80 open, that CPE firewall is not going to help at all. If the low level device should not be communicating with the internet, then a link-local or ULA address can be one layer of segmentation. Fred made a good assesment that the firewall is just protecting the LAN bandwidth from junk. I can buy that. But assuming LAN > WAN in capacity, and usually by an order of magnitude, it is still not justified IMHO. My main concerns is stateful inspection of every session, it is a terrible waste to import this legacy thinking into homenet. And, it effectively makes IPv6 the same experience as NAT44... everything over port 80. CB From therbst@silverspringnet.com Wed Mar 14 13:00:37 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D08C21F87EE for ; Wed, 14 Mar 2012 13:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, GB_I_LETTER=-2] 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 DRtcrTTyxYGr for ; Wed, 14 Mar 2012 13:00:37 -0700 (PDT) Received: from it-ipdr-01.silverspringnet.com (it-ipdr-01.silverspringnet.com [74.121.22.27]) by ietfa.amsl.com (Postfix) with ESMTP id ECA5D21F87ED for ; Wed, 14 Mar 2012 13:00:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJ74YE8KOQxz/2dsb2JhbABDtzSCCQEBAQQBAQE3NAsSAQgNAQQGHjcLFw4BAQQBDQWIFbpxBJB/BIhXkwyKG4MG X-IronPort-AV: E=Sophos;i="4.73,586,1325491200"; d="scan'208";a="1263913" Received: from unknown (HELO SFO-EXCA-02.silverspringnet.com) ([10.57.12.115]) by it-ipdr-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 14 Mar 2012 13:00:01 -0700 Received: from IT-EXCA-01.silverspringnet.com (10.200.1.60) by SFO-EXCA-02.silverspringnet.com (10.57.12.101) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Mar 2012 13:00:01 -0700 Received: from IT-RESTORE-01.silverspringnet.com ([::1]) by IT-EXCA-01.silverspringnet.com ([::1]) with mapi; Wed, 14 Mar 2012 13:00:01 -0700 From: Thomas Herbst To: Paul Duffy , Michael Richardson Date: Wed, 14 Mar 2012 13:00:00 -0700 Thread-Topic: [homenet] Name resolution in the homenet architecture document Thread-Index: Ac0CHQlT5JEVBId2SjGM0egKSYJGxg== Message-ID: In-Reply-To: <4F60F7C7.2070309@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:00:37 -0000 Not to be pedantic, but would that be .premises? Noun:A house or building, together with its land and outbuildings, occupied by a business or considered in an official context. Rather than=20 Noun:A previous statement or proposition from which another is inferred or follows as a conclusion. tom On 3/14/12 12:55 PM, "Paul Duffy" wrote: >.premise would provide wiggle room for consumer, commercial, or >industrial sites > > >On 3/14/2012 3:00 PM, Michael Richardson wrote: >>>>>>> "Tim" =3D=3D Tim Chown writes: >> >> Sorry, couldn't resist... >> >> Tim> Well let's hope ICANN don't cash in on .site while xmdns is >> Tim> being defined... >> >> That was my major comment about the document. >> I don't like .site. Yeah, it's generic enough to work everywhere. >> But, I think it will be confusing to the public. I think that .home >> would be better, but all of these are also rather english specific. >> >> Maybe there is an esperanto or lojban speaker that could give us a >> better four letter word. (cause, you know, it will be used in the >> context of my f#(#$ .*#$@# is busted!) >> > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From cb.list6@gmail.com Wed Mar 14 13:07:23 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A11C21F8804 for ; Wed, 14 Mar 2012 13:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 nS35YkWGFWlj for ; Wed, 14 Mar 2012 13:07:22 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9B93A21F8802 for ; Wed, 14 Mar 2012 13:07:22 -0700 (PDT) Received: by yhgm50 with SMTP id m50so3360188yhg.27 for ; Wed, 14 Mar 2012 13:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=y93KaCuTcNGk1tspCARkLRKQEZhYEEDkXM/uHo0NKmo=; b=B4egbtCwPkscgiJYyefOEunlJ2bpn32miEgUQbeXMu5oNxDid3i8EaoaJBjq1BJjBm jVWni3/qGpHJx1/bMFNygpCBpnEHUBr2+JfTjRJg0UFbk1tQU0iphA7YxGm0609lH0wW C8bPqM2FEby/T71ODKYmuPpEGLICgWZSEphJOBenOX2CzDbHot6T/Fx7TsMK2AunOzjY SPqmgoJjeNYp7VXF3Ewt8wX2+n7rzm6TfB95VsUYedRf+gBLSmJNtKQ/4kRh9z3MQSLX OUkM2htBAI8022ljcVzBo/QzXAJFKGCOlZx7Xe1Fw332KwrZF1UpUvTGmD2fsReomhpH +28g== MIME-Version: 1.0 Received: by 10.68.217.97 with SMTP id ox1mr55987pbc.81.1331755641924; Wed, 14 Mar 2012 13:07:21 -0700 (PDT) Received: by 10.142.163.16 with HTTP; Wed, 14 Mar 2012 13:07:21 -0700 (PDT) In-Reply-To: References: <13119.1331487384@marajade.sandelman.ca> <7D6717D7-9AEE-4C69-AFF5-BD4927B5A126@mbaugher.com> <13475.1331738214@marajade.sandelman.ca> Date: Wed, 14 Mar 2012 13:07:21 -0700 Message-ID: From: Cameron Byrne To: james woodyatt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:07:23 -0000 On Wed, Mar 14, 2012 at 12:56 PM, james woodyatt wrote: > On Mar 14, 2012, at 08:16 , Michael Richardson wrote: > >> whatever we set as the recommended default will be what is there for 99%= of users, and therefore what anyone writing an application that has to liv= e in the home is going to have to deal with. > > A point I have been trying to make for several years now is that we have = already set a recommended default in many places for "block all incoming co= nnections" at unmanaged Internet gateways. =A0We probably had a chance to r= everse course on this for IPv6 in the middle of the last decade, but not an= ymore. =A0We now have a strategic direction we have been following for quit= e some time now, and we have too much invested in it to turn back. > > I think the credit for preserving the continuity of the IPv4/NAT experien= ce with the transition to IPv6 should go to the IAB and the IESG. =A0The HO= MENET architecture should throw in the towel on E2E and go with RFC 6092 on= by default at the border gateway. =A0It should be silent about PCP until s= omething can be done about its lack of explicit support for nested security= domains. > > I disagree with your pessimism, but not with your summary of reality. If that really is the case, then i am not sure why HOMENET exist. So far, all i have gleaned from this group is debates about problems i consider pretty far fetched and irrelevant. Turing routing protocols on cheap routers is not interesting to me.... in fact, i am so boring, and admin a network all day long, that i cant imagine why anyone in their right mind would want more than one subnet in their home.... but that is just me (and 99% of all home users). I have the same apathy towards multihoming. Making IPv6 restore e2e, or the internet model, is a worthy goal and i am glad to help... But, if HOMENET is throwing in the towel, i can lurk somewhere else and you folks can keep debating about OSPF vs RIP and thinking that SPI makes something secure. CB > -- > james woodyatt > member of technical staff, core os networking > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From fred@cisco.com Wed Mar 14 13:13:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F70D21E8034 for ; Wed, 14 Mar 2012 13:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.221 X-Spam-Level: X-Spam-Status: No, score=-109.221 tagged_above=-999 required=5 tests=[AWL=1.378, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 ukUfOw+1u8dH for ; Wed, 14 Mar 2012 13:13:04 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EF28F21E8021 for ; Wed, 14 Mar 2012 13:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2146; q=dns/txt; s=iport; t=1331755983; x=1332965583; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=cIhyqUiTLitIsYwPCTCCWxtgkk+lQE6OGSVryZ7YtBI=; b=BfL6zRRN/mtOtMx8b5GUcT3ZtdDrKr8VbyMyIoFh6pxyuXL09V6BGD1r zvvqMAQzXkmHU2M34PO6voBSsPlrrKpnWXRJ+JgKQmUKaRMnZeeJ7eDdN PfBiBjGbHV8pJsCc7GHPYLgSaxMVh5796Jk5iOIZMRlMKSVoj/nHItmMp M=; X-IronPort-AV: E=Sophos;i="4.73,586,1325462400"; d="scan'208";a="33033200" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 14 Mar 2012 20:13:03 +0000 Received: from Freds-Computer.local (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2EKD3BP001354; Wed, 14 Mar 2012 20:13:03 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 14 Mar 2012 13:13:03 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 14 Mar 2012 13:13:03 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 14 Mar 2012 13:12:34 -0700 Message-Id: References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: Ashok Narayanan , =?iso-8859-1?Q?Roger_J=F8rgensen?= , "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:13:04 -0000 On Mar 13, 2012, at 10:11 PM, Cameron Byrne wrote: > My cursory research says you are not going to be able to present a = convincing amount of data to support the fact that a stateful > inspection firewall should be applied in a contemporary home = environment.=20 I don't recall anyone saying that a "stateful inspection" firewall was = specifically called for. I think we argued that there is a market = expectation that a firewall is at least available, and that however the = firewall is implemented, it should prevent simple attacks from "outside" = the network (I will argue "network layer attacks" as opposed to combing = through bits in layers above). As we get into the specifics of kinds of = firewalls, I think we're treading even more heavily on people's = religion. As to "kinds of firewalls", I have a posted draft (which I think I = mentioned), which might be discussed in opsawg and might be discussed in = the Security Area meeting. I haven't heard a decision on that. I would = suggest we defer to that discussion. However, as far as *this* draft = goes, I think that it is fair to say that - a CPE Router MAY include a firewall function. - IF such a function is implemented, it MUST be possible to disable it, reducing the CPE to a simple router. (my rule on the use of "MUST": I use the term when failing to do so breaks something, and I try to say what breaks. In this case, a CPE Router that has a firewall that can't be turned off=20 cannot be used as an interior router in the home network) - IF it is a "deny all" firewall, it SHOULD have a means of providing access rules for services inside the home, such as allowing SMTP to an SMTP server or ISP access to a set-top box. PCP or other protocols like it MAY be used to achieve that. - IF it is a role-based firewall, it SHOULD have a means of configuring and using roles. - IF it is a stateful inspection, reputation-based, or anomaly=20 detection firewall, it SHOULD have a way to maintain the indicated tables such as periodic download of signed files from a trusted site. From kerlyn2001@gmail.com Wed Mar 14 13:22:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82C421F881F for ; Wed, 14 Mar 2012 13:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.859 X-Spam-Level: X-Spam-Status: No, score=-103.859 tagged_above=-999 required=5 tests=[AWL=1.118, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 bavjq490mNqn for ; Wed, 14 Mar 2012 13:22:11 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF4EB21F87D0 for ; Wed, 14 Mar 2012 13:22:10 -0700 (PDT) Received: by lbol12 with SMTP id l12so1218745lbo.31 for ; Wed, 14 Mar 2012 13:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rucAmM0MrBIHcHMH+pZkClTuVM1+tfyfSG74Fz57ypY=; b=ks3cpJtNQ/p0wyBhqVOElSsvsZIxi6dEGUBL6aXtdBb1OqtCOi4t7cxM96igG2409I y+EkRxxe/ecEdZQCMz7zoUh81m99XWiDvkUhwEQHuqLvAHuisjJqw6drf38BkBE6lFwy cGqSC6C1W78vcdOfdkKUymioTuLzi/76eJbVtjro/xf38eM/y0TZLpeiCzymbSqwp/Ys NoFYbGsZS3qUPpWbYbzi+V9u+I/fdOaIHAjHEgJB0RCuDMN/UmUTmkH7NpILjZlQzwYK pMFneQN8WSemvITDU8JQo6eBpDosGJPZxhx2HVvShsqVwXgLysKVN9BxFflGI53wqom4 OPGA== MIME-Version: 1.0 Received: by 10.112.102.68 with SMTP id fm4mr1541778lbb.7.1331756529713; Wed, 14 Mar 2012 13:22:09 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.77.179 with HTTP; Wed, 14 Mar 2012 13:22:09 -0700 (PDT) In-Reply-To: <11090.1331751657@marajade.sandelman.ca> References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> Date: Wed, 14 Mar 2012 16:22:09 -0400 X-Google-Sender-Auth: lCzbKDSBlitc9MLjpp392v22Yss Message-ID: From: Kerry Lynn To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:22:11 -0000 On Wed, Mar 14, 2012 at 3:00 PM, Michael Richardson wrot= e: > >>>>>> "Tim" =3D=3D Tim Chown writes: > =A0 =A0>> Sorry, couldn't resist... > > =A0 =A0Tim> Well let's hope ICANN don't cash in on .site while xmdns is > =A0 =A0Tim> being defined... > > That was my major comment about the document. > I don't like .site. =A0Yeah, it's generic enough to work everywhere. > But, I think it will be confusing to the public. =A0I think that .home > would be better, but all of these are also rather english specific. > Is .local confusing to the public? I'm not sure they ever see it (unless they're running Wireshark). What they *do* see is a list of instance names for a given service (as, for example, when adding a printer from a list). Just like .local, .site defines a behavior for an xmDNS aware resolver. That is to multicast the DNS query to port 5353 on FF05::FB. .site SHOULD NOT be used to name a local unicast DNS TLD. If DNS is deployed in your homenet, it seems the cleanest thing is to get yourself a domain or have your ISP delegate you a zone. If some random name is used for your TLD, then perhaps the term "FQDN" should not be applied to a service in that context. -K- > Maybe there is an esperanto or lojban speaker that could give us a > better four letter word. =A0(cause, you know, it will be used in the > context of my f#(#$ .*#$@# is busted!) > > -- > ] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 = =A0 =A0 | =A0firewalls =A0[ > ] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|ne= t architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device d= river[ > =A0 Kyoto Plus: watch the video > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition. > > > > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From paduffy@cisco.com Wed Mar 14 13:28:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C50B21F8834 for ; Wed, 14 Mar 2012 13:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.799 X-Spam-Level: X-Spam-Status: No, score=-11.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8] 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 j1F9nz7dzOKg for ; Wed, 14 Mar 2012 13:28:04 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F0FA121F882E for ; Wed, 14 Mar 2012 13:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=1488; q=dns/txt; s=iport; t=1331756884; x=1332966484; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FHYlvi/B6d48NBkkAY/20AN6dm8TcDmXFVclPiOXtdk=; b=mbsFxpwgHpi7yp3+c5Hl7SJqi3ZT5V+ajx4MM+2R4ZoZQT0bHMhfohvi Yg+YA3urBoi7TeqK92nKTYc3kF8x2ta40/WM0bL3KbdIQ5g+HfMFyEBgm OG8kkHkerEF7JSjibmMmDgN/vTjZoB0GQNN5I9IY5CKyro9vR7XlhffzJ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPv+YE+rRDoJ/2dsb2JhbABDtjaBB4IJAQEBBAEBAQ8BAiM2CgEQCw4EBgkWDwkDAgECARUiDgYNAQUCAQEeh2cBC6BXgzwQk3kEkH8ElVaFa4hVgQJmgwI X-IronPort-AV: E=Sophos;i="4.73,586,1325462400"; d="scan'208";a="33571709" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 14 Mar 2012 20:28:04 +0000 Received: from [161.44.66.230] (dhcp-161-44-66-230.cisco.com [161.44.66.230]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2EKS3sN024093; Wed, 14 Mar 2012 20:28:03 GMT Message-ID: <4F60FF53.4010008@cisco.com> Date: Wed, 14 Mar 2012 16:28:03 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Thomas Herbst References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" , Michael Richardson Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:28:04 -0000 +1 The latin ".locus" may also work. ;) On 3/14/2012 4:00 PM, Thomas Herbst wrote: > Not to be pedantic, but would that be .premises? > > Noun:A house or building, together with its land and outbuildings, > occupied by a business or considered in an official context. > > > Rather than > > Noun:A previous statement or proposition from which another is inferred or > follows as a conclusion. > > > tom > > On 3/14/12 12:55 PM, "Paul Duffy" wrote: > >> .premise would provide wiggle room for consumer, commercial, or >> industrial sites >> >> >> On 3/14/2012 3:00 PM, Michael Richardson wrote: >>>>>>>> "Tim" == Tim Chown writes: >>> >> Sorry, couldn't resist... >>> >>> Tim> Well let's hope ICANN don't cash in on .site while xmdns is >>> Tim> being defined... >>> >>> That was my major comment about the document. >>> I don't like .site. Yeah, it's generic enough to work everywhere. >>> But, I think it will be confusing to the public. I think that .home >>> would be better, but all of these are also rather english specific. >>> >>> Maybe there is an esperanto or lojban speaker that could give us a >>> better four letter word. (cause, you know, it will be used in the >>> context of my f#(#$ .*#$@# is busted!) >>> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > From sm@resistor.net Wed Mar 14 14:24:24 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A365921F8871 for ; Wed, 14 Mar 2012 14:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.635 X-Spam-Level: X-Spam-Status: No, score=-102.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 wHfpcpPVseKo for ; Wed, 14 Mar 2012 14:24:23 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D04421F8870 for ; Wed, 14 Mar 2012 14:24:23 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2ELOE9O028283; Wed, 14 Mar 2012 14:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331760259; i=@resistor.net; bh=rz2nAyxAYmKN0XqBkRdmtE+xreojithC9b67SlCeLo4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wpdZGqX1E8Gp6KU7IpDXakHEHMxqq6A0MELNFfFfqrOm+4h7MG25sG+DspclIVWRh eRVPO5S2xEb+2qwJ9Wi8z811QH/ndufCaoh2HP7dVtB6Qvtj2iVRCgOxU94iAUec2K MfssElXay6NLFP+4YV5ayEOF6x+9BCpuUCGw3aJk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1331760259; i=@resistor.net; bh=rz2nAyxAYmKN0XqBkRdmtE+xreojithC9b67SlCeLo4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JryS0K/cJjGu5GR488gLF90qZUX8Ag/qbmsIS2HbMuUIaPiMc5kAChTyn9hAH/LIe nj/trziyoPDA0VIn00Wfu8rhc9HVkYtx2y7/j87tmvEqar2MVNK4IE5WAYAQ+QSbSr r1hkxPng/VkotFaorC+1NqgnHebgtwlZfTVIo7kU= Message-Id: <6.2.5.6.2.20120314140342.09b49be8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Mar 2012 14:11:46 -0700 To: Dave Taht From: SM In-Reply-To: References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "homenet@ietf.org" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 21:24:24 -0000 Hi Dave, At 12:18 14-03-2012, Dave Taht wrote: >What I have been using has been '.lan'. I've seen it used elsewhere, >too, on private nets, but I have no idea how common it is. See www.icann.org/en/groups/ssac/documents/sac-045-en.pdf Regards, -sm From dave.taht@gmail.com Wed Mar 14 14:36:25 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A9611E8087 for ; Wed, 14 Mar 2012 14:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 BLaEMg6irDxd for ; Wed, 14 Mar 2012 14:36:24 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A278E11E8086 for ; Wed, 14 Mar 2012 14:36:24 -0700 (PDT) Received: by werb10 with SMTP id b10so2682165wer.31 for ; Wed, 14 Mar 2012 14:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5Vx9koyj+SAIbb3yV+yFEY5JJczrMxn+4Hu6Z4Gm2+0=; b=ThZh1izomPottoz9v1fN5IW//VDwf7TmF+cB2GQvlivIT0lKw4avmVaoL2bOaCEJQC YFveJhVBp6Lshcw44B8HV64D0rsUJkLMuli1e5tpnSt2WizXtD1PNECybZvc4LnmNAjy Jtt/yyTpX9TIKVI3fQIRVkhOmdmxukVBqSaLs3Q14rq7tsbhYaWdJ5QCyiZPt7mNgIk/ 00X8Npf0j7yx3C2XdfHfvNO7Dwr1q7xpnz0wlX79qJsyfW0DojYWRx4JKHloAWq3Xp3U rwe1IWVao5CRMywvsY8yw6ta3G7s0moFHe7HsKL9VD56mXT3sIxGlaAZsSkTShmn96+w hSYw== MIME-Version: 1.0 Received: by 10.216.202.99 with SMTP id c77mr3008676weo.5.1331760972683; Wed, 14 Mar 2012 14:36:12 -0700 (PDT) Received: by 10.223.151.8 with HTTP; Wed, 14 Mar 2012 14:36:12 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20120314140342.09b49be8@resistor.net> References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> <6.2.5.6.2.20120314140342.09b49be8@resistor.net> Date: Wed, 14 Mar 2012 14:36:12 -0700 Message-ID: From: Dave Taht To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 21:36:25 -0000 On Wed, Mar 14, 2012 at 2:11 PM, SM wrote: > Hi Dave, > > At 12:18 14-03-2012, Dave Taht wrote: >> >> What I have been using has been '.lan'. I've seen it used elsewhere, >> too, on private nets, but I have no idea how common it is. > > > See www.icann.org/en/groups/ssac/documents/sac-045-en.pdf That, in it's own weird way, is confirmation that .lan is widely used as an internal dns address... :) For reference, this is how to configure bind9 to not leak a private .lan or .whatever to the roots. https://github.com/dtaht/ceropackages/blob/master/net/bind-latest/files/chr= oot/named/etc/bind/localzones/us.zones https://github.com/dtaht/ceropackages/blob/master/net/bind-latest/files/chr= oot/named/etc/bind/master/lan.internal > > Regards, > -sm --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net From brian.e.carpenter@gmail.com Wed Mar 14 15:31:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A6711E8079 for ; Wed, 14 Mar 2012 15:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.491 X-Spam-Level: X-Spam-Status: No, score=-103.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 KTmzOEz-Ht85 for ; Wed, 14 Mar 2012 15:31:42 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFF111E8075 for ; Wed, 14 Mar 2012 15:31:42 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1432566eaa.31 for ; Wed, 14 Mar 2012 15:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=xPKOOtyxl3yg+K5HdwMThP8jTzh8K86VLdRB0HvBwYE=; b=APYWeyW40SVacXidezFNEhXGjiVklclMEwfBrGSdC5nn9JnuD2VvgHIP1Msfrrceak I9DxF1Xh3G43HsfeUmYBEa8SiEUXu8y54irD3oyjp3dLy/tHFu2N8LqfufoTaILiL0dW itZhCZ8zg+vB54ZK+X/N1Tf8kDxIAuarZs8qjZU0ENUvFdjhj4O0bApX9f6eS9QKbtJt Xt0uybBXBAOv20iSNjBEWJj7PBt3boxQ0wil/gJKPuK3ugtdx1QwclF0IXV/Qm8lIAKh mxwmQ5cIW1w4S/wRoAA8CuFvaQwkAzG3QYCKZCxopf2T9ozLuVdOZQHJX2YVFNevdDJ6 mhpQ== Received: by 10.14.28.132 with SMTP id g4mr15410eea.96.1331764301280; Wed, 14 Mar 2012 15:31:41 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id u9sm18034720eem.11.2012.03.14.15.31.38 (version=SSLv3 cipher=OTHER); Wed, 14 Mar 2012 15:31:40 -0700 (PDT) Message-ID: <4F611C40.4090805@gmail.com> Date: Thu, 15 Mar 2012 11:31:28 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Taht References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> <6.2.5.6.2.20120314140342.09b49be8@resistor.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 22:31:43 -0000 On 2012-03-15 10:36, Dave Taht wrote: ... > For reference, this is how to configure bind9 to not leak a private > .lan or .whatever to the roots. .lan isn't a very good choice IMHO, since it does not imply multiple segments and routing. .whatever would be a good choice in so many ways :-) If we want something fairly neutral which isn't Anglocentric, how about .ici ("here" in French)? Brian From gettysjim@gmail.com Wed Mar 14 15:43:33 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777BD11E8088 for ; Wed, 14 Mar 2012 15:43:33 -0700 (PDT) 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 lQyQ2oy24IUa for ; Wed, 14 Mar 2012 15:43:32 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2744C11E8075 for ; Wed, 14 Mar 2012 15:43:31 -0700 (PDT) Received: by lagj5 with SMTP id j5so2249581lag.31 for ; Wed, 14 Mar 2012 15:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:from:date:message-id:subject:to :cc:content-type; bh=OO7+MaaxFvIcftGMdDP6pMfa6gF6QhSWhmojiUtFrmU=; b=f0bXOXDS4uNIYNdrp+Spka8KUHQMQnrQeV09dSuAqoE2I3n7M/mPFvDDa0H60kGVaX 5WWkjn5I9zK2RQ0MKasqL0WIP+TPYs84OarL7ZlysHk7gLC40FVzw1Yxmr/DZYQGb7oN y8rMj+x9xDZWrUl0kiJUtUUsRqLKnYj+8AMLeHJFVjJinMyeYSk/NxbNstCwTNyItyj+ uluB2rjrdxsru71x6FGflZq+GLnu8wNlTqaHnXbjJ0p7si9Hdn8LggNdvoL3/JEH3ftl yGh8MnNtKesjo2jBkaB2UOJHa598P2l6pBtfzJmokwjqehggMbVMx2UD/GIDujn4cDyW vdiQ== Received: by 10.112.23.135 with SMTP id m7mr1645063lbf.46.1331765011025; Wed, 14 Mar 2012 15:43:31 -0700 (PDT) References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> <6.2.5.6.2.20120314140342.09b49be8@resistor.net> <4F611C40.4090805@gmail.com> In-Reply-To: <4F611C40.4090805@gmail.com> Mime-Version: 1.0 (1.0) From: Jim Gettys Date: Wed, 14 Mar 2012 18:43:27 -0400 Message-ID: <-429658493480296061@unknownmsgid> To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: "homenet@ietf.org" , Dave Taht Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 22:43:33 -0000 On Mar 14, 2012, at 6:31 PM, Brian E Carpenter wrote: > On 2012-03-15 10:36, Dave Taht wrote: > ... >> For reference, this is how to configure bind9 to not leak a private >> .lan or .whatever to the roots. > > .lan isn't a very good choice IMHO, since it does not imply multiple > segments and routing. It doesn't have that binding in my mind. We could try .han if you like: home area network.... Jim > > .whatever would be a good choice in so many ways :-) > > If we want something fairly neutral which isn't Anglocentric, > how about .ici ("here" in French)? > > Brian > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Wed Mar 14 15:48:24 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D195B11E8081 for ; Wed, 14 Mar 2012 15:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 HWXDsbx5IFMm for ; Wed, 14 Mar 2012 15:48:24 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 097D511E8075 for ; Wed, 14 Mar 2012 15:48:23 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2EMmHkA029563; Wed, 14 Mar 2012 22:48:17 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2EMmHkA029563 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1331765297; bh=dSyMQbw3B5oXIgKMAwLqAcI+yf0=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=MzfTTMs7P/6R1eaYUkc2EbsXizmv2c7HQc1C7Q31EQiJMrXdRx2fvNL1tYVkMEyNo tk3g4c8wK45alVrQokRrzjKGBiLJRtoKd8A0rcv1JDQgRE48J757YknJ6x8V4TlEMj YF8PY3VWLInkh0FU2WrPWyQCA/6K9ji/pmERN0uU= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id o2DMmH0543755816AC ret-id none; Wed, 14 Mar 2012 22:48:17 +0000 Received: from [192.168.1.104] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2EMmBTY002077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Mar 2012 22:48:12 GMT References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> <6.2.5.6.2.20120314140342.09b49be8@resistor.net> <4F611C40.4090805@gmail.com> In-Reply-To: <4F611C40.4090805@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-ID: X-Mailer: iPad Mail (9A405) From: Tim Chown Date: Wed, 14 Mar 2012 22:48:01 +0000 To: Brian E Carpenter X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2DMmH054375581600; tid=o2DMmH0543755816AC; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2EMmHkA029563 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "homenet@ietf.org" , Dave Taht Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 22:48:24 -0000 On 14 Mar 2012, at 22:31, Brian E Carpenter wr= ote: > On 2012-03-15 10:36, Dave Taht wrote: > ... >> For reference, this is how to configure bind9 to not leak a private >> .lan or .whatever to the roots. >=20 > .lan isn't a very good choice IMHO, since it does not imply multiple > segments and routing. We should really make this work transparently for the user, so the choice is= not important. They should grasp that devices in their homenet must have u= nique names within that network, but not be exposed to the .lan, .site, .hom= e or .dave domain used wherever possible. Tim= From brian.e.carpenter@gmail.com Wed Mar 14 15:55:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41F821F871C for ; Wed, 14 Mar 2012 15:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.492 X-Spam-Level: X-Spam-Status: No, score=-103.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 7HlwqScqB3RW for ; Wed, 14 Mar 2012 15:55:52 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB70121F8712 for ; Wed, 14 Mar 2012 15:55:49 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1435549eaa.31 for ; Wed, 14 Mar 2012 15:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kiWIVS78TCuCaeRTkV7sAPyVuXlHyM0xxuPju0KiMZQ=; b=QPsksaTXLr1H62bD5gszSBU/C9F4+flm7P/YEGMZNiCTku+1zsrqdcQnZX6vFvXZ85 HEQOVhkrCfA/zRnjhMEVrONpYCwjF0LB2m4fiEIf0I+7Hz+cBXXBGg4VGTvKoIsG+K3b 1V0RL8J6WdzguYmqS84YPMlDmlUvx/lNDxRUW1Q1onl7eD+Ko+srCkbKNnxdhZKfY7QT 0YJ45vLuKSj5mRF0b6sBXRjlgtsHzWCAgbLP8bTaxehHSWBtN8/S5ptZrWSy41+OQhuO hezKTjon+HYxDuGAfOXIjcyskw76MNUCZGwMTdEHa5Tg8dxVg7XlWWUZ0AmROYSFB+kh WBZw== Received: by 10.14.94.200 with SMTP id n48mr649415eef.48.1331765748960; Wed, 14 Mar 2012 15:55:48 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id v15sm253640eem.1.2012.03.14.15.55.45 (version=SSLv3 cipher=OTHER); Wed, 14 Mar 2012 15:55:48 -0700 (PDT) Message-ID: <4F6121E9.7060301@gmail.com> Date: Thu, 15 Mar 2012 11:55:37 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Chown References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> <6.2.5.6.2.20120314140342.09b49be8@resistor.net> <4F611C40.4090805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" , Dave Taht Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 22:55:52 -0000 On 2012-03-15 11:48, Tim Chown wrote: > On 14 Mar 2012, at 22:31, Brian E Carpenter wrote: > >> On 2012-03-15 10:36, Dave Taht wrote: >> ... >>> For reference, this is how to configure bind9 to not leak a private >>> .lan or .whatever to the roots. >> .lan isn't a very good choice IMHO, since it does not imply multiple >> segments and routing. > > We should really make this work transparently for the user, so the choice is not important. They should grasp that devices in their homenet must have unique names within that network, but not be exposed to the .lan, .site, .home or .dave domain used wherever possible. I fully agree; just let's choose something that is neutral and simple when users do happen to see it. Brian From kerlyn2001@gmail.com Wed Mar 14 19:34:24 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1060821F8661 for ; Wed, 14 Mar 2012 19:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.945 X-Spam-Level: X-Spam-Status: No, score=-102.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Q6kGRg6o1goj for ; Wed, 14 Mar 2012 19:34:23 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id B37C221F865F for ; Wed, 14 Mar 2012 19:34:22 -0700 (PDT) Received: by lbol12 with SMTP id l12so1363936lbo.31 for ; Wed, 14 Mar 2012 19:34:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OcJmE2mWngJ870l1FzNOFIhi68FmWzwBd7t6y8giMW4=; b=Al1vkivqhhZ8bbJKcAv81+OtJEQy7Kkn8LkZZeHJfh+xvRwVNvkv9Pwao5qLsVwxAX P6R+zFxYDCW0OeAtqplWXBAmBztoiVQbR0viS+HtF12P+1SDx+kpAAoi+NGDVrz8To4/ F4Bu+hcJvTkMmB0UVObriRGDNgq/0XHD/FrorYMdP+Br7tcEpoC3RVO7p4gfqjxCxOdn yClc6N1uiU8fEKgIEoHKewipobqlovpJZO7cg21DXWgbFzC5Ezp3pcIkPIkmxqYC5r2B eQQOet0SNQhVN9n6qKrt+lT/yVThLitTAi8lXdjtRsSTnbSwpelZTrAeb/1uN+V6n/gR l7LA== MIME-Version: 1.0 Received: by 10.112.40.72 with SMTP id v8mr1866318lbk.49.1331778861274; Wed, 14 Mar 2012 19:34:21 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.77.179 with HTTP; Wed, 14 Mar 2012 19:34:21 -0700 (PDT) In-Reply-To: References: <56D070B2-8F60-4222-90FA-ADA8DAA6C003@cisco.com> <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> <6.2.5.6.2.20120314140342.09b49be8@resistor.net> Date: Wed, 14 Mar 2012 22:34:21 -0400 X-Google-Sender-Auth: J8fwCs9oGLTxmKmu29lFfcEMbhQ Message-ID: From: Kerry Lynn To: Dave Taht Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SM , "homenet@ietf.org" Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 02:34:24 -0000 On Wed, Mar 14, 2012 at 5:36 PM, Dave Taht wrote: > On Wed, Mar 14, 2012 at 2:11 PM, SM wrote: >> Hi Dave, >> >> At 12:18 14-03-2012, Dave Taht wrote: >>> >>> What I have been using has been '.lan'. I've seen it used elsewhere, >>> too, on private nets, but I have no idea how common it is. >> >> >> See www.icann.org/en/groups/ssac/documents/sac-045-en.pdf > > That, in it's own weird way, is confirmation that .lan is widely used > as an internal dns address... :) > > For reference, this is how to configure bind9 to not leak a private > .lan or .whatever to the roots. > > https://github.com/dtaht/ceropackages/blob/master/net/bind-latest/files/c= hroot/named/etc/bind/localzones/us.zones > > https://github.com/dtaht/ceropackages/blob/master/net/bind-latest/files/c= hroot/named/etc/bind/master/lan.internal Dave, This is interesting work. Do you see it expanding to cover the list of domains described in RFC 6303 and registered by IANA: http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns= -zones.xml Granted, ISPs probably have sacrificial servers deployed but by also filtering at the CER the bad packets, as Fred said, have to thread two needles. -K- >> >> Regards, >> -sm > > > > -- > Dave T=E4ht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://www.bufferbloat.net > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From each@isc.org Wed Mar 14 19:58:23 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F6E11E808C for ; Wed, 14 Mar 2012 19:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 eblxS-AQK+qg for ; Wed, 14 Mar 2012 19:58:23 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 23F3E11E8087 for ; Wed, 14 Mar 2012 19:58:23 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id B45475F98AF; Thu, 15 Mar 2012 02:58:05 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id BA01A216C33; Thu, 15 Mar 2012 02:58:03 +0000 (UTC) Date: Thu, 15 Mar 2012 02:58:03 +0000 From: Evan Hunt To: Kerry Lynn Message-ID: <20120315025803.GA32658@isc.org> References: <5B578E7D-ADC2-4A73-B3C7-625294F27ABF@nominet.org.uk> <95CFDAAE-D726-4AD0-A7BA-51B8D94DF276@ecs.soton.ac.uk> <11090.1331751657@marajade.sandelman.ca> <6.2.5.6.2.20120314140342.09b49be8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: SM , "homenet@ietf.org" , Dave Taht Subject: Re: [homenet] Name resolution in the homenet architecture document X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 02:58:23 -0000 > This is interesting work. Do you see it expanding to cover the list of > domains described in RFC 6303 and registered by IANA: BIND 9 covers those by default now. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc. From v6ops@globis.net Thu Mar 15 01:56:48 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0C621F8667 for ; Thu, 15 Mar 2012 01:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 PnAtrWWi5dez for ; Thu, 15 Mar 2012 01:56:47 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id BE3FE21F8665 for ; Thu, 15 Mar 2012 01:56:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4C9928700D9; Thu, 15 Mar 2012 09:56:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rqdg-h6yVee9; Thu, 15 Mar 2012 09:56:39 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 5B27987004D; Thu, 15 Mar 2012 09:56:39 +0100 (CET) Message-ID: <4F61AEC7.5040401@globis.net> Date: Thu, 15 Mar 2012 09:56:39 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Fred Baker References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050308060700060207020403" Cc: Ashok Narayanan , Cameron Byrne , "homenet@ietf.org Group" , =?ISO-8859-1?Q?Roger_J=F8rgensen?= , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 08:56:48 -0000 This is a multi-part message in MIME format. --------------050308060700060207020403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Whilst I don't disagree significantly with Fred's list (which seems to match the functionality of the installed IPv4 base), I think the challenge for Homenet is going to be to make this requirements list work in a multi-vendor environment out of the shrink wrap (Homenet architecture by definition assumes more than one CPE device). To me, ensuring interoperability is the main added value of the Homenet WG. I therefore humbly submit that language based on "MAY" is generally not going to cut it for Homenet. Here are my suggested modifications of Fred's list, for further improvement. 1) s/a CPE Router MAY include a firewall function/a Customer Edge Router (CER) SHOULD implement a mechanism to facilitate egress and ingress access control of traffic crossing the external border of the Homenet. This MAY be implemented either as a firewall or as simple IPv6 Access Control List (ACL)./ ACL being debatable, but it's functionality that exists today in IPv4 and which works. Who am I to say that isn't "good enough" for some folks' security needs? As an end-user, I'm all for functional equivalence with IPv4. 2) For me it's debatable whether the Homenet WG needs to further define how this egress or ingress control functionality actually processes traffic. That's something IMHO where vendors can differentiate their products, and which can evolve over time. Perhaps: /The firewall MAY be functionally defined by draft-ietf-v6ops-cpe-simple-security or draft-vyncke-advanced-ipv6-security-03. Other functional definitions of the ingress and egress access control mechanism may be introduced to Homenet later. As a general principle, equivalent security controls SHOULD be applied to both IPv4 and IPv6 traffic when running in dual stack mode at the external boundary./ 3) s/IF such a function is implemented, it MUST be possible to disable it, reducing the CPE to a simple router./ It MUST be possible to disable the ingress and egress access control function to reduce the CER to a simple router, and the mechanism to achieve this SHOULD ...../ In this case, "be manual" or do you want the device to "auto-detect that the device is acting as a CER"? I think this is pretty essential for ensuring that Homenet works as a system when users plug and play kit from various vendors. Perhaps the detail is best left for another day. 4) s/IF it is a "deny all" firewall, it SHOULD have a means of providing access rules for services inside the home/ IF it is a "deny all" ingress mechanism, it SHOULD have a means of providing access rules for services located inside the home, and the mechanism to achieve this SHOULD be ...../ "PCP"? If PCP isn't considered by the WG to be "good enough" for the task of acting as the Homenet control protocol for the ingress and egress security function, then I submit that the challenge is either going to be to make PCP "good enough", or come up with an alternative. I am neutral on what the control protocol should be. But there's no doubt in my mind that we really should define an open and standard control protocol to configure the ingress and egress access control mechanism (to ensure interoperability, to preserve e2e, and to ensure the sanity of developers and end users). regards, RayH Fred Baker wrote: > On Mar 13, 2012, at 10:11 PM, Cameron Byrne wrote: > >> My cursory research says you are not going to be able to present a convincing amount of data to support the fact that a stateful >> inspection firewall should be applied in a contemporary home environment. >> > > I don't recall anyone saying that a "stateful inspection" firewall was specifically called for. I think we argued that there is a market expectation that a firewall is at least available, and that however the firewall is implemented, it should prevent simple attacks from "outside" the network (I will argue "network layer attacks" as opposed to combing through bits in layers above). As we get into the specifics of kinds of firewalls, I think we're treading even more heavily on people's religion. > > As to "kinds of firewalls", I have a posted draft (which I think I mentioned), which might be discussed in opsawg and might be discussed in the Security Area meeting. I haven't heard a decision on that. I would suggest we defer to that discussion. However, as far as *this* draft goes, I think that it is fair to say that > > - a CPE Router MAY include a firewall function. > > - IF such a function is implemented, it MUST be possible to disable > it, reducing the CPE to a simple router. > > (my rule on the use of "MUST": I use the term when failing to > do so breaks something, and I try to say what breaks. In this > case, a CPE Router that has a firewall that can't be turned off > cannot be used as an interior router in the home network) > > - IF it is a "deny all" firewall, it SHOULD have a means of providing > access rules for services inside the home, such as allowing SMTP > to an SMTP server or ISP access to a set-top box. PCP or other > protocols like it MAY be used to achieve that. > > - IF it is a role-based firewall, it SHOULD have a means of > configuring and using roles. > > - IF it is a stateful inspection, reputation-based, or anomaly > detection firewall, it SHOULD have a way to maintain the indicated > tables such as periodic download of signed files from a trusted > site. > > > --------------050308060700060207020403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Whilst I don't disagree significantly with Fred's list (which seems to match the functionality of the installed IPv4 base), I think the challenge for Homenet is going to be to make this requirements list work in a multi-vendor environment out of the shrink wrap (Homenet architecture by definition assumes more than one CPE device). To me, ensuring interoperability is the main added value of the Homenet WG.

I therefore humbly submit that language based on "MAY" is generally not going to cut it for Homenet.

Here are my suggested modifications of Fred's list, for further improvement.

1) s/a CPE Router MAY include a firewall function/a Customer Edge Router (CER) SHOULD implement a mechanism to facilitate egress and ingress access control of traffic crossing the external border of the Homenet. This MAY be implemented either as a firewall or as simple IPv6 Access Control List (ACL)./

ACL being debatable, but it's functionality that exists today in IPv4 and which works. Who am I to say that isn't "good enough" for some folks' security needs? As an end-user, I'm all for functional equivalence with IPv4.

2) For me it's debatable whether the Homenet WG needs to further define how this egress or ingress control functionality actually processes traffic. That's something IMHO where vendors can differentiate their products, and which can evolve over time.

Perhaps:
/The firewall MAY be functionally defined by draft-ietf-v6ops-cpe-simple-security or draft-vyncke-advanced-ipv6-security-03. Other functional definitions of the ingress and egress access control mechanism may be introduced to Homenet later. As a general principle, equivalent security controls SHOULD be applied to both IPv4 and IPv6 traffic when running in dual stack mode at the external boundary./

3) s/IF such a function is implemented, it MUST be possible to disable it, reducing the CPE to a simple router./
It MUST be possible to disable the ingress and egress access control function to reduce the CER to a simple router, and the mechanism to achieve this SHOULD ...../

In this case, "be manual" or do you want the device to "auto-detect that the device is acting as a CER"?
I think this is pretty essential for ensuring that Homenet works as a system when users plug and play kit from various vendors.
Perhaps the detail is best left for another day.

4) s/IF it is a "deny all" firewall, it SHOULD have a means of providing access rules for services inside the home/
IF it is a "deny all" ingress mechanism, it SHOULD have a means of providing access rules for services located inside the home, and the mechanism to achieve this SHOULD be ...../

"PCP"?

If PCP isn't considered by the WG to be "good enough" for the task of acting as the Homenet control protocol for the ingress and egress security function, then I submit that the challenge is either going to be to make PCP "good enough", or come up with an alternative. I am neutral on what the control protocol should be. But there's no doubt in my mind that we really should define an open and standard control protocol to configure the ingress and egress access control mechanism (to ensure interoperability,  to preserve e2e, and to ensure the sanity of developers and end users).

regards,
RayH

Fred Baker wrote: 
On Mar 13, 2012, at 10:11 PM, Cameron Byrne wrote:
  
My cursory research says you are not going to be able to present a convincing amount of data to support the fact that a stateful
inspection firewall should be applied in a contemporary home environment. 
    

I don't recall anyone saying that a "stateful inspection" firewall was specifically called for. I think we argued that there is a market expectation that a firewall is at least available, and that however the firewall is implemented, it should prevent simple attacks from "outside" the network (I will argue "network layer attacks" as opposed to combing through bits in layers above). As we get into the specifics of kinds of firewalls, I think we're treading even more heavily on people's religion.

As to "kinds of firewalls", I have a posted draft (which I think I mentioned), which might be discussed in opsawg and might be discussed in the Security Area meeting. I haven't heard a decision on that. I would suggest we defer to that discussion. However, as far as *this* draft goes, I think that it is fair to say that

 - a CPE Router MAY include a firewall function.

 - IF such a function is implemented, it MUST be possible to disable
   it, reducing the CPE to a simple router.

   (my rule on the use of "MUST": I use the term when failing to
   do so breaks something, and I try to say what breaks. In this
   case, a CPE Router that has a firewall that can't be turned off 
   cannot be used as an interior router in the home network)

 - IF it is a "deny all" firewall, it SHOULD have a means of providing
   access rules for services inside the home, such as allowing SMTP
   to an SMTP server or ISP access to a set-top box. PCP or other
   protocols like it MAY be used to achieve that.

 - IF it is a role-based firewall, it SHOULD have a means of
   configuring and using roles.

 - IF it is a stateful inspection, reputation-based, or anomaly 
   detection firewall, it SHOULD have a way to maintain the indicated
   tables such as periodic download of signed files from a trusted
   site.

--------------050308060700060207020403-- From rogerj@gmail.com Thu Mar 15 06:13:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04EA21F854C for ; Thu, 15 Mar 2012 06:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.15 X-Spam-Level: X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 VQjg5zXCx0pJ for ; Thu, 15 Mar 2012 06:13:41 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 342B221F854A for ; Thu, 15 Mar 2012 06:13:41 -0700 (PDT) Received: by iazz13 with SMTP id z13so4520227iaz.31 for ; Thu, 15 Mar 2012 06:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=biULJAWEkfGMyCJ8/ewnBI93eOL03ciMUWlGnilf4vk=; b=Y12Hj0c/iyyhUseyb90W2rb6IfXt7RFeye86R/E8orwr9qR1dRde/usx73YgUxw96i zL6lMlZmELes2Q32u17PpgzOrG0e3rWXaQBf93R8wrQhx9EAfFwv+E1H8XbupkB23/tK oDq2GfvI2vfOds5J1whLCB++7f8mh7178dTrE0foHh/UKnzAD7Kx+frFBvnmKRrrkhWL zwjh2VOkpg9djciK3/Q3I8HaYKKGiyORr9AXAyly3cI9BtOghICEWZEWwxP2k2mwgVtS dUAlzGSzMho0Antf5Hq6o43jQj5KnOz3pJ5nvpF6uSpPWEvsXLwpjkhDlDF4y8XE/lOG 165Q== MIME-Version: 1.0 Received: by 10.50.216.231 with SMTP id ot7mr10280276igc.8.1331817220858; Thu, 15 Mar 2012 06:13:40 -0700 (PDT) Received: by 10.42.117.200 with HTTP; Thu, 15 Mar 2012 06:13:40 -0700 (PDT) In-Reply-To: References: <13119.1331487384@marajade.sandelman.ca> <7D6717D7-9AEE-4C69-AFF5-BD4927B5A126@mbaugher.com> <13475.1331738214@marajade.sandelman.ca> Date: Thu, 15 Mar 2012 14:13:40 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Cameron Byrne Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:13:42 -0000 On Wed, Mar 14, 2012 at 9:07 PM, Cameron Byrne wrote: > Making IPv6 restore e2e, or the internet model, is a worthy goal and i > am glad to help... But, if HOMENET is throwing in the towel, i can > lurk somewhere else and you folks can keep debating about OSPF vs RIP > and thinking that SPI makes something secure. I don't think we should throw in the towel just yet.... as I see it, homenet should by default _not_ care about traffic into homenet. That is the CPE's job. A seperate feature and function. However, homenet should _support_ the creation of several security "zones" internaly * One that is isolated toward The Big Bad World (Internet), no communication toward the CPE functionality * One that _ask_ the CPE to block all traffic into it * One that allow every packet that flow..... * whatever else we might figure out etc... The only default one should be allow all (leave the job to CPE) --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From C.Grundemann@CableLabs.com Thu Mar 15 08:01:07 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF6921F8713 for ; Thu, 15 Mar 2012 08:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 ELdlbIOAE3ty for ; Thu, 15 Mar 2012 08:01:07 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 43B5E21F872B for ; Thu, 15 Mar 2012 08:01:07 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2FEnl7S031705; Thu, 15 Mar 2012 09:01:05 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 15 Mar 2012 08:49:47 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 15 Mar 2012 08:39:54 -0600 From: Chris Grundemann To: Brian E Carpenter , "homenet@ietf.org" Date: Thu, 15 Mar 2012 08:40:05 -0600 Thread-Topic: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt Thread-Index: Ac0CuXxKudnetjTFRg6kPyvejASpNw== Message-ID: In-Reply-To: <4F5EAF3D.2020506@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:01:08 -0000 On 3/12/12 8:21 PM, "Brian E Carpenter" wrote: >Hi, > >How does this work when there are multiple customer edge routers (CERs), >as in a MIF situation for example? I'm afraid that I'm not familiar with 'MIF.' With apologies, can you tell me what that stands for? In general, the current version does not directly address multi-CER topologies. We noted that (perhaps not especially clearly) in section 2: "This document assumes that the vast majority of home networks will connect to a single ISP and will be generally constructed in a tree architecture." Because we suggest electing the home router attached to the ISP as the CER, a single ISP would mean a single CER. However, in a multi-CER situation as long as the two (or more) CERs know each others prefixes/routes, this mechanism will work. You would simply end up with two (or more) independent trees connected at the top, through the CERs. HTH, ~Chris > Brian > >On 2012-03-13 10:14, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >>=20 >> Title : Home Network Autoconfiguration via DHCPv6 Relay >> Author(s) : Chris Grundemann >> Chris Donley >> Filename : draft-gmann-homenet-relay-autoconf-01.txt >> Pages : 8 >> Date : 2012-03-12 >>=20 >> This document describes a method for efficiently delegating subnets >> of an IPv6 prefix among home routers while simultaneously creating >> functional routing tables in all home routers without the need for a >> routing protocol. >>=20 >>=20 >>=20 >> A URL for this Internet-Draft is: >>=20 >>http://www.ietf.org/internet-drafts/draft-gmann-homenet-relay-autoconf-01 >>.txt >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From james.gettys@alcatel-lucent.com Thu Mar 15 08:27:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B602421F872F for ; Thu, 15 Mar 2012 08:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] 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 Yw2Re3n5WOxG for ; Thu, 15 Mar 2012 08:27:25 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 268C021F84EA for ; Thu, 15 Mar 2012 08:27:23 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2FFIOpE007311 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Mar 2012 16:27:14 +0100 Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 15 Mar 2012 16:26:34 +0100 Received: from [135.222.104.231] (135.5.27.11) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 15 Mar 2012 11:26:31 -0400 Message-ID: <4F620A25.2030206@Alcatel-Lucent.com> Date: Thu, 15 Mar 2012 11:26:29 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Fred Baker References: <13119.1331487384@marajade.sandelman.ca> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.11] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 X-Mailman-Approved-At: Thu, 15 Mar 2012 08:57:07 -0700 Cc: =?ISO-8859-1?Q?Roger_J=F8rgensen?= , "homenet@ietf.org Group" , Michael Richardson Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:53:00 -0000 I'd like to get away from the worshipping of end-to-end (which I genuflect at that altar as much as anyone), and bring it back to reality slightly, amplifying a bit on some bits I've seen in parts of this long thread. I think Stuart Chesire pointed out remotely in the Philadelphia ftf meeting that attack surface is a real issue, and I think it is a rapidly growing issue. Here's reality: o the number of devices has been growing exponentially in people's houses: first it was one machine, then one/person, and now it's the TV(s), BluRay player(s) phones, NAS boxes, TiVO, Roku Box, Apple TV, and often more than one computer/person, IP camera(s), thermostat(s) (I just ordered a Nest to play with), printers, etc. This is the concrete example of my house, but even the grandparent's house I visit isn't that far behind, with around 3 laptops and a TiVO and a printer. More and more of these devices are "legacy" devices already that sit and rot without software updates (concrete example: the NAS box I have which hasn't seen a software update now in about 3 years). This is a huge problem, but not one this working group can undertake. Certainly the consumer electronics Linux efforts are trying to help this problem via the Linux foundation efforts. But I don't think this problem is going to go away, and certainly not in my lifetime. Even if rotting hardware didn't exist, and it all had the right UI's to let you control its access, you're asking the poor home manager to learn the management UI on all devices just to ensure the right policies are in case: this means there is essentially *zero* chance of succeeding. o there are certain policies I really want to enforce: the one that Dave Taht and I ran into last week installing the latest CeroWrt was the following: to ensure that Microsoft file services were *not* accessible by default to the outside; we had a bug that it was accessible via IPv6. My reasoning is the following: the RIAA would like me to legally liable for accidental sharing of my CD collection that I've digitised. So I really want to prevent this accidental sharing of a misconfigured laptop or NAS box; I really, really want to make sure it fails, so that my door is not left "unlocked" by accident. And there is lots of other personal data I'd also not like to share. So despite the fact that this is at best a half-measure, when we detected that via IPv6 the default firewall rules allowed such access on CeroWrt, Dave set it to deny, and I expect that that is what most people will want/need. In fact, for my NAS device, I really want to ensure that *all* ports are blocked from outside, since it's OS has been rotting and its attack surface grows with almost every passing day. So I'm not interested in default-deny in general; but I sure want to be able to easily do deny-all or deny a particular service to particular devices, or particularly insecure protocols to everyone (e.g. microsoft file sharing). For our general laptops, which are kept decently up to date, I probably *do* want almost all ports open (with the exception again of things like file sharing services, for the reason given above). This is yet another example of the *primary* utility of firewalls; reduce the attack surface, particularly to vulnerable systems, and to try to prevent things getting *out*, rather then coming in. In my example, I just want to be able to appear in court and say to the judge: "my door was locked". As a way of keeping things out: we know that doesn't work in general; at most firewalls can reduce the attack surface from the outside. Ok, what have I been thinking about doing for CeroWrt, that is more nuanced? ============================================== I've been thinking about this problem a lot this week, as I need to put time based controls to help my son control his game playing, have been thinking about visibility of internal names to the global internet, and how to ensure diffserv is handled properly (if the home gateway has no controls over diffserv for users, then it will be gamed to uselessness by applications/devices). I'm writing this lengthy message in part as it's helping me to make my thinking concrete. I'm really not worried about someone using my printer from outside: I suppose that they can waste some paper and toner, and if that becomes a problem, I'll put other (per person) access control on it. But for printer devices, I'll want a policy that opens my IPv6 capable printer to the world on some protocol, so I can easily print from anywhere. Since it's firmware is not frequently updated by HP, I probably want all other ports "closed", just to reduce it's attack surface. I don't know if the printer has an internal firewall or not... For actively maintained laptops/phones, I'll want a policy that allows pretty much full access, with the exception of file sharing, where I'll want my kids and wife to have to come see me to do anything out of the ordinary (until we have file sharing protocols that enforce strong authentication). On top of this basic policy, I may want to add the time based control for my son. My NAS box(es) I want default deny all, until/unless someone can sell me one (or I set one up myself) that does both strong authentication and is auto-updating its system. Similarly, depending on the update rate of the firmware and how general the device is, I may have other nuanced policies I'd like to have the firewall enforce. OK, where does this leave me? o having a firewall at all is necessary, if only to try to protect myself from the RIAA and rotting devices in my home. My primary systems are mostly kept up to date and wander all over the Internet, between work and school. o knowing what class of device it is may help a lot in setting the firewall rules. It might be useful to define a protocol that devices can inform the environment what they are to automate this, but something like that isn't going to happen any time soon and then presents yet another way to attack the system. So I need a way to associate a device (IP address or mac address) with a particular default rule (e.g. file server, printer, thermostat, camera and so on). On top of that I may have other access rules (e.g. no public internet access at all for my son after he should be in bed, so I can stop losing sleep every night). So it may be a device belongs to more than one class of device. You can think of a laptop as something which can be any class of device... But the user of that laptop may need other policies ;-). o end users can't have to know about port numbers or firewall rule languages; gotta do something pretty simple. o firewall rules that are global to all devices aren't what I want: I need to set the rules on a per-device basis. o because of attack surface issues, saying "just put devices into a DMZ" is an insufficient answer as those devices may not have actively maintained firmware and I want to reduce the attack surface against those devices. It isn't clear to me what a DMZ buys other than more complication. So on the KISS principle, I want to avoid DMZ's. o keeping track of all devices in my home has become a real problem: I want my home router to keep track of all MAC addresses it sees; from that (the physical device), I can associate a policy. So we'll see where I get to on all this. But it's a lot easier to think about these problems if you are actually trying to solve them yourself... (Hint... Hint... Hint.... Help very welcome!). - Jim From paduffy@cisco.com Thu Mar 15 10:26:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EFE21F87C5 for ; Thu, 15 Mar 2012 10:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.015 X-Spam-Level: X-Spam-Status: No, score=-10.015 tagged_above=-999 required=5 tests=[AWL=-1.717, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_HI=-8] 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 u7bcCGA71jjr for ; Thu, 15 Mar 2012 10:26:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CB61421F87AA for ; Thu, 15 Mar 2012 10:26:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=paduffy@cisco.com; l=5111; q=dns/txt; s=iport; t=1331832395; x=1333041995; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=gVoSJuXPTRn7mGzNddsOOGrIb3wuMymuw3A4l8ivwKY=; b=Lf3T2S4+KdoWpFZJ/XzhHiuaqdaNG57kIKAhwZokFVIWBPHLACt9GW9C TX0CrnsjHVXiAqtW4UvrDvspkSeGOEM8tP/Kc4kNjxjIjubqy1qkC4oqL U3EWa6Fu4Li94w/7WX+NknFMXxIhp6hiCWccxXEYcS+OH4Amt4t4kxuS3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocFAMUlYk+tJXG9/2dsb2JhbABDhTytZIMJgQeCCQEBAQMBEgECDlUBEAsEFAkWCwICCQMCAQIBRQYNAQcBARcHh2MFmnaDPBCJOJITj3GBFgSVYYVsiFOBAmaDAg X-IronPort-AV: E=Sophos;i="4.73,591,1325462400"; d="scan'208,217";a="66792232" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 15 Mar 2012 17:26:35 +0000 Received: from [161.44.66.230] (dhcp-161-44-66-230.cisco.com [161.44.66.230]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2FHQY2t017935; Thu, 15 Mar 2012 17:26:34 GMT Message-ID: <4F62264A.2070902@cisco.com> Date: Thu, 15 Mar 2012 13:26:34 -0400 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4F5A2929.4010802@freedesktop.org> <4F5A521B.9030601@gmail.com> <4F5A5D2F.5030302@cisco.com> <4F5BA45A.9040100@gmail.com> In-Reply-To: <4F5BA45A.9040100@gmail.com> Content-Type: multipart/alternative; boundary="------------090103060707070808000405" Cc: Michael Richardson , Jason Livingood , Dave Taht , Jim Gettys , homenet@ietf.org, David Harrington Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 17:26:36 -0000 This is a multi-part message in MIME format. --------------090103060707070808000405 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 3/10/2012 1:58 PM, Brian E Carpenter wrote: > > On 2012-03-10 08:42, Paul Duffy wrote: > > On 3/9/2012 1:55 PM, Brian E Carpenter wrote: > >> On 2012-03-10 05:00, Jim Gettys wrote: > >> ... > >>> I was just observing comments I came across in code being used for > >>> printer discovery. > >> Why would we consider anything other than SLP for service discovery? > > > > Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more > > traction in the consumer space than SLP. > > > > Please do correct if I'm wrong. > > Aren't we trying to influence the future rather than document the > past? > Agreed. The initial discussion re: service discovery should be requirements driven. I'll admit guilt re: starting to jump to a pre-mature conclusion. Partly driven by issue fatigue. I've been involved with this same requirements based discussion re: zero touch service discovery now within several venues, over many years. Its largely the same cast of characters. SLP vs DNS-SD vs uPnP SDDP. At some point, there needs to be a practical incorporation of which way the wind is blowing, unless there are compelling reasons to do otherwise. > > We need a name-based service discovery solution. That's also a > requirement emerging from 6renum. I think we should decide what's > the best recommendation; it may end up being DNS-based, but this > is what SLP was designed for, so IMHO it should be considered. > > This is clearly *not* what SNMP was designed for. > Totally agree. Particularly in light of the fact that IETF has acknowledged SNMP is typically used only for poll based status monitoring. > > Brian > --------------090103060707070808000405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 3/10/2012 1:58 PM, Brian E Carpenter wrote:
Re: [homenet] Discovery [snmp for monitoring home network]

On 2012-03-10 08:42, Paul Duffy wrote:
> On 3/9/2012 1:55 PM, Brian E Carpenter wrote:
>> On 2012-03-10 05:00, Jim Gettys wrote:
>> ...
>>> I was just observing comments I came across in code being used for
>>> printer discovery.
>> Why would we consider anything other than SLP for service discovery?
>
> Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more
> traction in the consumer space than SLP.
>
> Please do correct if I'm wrong.

Aren't we trying to influence the future rather than document the
past?


Agreed.  The initial discussion re: service discovery should be requirements driven.

I'll admit guilt re: starting to jump to a pre-mature conclusion.  Partly driven by issue fatigue.   I've been involved with this same requirements based discussion re: zero touch service discovery now within several venues, over many years.  Its largely the same cast of characters.  SLP vs DNS-SD vs uPnP  SDDP. 

At some point, there needs to be a practical incorporation of which way the wind is blowing, unless there are compelling reasons to do otherwise.


We need a name-based service discovery solution. That's also a
requirement emerging from 6renum. I think we should decide what's
the best recommendation; it may end up being DNS-based, but this
is what SLP was designed for, so IMHO it should be considered.

This is clearly *not* what SNMP was designed for.


Totally agree.  Particularly in light of the fact that IETF has acknowledged SNMP is typically used only for poll based status monitoring.


   Brian


--------------090103060707070808000405-- From ietfdbh@comcast.net Thu Mar 15 11:08:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1AD21F85EF for ; Thu, 15 Mar 2012 11:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.132 X-Spam-Level: X-Spam-Status: No, score=-101.132 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, MANGLED_PREMTR=2.3, USER_IN_WHITELIST=-100] 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 7oOpBBDVANX7 for ; Thu, 15 Mar 2012 11:08:59 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id DB86221F85CD for ; Thu, 15 Mar 2012 11:08:58 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id lnhf1i0061c6gX85Du8zkw; Thu, 15 Mar 2012 18:08:59 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta23.westchester.pa.mail.comcast.net with comcast id lu8h1i00D3Ecudz3ju8qop; Thu, 15 Mar 2012 18:08:59 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 15 Mar 2012 14:08:39 -0400 From: David Harrington To: , Brian E Carpenter Message-ID: Thread-Topic: [homenet] Discovery [snmp for monitoring home network] In-Reply-To: <4F62264A.2070902@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Dave Taht , homenet@ietf.org, Jason Livingood , Jim Gettys , Michael Richardson Subject: Re: [homenet] Discovery [snmp for monitoring home network] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:08:59 -0000 Agreed. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/15/12 1:26 PM, "Paul Duffy" wrote: > > > > > > On 3/10/2012 1:58 PM, Brian E Carpenter wrote: > > > > Re: [homenet] Discovery [snmp for monitoring home network] > > On 2012-03-10 08:42, Paul Duffy wrote: > > On 3/9/2012 1:55 PM, Brian E Carpenter wrote: > >> On 2012-03-10 05:00, Jim Gettys wrote: > >> ... > >>> I was just observing comments I came across in > code being used for > >>> printer discovery. > >> Why would we consider anything other than SLP for > service discovery? > > > > Its my understanding that mDNS/DNS-SD and UPnP SDDP have > far more > > traction in the consumer space than SLP. > > > > Please do correct if I'm wrong. > > Aren't we trying to influence the future rather than document > the > past? > > > > > Agreed. The initial discussion re: service discovery should be > requirements driven. > > I'll admit guilt re: starting to jump to a pre-mature conclusion. > Partly driven by issue fatigue. I've been involved with this same > requirements based discussion re: zero touch service discovery now > within several venues, over many years. Its largely the same cast > of characters. SLP vs DNS-SD vs uPnP SDDP. > > At some point, there needs to be a practical incorporation of which > way the wind is blowing, unless there are compelling reasons to do > otherwise. > > > > > We need a name-based service discovery solution. That's also a > requirement emerging from 6renum. I think we should decide > what's > the best recommendation; it may end up being DNS-based, but > this > is what SLP was designed for, so IMHO it should be considered. > > This is clearly *not* what SNMP was designed for. > > > > > Totally agree. Particularly in light of the fact that IETF has > acknowledged SNMP is typically used only for poll based status > monitoring. > > > > > Brian > > > > > > > From rdroms.ietf@gmail.com Thu Mar 15 11:21:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2912E21F87F1 for ; Thu, 15 Mar 2012 11:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.293 X-Spam-Level: X-Spam-Status: No, score=-103.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 goWiKlt7GeuY for ; Thu, 15 Mar 2012 11:21:40 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 744D021F8810 for ; Thu, 15 Mar 2012 11:21:40 -0700 (PDT) Received: by eeke51 with SMTP id e51so2004652eek.31 for ; Thu, 15 Mar 2012 11:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=gpu0kVGp6prShFI8LH6pmApG7YyexyeY/x1bmXDw9lI=; b=IS6hUf/eygJyy2LUWQuHkgLa1GHfeHA4ydmtAbCNFmqy0+f/uMJR+KCWgtsE9iaG+j 7YiIIJ0cLzcufag38LCPCvULua9w5jDl++N75TM0I0yha6589Iqx2hHcU36OP8li9fzW q+F7ARqHLhYI/JDdtm8cvPjGBIGIBon4qaADnP4nBwQ5R45KKBzdKpRhzPhRGxr3P31w id7P4+IfkBuxlcHfKf5sjTbvfV4E4GvaLwhLt01xIhHI3Dls2w1FbCGHDBzu6bDkIvEa BMAmKnKaWKTn7RNQtOOOwc63oTMUEh6qm0Dmc6ekyuNHBD0X0XQaULz4d3kVWU38Kn+y B0EA== Received: by 10.229.107.9 with SMTP id z9mr2679156qco.80.1331835699372; Thu, 15 Mar 2012 11:21:39 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id gv7sm5400493qab.5.2012.03.15.11.21.37 (version=SSLv3 cipher=OTHER); Thu, 15 Mar 2012 11:21:38 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Thu, 15 Mar 2012 14:21:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Chris Grundemann X-Mailer: Apple Mail (2.1251.1) Cc: "" Subject: Re: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:21:41 -0000 Chris - you might want to take a look at = draft-baker-homenet-prefix-assignment-01, which describes similar = technology (if I'm understanding your document correctly). - Ralph From brian.e.carpenter@gmail.com Thu Mar 15 12:43:48 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0CA421F852B for ; Thu, 15 Mar 2012 12:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.494 X-Spam-Level: X-Spam-Status: No, score=-104.494 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 4oTIvbTQY2OS for ; Thu, 15 Mar 2012 12:43:48 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 052C221F851C for ; Thu, 15 Mar 2012 12:43:47 -0700 (PDT) Received: by eeke51 with SMTP id e51so2064869eek.31 for ; Thu, 15 Mar 2012 12:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BIh8jlZz0TYTODqArLg256zBNlX/5GRxkvra5ZHQ9rg=; b=h6qVP4arBgAUn7UiUZPjBJqhRGwv6dutV8H+Ai3Y62d8MvTu2hKkNxpQeMqOoTL8rT mvV8RNNLw4HU7egl1ao/t70COvbD7Bqgq6txNpg4WQKthqKVhzdZppWhQoNCZ39GNvsy u8yMfMQ2tjDrAxl15ybobxbkD3htkSDZN1QxIUIjC8Q77gxTBI71STshqH26c/9xrz18 9omK1mHw6XOeh6XRPBYt/JhENvuwkWkU086YXCl9oujDcG8GMojKS9YxsIFVHlBPiFhf L/EDK0SttS1wpsl7aH9qDqwSOtrg82l+nUGpZEniB5clvKhVxsPjSBgXuVTcY+L5C4QV eEPQ== Received: by 10.213.2.83 with SMTP id 19mr581357ebi.241.1331840627162; Thu, 15 Mar 2012 12:43:47 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x8sm10298333eea.10.2012.03.15.12.43.43 (version=SSLv3 cipher=OTHER); Thu, 15 Mar 2012 12:43:46 -0700 (PDT) Message-ID: <4F62466A.5020805@gmail.com> Date: Fri, 16 Mar 2012 08:43:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Chris Grundemann References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org" Subject: Re: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:43:48 -0000 On 2012-03-16 03:40, Chris Grundemann wrote: > On 3/12/12 8:21 PM, "Brian E Carpenter" > wrote: > >> Hi, >> >> How does this work when there are multiple customer edge routers (CERs), >> as in a MIF situation for example? > > I'm afraid that I'm not familiar with 'MIF.' With apologies, can you tell > me what that stands for? What, you don't know *every* 3 letter acronym by heart? MIF is the IETF Multiple InterFaces working group: http://datatracker.ietf.org/wg/mif/charter/ It's very likely that many homenets will have two providers (e.g. wireline and wireless) and therefore the issues that MIF is discussing all affect homenet, as far as I can see. Brian > > In general, the current version does not directly address multi-CER > topologies. We noted that (perhaps not especially clearly) in section 2: > > "This document assumes that the vast majority of home networks will > connect to a single ISP and will be generally constructed in a tree > architecture." > > Because we suggest electing the home router attached to the ISP as the > CER, a single ISP would mean a single CER. However, in a multi-CER > situation as long as the two (or more) CERs know each others > prefixes/routes, this mechanism will work. You would simply end up with > two (or more) independent trees connected at the top, through the CERs. > > HTH, > ~Chris > >> Brian >> >> On 2012-03-13 10:14, internet-drafts@ietf.org wrote: >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : Home Network Autoconfiguration via DHCPv6 Relay >>> Author(s) : Chris Grundemann >>> Chris Donley >>> Filename : draft-gmann-homenet-relay-autoconf-01.txt >>> Pages : 8 >>> Date : 2012-03-12 >>> >>> This document describes a method for efficiently delegating subnets >>> of an IPv6 prefix among home routers while simultaneously creating >>> functional routing tables in all home routers without the need for a >>> routing protocol. >>> >>> >>> >>> A URL for this Internet-Draft is: >>> >>> http://www.ietf.org/internet-drafts/draft-gmann-homenet-relay-autoconf-01 >>> .txt >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > From ckd@us.ibm.com Thu Mar 15 14:20:43 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA20C21F86B4 for ; Thu, 15 Mar 2012 14:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 6cQvtLVAVDoj for ; Thu, 15 Mar 2012 14:20:42 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3EE21F86AA for ; Thu, 15 Mar 2012 14:20:42 -0700 (PDT) Received: from /spool/local by e3.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 15 Mar 2012 17:20:41 -0400 Received: from d01dlp01.pok.ibm.com (9.56.224.56) by e3.ny.us.ibm.com (192.168.1.103) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 15 Mar 2012 17:18:40 -0400 Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 0BEF938C805C for ; Thu, 15 Mar 2012 17:18:37 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q2FLIbGU277146 for ; Thu, 15 Mar 2012 17:18:37 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q2FLIZ5Q008941 for ; Thu, 15 Mar 2012 18:18:35 -0300 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q2FLIX1u008798 for ; Thu, 15 Mar 2012 18:18:34 -0300 In-Reply-To: References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F60F458.4080403@gmail.com> X-KeepSent: CE42265F:5E504CC6-862579C2:0074C444; type=4; name=$KeepSent To: Cameron Byrne X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: Colin Dixon Date: Thu, 15 Mar 2012 16:18:32 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.3HF266 | January 13, 2012) at 03/15/2012 17:18:34 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=09BBF351DFE742D48f9e8a93df938690918c09BBF351DFE742D4" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12031521-8974-0000-0000-0000074A5F9C Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 21:20:43 -0000 --0__=09BBF351DFE742D48f9e8a93df938690918c09BBF351DFE742D4 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable homenet-bounces@ietf.org wrote on 03/14/2012 02:57:14 PM: > From: Cameron Byrne > To: Brian E Carpenter , > Cc: Ashok Narayanan , Roger J=F8rgensen > , Fred Baker , "homenet@ietf.org > Group" , Michael Richardson > Date: 03/14/2012 02:58 PM > Subject: Re: [homenet] Security goals > Sent by: homenet-bounces@ietf.org > > Fred made a good assesment that the firewall is just protecting the > LAN bandwidth from junk. I can buy that. But assuming LAN > WAN in > capacity, and usually by an order of magnitude, it is still not > justified IMHO. If the LAN is wireless (as it almost certainly will be), then there is no clean way to assert that LAN > WAN and, even more so, any extra traffic on the WLAN can cause problems w.r.t. power consumption for devices with batteries. --Colin= --0__=09BBF351DFE742D48f9e8a93df938690918c09BBF351DFE742D4 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

homenet-bounces@ietf.org wrote on 03/14/2012 02= :57:14 PM:
> From: Cameron Byrne <cb.list6@gmail.com>
> To: Brian E Carpenter <brian.e.carpenter@g= mail.com>,
> Cc: Ashok Narayanan <ashokn@cisco.com>,= Roger J=F8rgensen
> <rogerj@gmail.com>, Fred Baker <fred@cisco.com>, "= ;homenet@ietf.org
> Group" <homenet@ietf.org>, Michael Richardson <mcr@s= andelman.ca>
> Date: 03/14/2012 02:58 PM
> Subject: Re: [homenet] Security goals<= /tt>
> Sent by: homenet-bounces@ietf.org=
>
> Fred made a good assesment that the firewall is just protecting th= e
> LAN bandwidth from junk.  I can buy that. But assuming LAN &g= t; WAN in
> capacity, and usually by an order of magnitude, it is still not > justified IMHO.

If the LAN is wireless (as it almost certainly wil= l be), then there
is no clean way to assert that LAN > WAN and, e= ven more so, any
extra traffic on the WLAN can cause problems w.r.t= . power
consumption for devices with batteries.

--Colin= --0__=09BBF351DFE742D48f9e8a93df938690918c09BBF351DFE742D4-- From kerlyn2001@gmail.com Sat Mar 17 10:02:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD3621F855B; Sat, 17 Mar 2012 10:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 yHjY3FIqDTvs; Sat, 17 Mar 2012 10:02:08 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2C621F851C; Sat, 17 Mar 2012 10:02:07 -0700 (PDT) Received: by lbol12 with SMTP id l12so3017015lbo.31 for ; Sat, 17 Mar 2012 10:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nDCqmtwCBE9KSOH9MiptdcK7cfS3mizeJsLWmQSzYXM=; b=v8t2aGG8RQFhAgwwIvi+O9J2N0c5FbrraJN6G5M+kPTHo/XN6nq/6l8FwHbqjXF1RP a7b3ZzNdfKAJ8zIr+LJjuOeyhZtCfK+W5vAQtekjRGwxZxhI4bLeEYKYud9Qm18YFV3O bXTSYTSx6jqFGZAytcc++tN0zE7raLWGrKEEvnsTAfJI8paj6hjUBBLzDBJFif7lqwDn KCeAojA0R9WKNTYHkd4t3tlqRbOaYaj7eCU0PAqQpFebzGQdqnIoauZZazymR2sb4dSr CF04grJo7x6AvTdxSeKT/+fB3w3albhQjvCOWxpJet9+tdT/015+fpM3vhaYz4JaXgrn q0VQ== MIME-Version: 1.0 Received: by 10.152.147.202 with SMTP id tm10mr5350122lab.49.1332003726278; Sat, 17 Mar 2012 10:02:06 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.112.77.179 with HTTP; Sat, 17 Mar 2012 10:02:06 -0700 (PDT) In-Reply-To: References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Date: Sat, 17 Mar 2012 13:02:06 -0400 X-Google-Sender-Auth: INHGq7o-CvCWzd3hGwVNkW4bzRw Message-ID: From: Kerry Lynn To: 6man , "homenet@ietf.org Group" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 17:02:09 -0000 On Sat, Mar 17, 2012 at 2:22 AM, Dave Thaler wrote: > Brian Carpenter writes: > [...] >> Let me be clear. If a local service has (for some reason) both a ULA and= a non- >> ULA global address, and the host has both, I think the correct default >> behaviour is for the ULA address pair to be used. > > As I put into the doc, I don't think that's quite right. > > If both the source and dest ULAs are in the same /48 then I think the cor= rect > default is as you say (use ULA). > > If the source and dest ULAs are in different /48's then I think the corre= ct > default is instead to use the non-ULA global, since there's no guarantee = of > routability between different /48s. =A0So unless configured otherwise, on= e > has to assume it's far more problematic than a non-ULA global. > Do you mean "no guarantee of symmetric routability"? =A0The fact that the packet arrived in the first place seems to indicate earlier policy choices (e.g. the sender may not have a non-ULA global address, and the two /48s already seem to share a common definition of "site"). I am still relatively new to homenet and I am surely missing a lot of background. =A0Has anyone discussed dealing with multiple /48 ULA prefixes in a single site? Thanks, -K- > You'll find the above logic in the current 3484bis draft. > > -Dave > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Anders_Brandt@sigmadesigns.com Tue Mar 20 01:51:37 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4532821F87D2; Tue, 20 Mar 2012 01:51:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1cHnv7Fpen9; Tue, 20 Mar 2012 01:51:36 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id E00D121F87EF; Tue, 20 Mar 2012 01:51:35 -0700 (PDT) From: Anders Brandt To: Kerry Lynn , 6man , "homenet@ietf.org Group" Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: AQHNBF/JLon5l3+WvUuFCR1klHlwqJZy4dkA Date: Tue, 20 Mar 2012 08:51:31 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-ex1> References: <4EB3F3D6.4090302@innovationslab.net> <4EEA3D20.7020603@innovationslab.net> <4EEA5793.8080800@gmail.com> <4EEA7AF8.2090508@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.120] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 08:51:37 -0000 Kerry Lynn writes: > On Sat, Mar 17, 2012 at 2:22 AM, Dave Thaler > wrote: > > Brian Carpenter writes: > > [...] > >> Let me be clear. If a local service has (for some reason) both a ULA > >> and a non- ULA global address, and the host has both, I think the > >> correct default behaviour is for the ULA address pair to be used. > > > > As I put into the doc, I don't think that's quite right. > > > > If both the source and dest ULAs are in the same /48 then I think the > > correct default is as you say (use ULA). > > > > If the source and dest ULAs are in different /48's then I think the > > correct default is instead to use the non-ULA global, since there's no > > guarantee of routability between different /48s. =A0So unless configure= d > > otherwise, one has to assume it's far more problematic than a non-ULA > global. > > > Do you mean "no guarantee of symmetric routability"? =A0The fact that the > packet arrived in the first place seems to indicate earlier policy choice= s (e.g. > the sender may not have a non-ULA global address, and the two /48s alread= y > seem to share a common definition of "site"). >=20 > I am still relatively new to homenet and I am surely missing a lot of > background. =A0Has anyone discussed dealing with multiple /48 ULA prefixe= s > in a single site? I would like to second Kerry. It is a surprise to me that ULA addresses are not by default routable withi= n the site. I can easily imagine a number of LLN border routers which autonomously allo= cate different ULA prefixes for use within their individual LLN subnets. Meeting a ULA address outside the local prefix will cause the LLN node to f= orward its IP packets to the default gateway (border router) of the LLN subnet. Th= is way packets can travel between LLN subnets using normal routing with long-term = stable ULA addresses. We need the stable addresses for control-style applications = in LLNs. Obviously it requires a routing protocol in the (homenet) LAN but are there= other issues? Thanks, Anders >=20 > > You'll find the above logic in the current 3484bis draft. > > > > -Dave > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Tue Mar 20 14:26:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3D221F85A4; Tue, 20 Mar 2012 14:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.132 X-Spam-Level: X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 16yX3SqEj7r1; Tue, 20 Mar 2012 14:26:04 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38A5A21F85A3; Tue, 20 Mar 2012 14:26:04 -0700 (PDT) Received: by dakl33 with SMTP id l33so561573dak.31 for ; Tue, 20 Mar 2012 14:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4pCWAxuWl6tggh0bkdZ2roAwi+dvY+9087L0JG+PAfA=; b=Og8ueXzfTLFfROY+7k6xqbHH8DOGqMFfFNsqv0Nw7XjQaSVOduo6dtBl0Mytmt5ixw orqXgypU6/0DBshkn6IGCtrfaoWJoUXf9yUBG+ffU9lNbGMW0DOj7SoTuLjaOATmvy/h oaBkodjq2UG9PJMNK3bxXeAE5vvMpXv+n3Pa3dMtaVhgsN+pHmu8aGDD9gOQtO9eao7E dLpA79sAAx3jEulZZeQZsTW/Jq2BMwTyUt7DQRH92bFFAANeu5ozefc1Sn6o1xaKWbTD SzOAU3sXR7tz/yFDUn9m+UroUf3pMcER+ev4Xtq2TUkDYHdjKFH5Q99AIZSoizqgBGaw XPUg== Received: by 10.68.203.202 with SMTP id ks10mr4787714pbc.84.1332278763734; Tue, 20 Mar 2012 14:26:03 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id y9sm2067366pbu.40.2012.03.20.14.26.01 (version=SSLv3 cipher=OTHER); Tue, 20 Mar 2012 14:26:03 -0700 (PDT) Message-ID: <4F68F5E5.7060901@gmail.com> Date: Wed, 21 Mar 2012 10:25:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Anders Brandt References: <4EB3F3D6.4090302@innovationslab.net> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-ex 1> In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-ex1> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kerry Lynn , 6man , "homenet@ietf.org Group" Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:26:05 -0000 On 2012-03-20 21:51, Anders Brandt wrote: > Kerry Lynn writes: > >> On Sat, Mar 17, 2012 at 2:22 AM, Dave Thaler >> wrote: >>> Brian Carpenter writes: >>> [...] >>>> Let me be clear. If a local service has (for some reason) both a ULA >>>> and a non- ULA global address, and the host has both, I think the >>>> correct default behaviour is for the ULA address pair to be used. >>> As I put into the doc, I don't think that's quite right. >>> >>> If both the source and dest ULAs are in the same /48 then I think the >>> correct default is as you say (use ULA). >>> >>> If the source and dest ULAs are in different /48's then I think the >>> correct default is instead to use the non-ULA global, since there's no >>> guarantee of routability between different /48s. So unless configured >>> otherwise, one has to assume it's far more problematic than a non-ULA >> global. >> Do you mean "no guarantee of symmetric routability"? The fact that the >> packet arrived in the first place seems to indicate earlier policy choices (e.g. >> the sender may not have a non-ULA global address, and the two /48s already >> seem to share a common definition of "site"). >> >> I am still relatively new to homenet and I am surely missing a lot of >> background. Has anyone discussed dealing with multiple /48 ULA prefixes >> in a single site? > > I would like to second Kerry. > > It is a surprise to me that ULA addresses are not by default routable within the site. > I can easily imagine a number of LLN border routers which autonomously allocate > different ULA prefixes for use within their individual LLN subnets. IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they cover an entire enterprise or home network, but not if they cover a subset. > Meeting a ULA address outside the local prefix will cause the LLN node to forward > its IP packets to the default gateway (border router) of the LLN subnet. This way > packets can travel between LLN subnets using normal routing with long-term stable > ULA addresses. We need the stable addresses for control-style applications in LLNs. > > Obviously it requires a routing protocol in the (homenet) LAN but are there other issues? It doesn't just require a routing protocol; it also requires a routing policy that knows which routers have to block the ULAs (plural). That seems a lot more complex that a rule that says only a border router originates and delegates a ULA prefix, because that border router would also know to block the prefix across the border. Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis and discuss it over on v6ops. Brian > > Thanks, > Anders >>> You'll find the above logic in the current 3484bis draft. >>> >>> -Dave >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From C.Grundemann@cablelabs.com Tue Mar 20 16:01:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A91621F85AC for ; Tue, 20 Mar 2012 16:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.093 X-Spam-Level: X-Spam-Status: No, score=-0.093 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 QrMPD5zuUWGR for ; Tue, 20 Mar 2012 16:01:17 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDBE21F8595 for ; Tue, 20 Mar 2012 16:01:17 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2KN1F2X008991; Tue, 20 Mar 2012 17:01:15 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 20 Mar 2012 17:01:15 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 20 Mar 2012 17:01:15 -0600 From: Chris Grundemann To: Ralph Droms , Chris Donley , Fred Baker Date: Tue, 20 Mar 2012 17:01:13 -0600 Thread-Topic: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt Thread-Index: Ac0G7Vnx9mTgi25pSaeqB6ZbnQSnXg== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "" Subject: Re: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 23:01:18 -0000 Hi Ralph, Thanks for the pointer. I had previously read draft-baker-homenet-prefix-assignment-00 but had not yet seen the -01. I just read through it again in depth and I agree that we are describing similar technology. It appears that draft-baker covers the high-level "home networks could use DHCPv6" while draft-gmann takes a "here's how to make DHCPv6 Relay work in home networks." If that's a correct observation, perhaps we should combine forces to document the mechanisms more completely? I think we could find a way to merge the detailed procedure and requirements for using DHCPv6 relay from draft-gmann into draft-baker. The next step would likely be to add detailed steps for using unicast DHCPv6. Thoughts? ~Chris PS - I unfortunately will not be in Paris next week but Chris Donley will be and I'm sure he'd be happy to talk this through a bit more if you and/or Fred are amenable and available. On 3/15/12 12:21 PM, "Ralph Droms" wrote: >Chris - you might want to take a look at >draft-baker-homenet-prefix-assignment-01, which describes similar >technology (if I'm understanding your document correctly). > >- Ralph > From C.Grundemann@cablelabs.com Tue Mar 20 16:13:57 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DC021E8018 for ; Tue, 20 Mar 2012 16:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 qhe1tOzV0GmC for ; Tue, 20 Mar 2012 16:13:57 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55921E800F for ; Tue, 20 Mar 2012 16:13:57 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2KNDuOg010287; Tue, 20 Mar 2012 17:13:56 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 20 Mar 2012 17:13:56 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 20 Mar 2012 17:13:56 -0600 From: Chris Grundemann To: Brian E Carpenter Date: Tue, 20 Mar 2012 17:13:54 -0600 Thread-Topic: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt Thread-Index: Ac0G7x82ATZYIgsATaejEoWAQkzQsg== Message-ID: In-Reply-To: <4F62466A.5020805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "homenet@ietf.org" Subject: Re: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 23:13:57 -0000 On 3/15/12 1:43 PM, "Brian E Carpenter" wrote: >On 2012-03-16 03:40, Chris Grundemann wrote: >> On 3/12/12 8:21 PM, "Brian E Carpenter" >> wrote: >>=20 >>> Hi, >>> >>> How does this work when there are multiple customer edge routers >>>(CERs), >>> as in a MIF situation for example? >>=20 >> I'm afraid that I'm not familiar with 'MIF.' With apologies, can you >>tell >> me what that stands for? > >What, you don't know *every* 3 letter acronym by heart? I aspire to. =3D) >MIF is the IETF Multiple InterFaces working group: >http://datatracker.ietf.org/wg/mif/charter/ Thanks. >It's very likely that many homenets will have two providers >(e.g. wireline and wireless) and therefore the issues that MIF is >discussing all affect homenet, as far as I can see. That's an interesting assertion. My personal read is that if we apply the 80/20 rule, it will be the 80% (or more) of residential internet subscribers (homenets) who choose not to pay for two providers. Cheers, ~Chris > Brian From mark@townsley.net Tue Mar 20 16:20:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BA021E801F for ; Tue, 20 Mar 2012 16:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.354, 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 Z8xuQyjgdOzL for ; Tue, 20 Mar 2012 16:20:04 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67A9D21F84E2 for ; Tue, 20 Mar 2012 16:20:04 -0700 (PDT) Received: by werb10 with SMTP id b10so578701wer.31 for ; Tue, 20 Mar 2012 16:20:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Y0E3jI2Nk5y431og5FH7mLEzyorP8/3GVIbLasGnfwc=; b=B0xuh638dtLczJ6kAuTE6f6aZ+wFcrtijpPwSw34RostV+Zi5t9G9FeEk8ykJDanRB vdmB66xdpWVJxObWrprYWvSWleA/U2qoXKrnXwE2b3L3btuGClBPWQVyCk0oWHWU2Ob1 nGPp09hlqsFb9uMde7p6+0S2qygsIFmB7STl9MxiqLbHTBMQ+uiGCPi8/MRNR23bX6bK ZwX2hM8dqnagsKHnaKF8amcSMBV0jVXnwwga7RVXxYhFyguumyAXlIWGKiC3+fjrbXaz MW76K/CpU3Cqhtpp2wWrBTSYus6tBcaUzaTv9CSfAsr3HHCEclBrIPET/5WL2Htoc/OH 6U6Q== Received: by 10.180.104.137 with SMTP id ge9mr3714451wib.20.1332285603596; Tue, 20 Mar 2012 16:20:03 -0700 (PDT) Received: from ams-townsley-8919.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n15sm37765631wiw.6.2012.03.20.16.20.01 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 16:20:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Mark Townsley In-Reply-To: <4F60F458.4080403@gmail.com> Date: Wed, 21 Mar 2012 00:19:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F60F458.4080403@gmail.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkptfS6qW1xaO0VyG0n/YFbhY8sdkV9DZnhdDlghsLYEZkpKqgWHAmX04crqOsSRJbGirec Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 23:20:06 -0000 Let me try and up-level a bit architecturally, because this is more = than just about whether we turn on or off a firewall on a particular = border.=20 Consider two routers fully within a homenet Now, list all the types of = traffic and information that might be exchanged between those routers, = e.g., - Datalink establishment - IP addressing for the link - IP Prefixes reachable by the router (what a "routing protocol" would = do) - Services present on the router itself - Services on connected links propagated via the router - User traffic=20 - etc... Our job is to determine what kind of link exists between two routers and = start crossing out items, in whole or in part, based on how promiscuous = we wish the routers to be on that link. In effect, we are deciding where = to break the network and where not to, but it is by doing this that we = carve out the separate "home", "guest" and "Internet" realms that we are = targeting to create. I think that what is most important at this moment = is to nail down what knobs we want to try and have available, what their = "out of the box" defaults are for the above 3 combinations of border = types, and allow for super-users, ISP-managed devices, etc. monkey = around with them as they wish according to what vendors and providers = can dream up. If we can agree on these, and still remain blocked on what = kind of firewall to recommend to be enabled by default, we will still = have accomplished quite a bit. So I'd like to encourage us to step out = of the firewall rathole for a moment, and look at this from a wider = angle. Further, if we *really* want to talk about goals for security of our = homenet routers, we should consider mandating the ability to download = bug fixes and security updates. Far and away, this has been what has = made hosts more secure in the past decade, why a home router would be = exempt from this baffles me. - Mark On Mar 14, 2012, at 8:41 PM, Brian E Carpenter wrote: > On 2012-03-14 18:11, Cameron Byrne wrote: >> On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan = wrote: >>> On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote: >>>=20 >>>=20 >>>> That's reality, and much as I love the e2e principle I think the = ordinary >>>> citizen is better off behind default-deny. >>>>=20 >>> I am not trying to be dense, but why? >>>=20 >>> What is the negative scenario of not having a homenet firewall on? = Using >>> real examples from the last 5 years .... I would like to know how a = cpe >>> firewall protects against real threats to modern software. >>>=20 >>> It seems hard to predict a priori what a "real threat" is going to = be. And >>> it seems unlikely that "modern software" is all that will be found = in >>> average homes. For example, will the Android version on the = refrigerator >>> display be updated? >>>=20 >>=20 >> Agreed about a priori. BUT! what else do we have to go on? I am >> asking for a baseline to justify why a CPE firewall is required. In >> fact, i have asked for it multiple times on this thread, and all i = get >> back is anecdotal hand waving, not technical reasons. >>=20 >> Putting the E back in IETF, let's see some data about why this >> function of the system must exist. >>=20 >> My cursory research says you are not going to be able to present a >> convincing amount of data to support the fact that a stateful >> inspection firewall should be applied in a contemporary home >> environment. I believe the spirit of Homenet is moving the internet >> forward without being beholden to the Morris worm and X.25 >=20 > Fred and I provided factual but local evidence of background radiation > of unwanted UDP packets. Actually there is a lot more systematic = evidence > of this too. For example, this week at the PAM conference in Vienna > there's a paper "One-way traffic monitoring with iatmon" by Nevil = Brownlee > that gives a detailed analysis of observed unwanted traffic, both UDP = and TCP SYN. > See = http://www.caida.org/publications/papers/2012/one_way_traffic_iatmon/ >=20 > Can you assert that all low-end homenet devices will be internally > protected against such traffic? >=20 > Bian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From fred@cisco.com Wed Mar 21 02:51:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9CF21F8674 for ; Wed, 21 Mar 2012 02:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 KqWsj5ikMHbP for ; Wed, 21 Mar 2012 02:51:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 157FD21F85F7 for ; Wed, 21 Mar 2012 02:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1736; q=dns/txt; s=iport; t=1332323515; x=1333533115; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=WXrB0icT8lX8vKu/r2zmD2P7ocsauxD79JNWTh9PW20=; b=mNXs4Oh5T9+3rfJScyf4s2qnS3/MundRFtf34KrSO2OsijPIWqnRllUI kKVqgvG39gLeF3UD0lpcQdYCctRj+EUUmfusVCNlD3CGoV0I+3K+2uwPA Xedzgsz5hwoQMKASWfh2mw74BGbH6EIzQEX6vzfNL59OA8tVWNrsZ8sRr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALSjaU+Q/khL/2dsb2JhbABEtn2BB4IJAQEBAwEBAQEPASc0CwULCw4KLiEGMAYTIodjBQuYPJ8ZBIlshjJjBJVfhW2FQYMRgWiCaA X-IronPort-AV: E=Sophos;i="4.73,623,1325462400"; d="scan'208";a="132912638" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2012 09:51:54 +0000 Received: from Freds-Computer.local (dhcp-10-55-82-142.cisco.com [10.55.82.142]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2L9prQm026351; Wed, 21 Mar 2012 09:51:53 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 21 Mar 2012 10:51:53 +0100 X-PGP-Universal: processed; by Freds-Computer.local on Wed, 21 Mar 2012 10:51:53 +0100 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 21 Mar 2012 10:51:45 +0100 Message-Id: <9BDB5DDF-0E32-43DE-9F44-D23C3A5FE8DF@cisco.com> References: To: Chris Grundemann X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "" , Chris Donley , Ralph Droms Subject: Re: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 09:51:56 -0000 I should think we could combine forces. The -00 also proposed a way to use DHCP/DHCPv6 within the home, and the = working group didn't like it (an option on the RA). If the working group = likes yours, then it's an obvious fit. On Mar 21, 2012, at 12:01 AM, Chris Grundemann wrote: > Hi Ralph, >=20 > Thanks for the pointer. I had previously read > draft-baker-homenet-prefix-assignment-00 but had not yet seen the -01. = I > just read through it again in depth and I agree that we are describing > similar technology. It appears that draft-baker covers the high-level > "home networks could use DHCPv6" while draft-gmann takes a "here's how = to > make DHCPv6 Relay work in home networks." If that's a correct = observation, > perhaps we should combine forces to document the mechanisms more > completely? I think we could find a way to merge the detailed = procedure > and requirements for using DHCPv6 relay from draft-gmann into = draft-baker. > The next step would likely be to add detailed steps for using unicast > DHCPv6. >=20 > Thoughts? >=20 > ~Chris >=20 > PS - I unfortunately will not be in Paris next week but Chris Donley = will > be and I'm sure he'd be happy to talk this through a bit more if you > and/or Fred are amenable and available. >=20 >=20 > On 3/15/12 12:21 PM, "Ralph Droms" wrote: >=20 >> Chris - you might want to take a look at >> draft-baker-homenet-prefix-assignment-01, which describes similar >> technology (if I'm understanding your document correctly). >>=20 >> - Ralph >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Wed Mar 21 04:21:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1253321F8664 for ; Wed, 21 Mar 2012 04:21:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZHUuSW13Rs7 for ; Wed, 21 Mar 2012 04:21:03 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 099D421F8690 for ; Wed, 21 Mar 2012 04:21:02 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2LBKxbn012013 for ; Wed, 21 Mar 2012 11:20:59 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2LBKxbn012013 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1332328859; bh=M2YjQTEhEH5IyZreHtbNxXfvxxE=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=Mcc9rXP/tRXnJgKc2eUMLoTAwHos/rPHUBYr8xgrOyy1rbhehdqaUoW7ejrCIW4wH hSO3sNUKEyYbGN6fiuVnBZ7fPmtoGm4jEXxnWZUwO80bYVql/qnq1l6HRUAsxFlk3c IAZdSz/jjbEes3uy5KTxPNH2IBrxpmBRQuySOkP8= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id o2KBKx0543740828iF ret-id none; Wed, 21 Mar 2012 11:20:59 +0000 Received: from [IPv6:2001:630:d0:ed03:c41f:eca9:3eba:be1c] ([IPv6:2001:630:d0:ed03:c41f:eca9:3eba:be1c]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2LBKv0W018214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 21 Mar 2012 11:20:57 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Tim Chown In-Reply-To: Date: Wed, 21 Mar 2012 11:20:58 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <651BA61B-1585-4F8B-84D8-5BCD8397E496@ecs.soton.ac.uk> To: homenet@ietf.org X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2KBKx054374082800; tid=o2KBKx0543740828iF; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2LBKxbn012013 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:21:04 -0000 On 20 Mar 2012, at 23:13, Chris Grundemann wrote: > On 3/15/12 1:43 PM, "Brian E Carpenter" > wrote: >> It's very likely that many homenets will have two providers >> (e.g. wireline and wireless) and therefore the issues that MIF is >> discussing all affect homenet, as far as I can see. >=20 > That's an interesting assertion. My personal read is that if we apply = the > 80/20 rule, it will be the 80% (or more) of residential internet > subscribers (homenets) who choose not to pay for two providers. One of the things to nail down in/by Paris is the level of multihoming = support required in the homenet arch text. Currently single CER, multiple uplink is required, beyond that multiple = CER, multiple uplink support is only "desirable". =20 Tim= From tjc@ecs.soton.ac.uk Wed Mar 21 04:55:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D53A21F8690; Wed, 21 Mar 2012 04:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 zLnpZ+vOuMz6; Wed, 21 Mar 2012 04:55:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 5790421F8684; Wed, 21 Mar 2012 04:55:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2LBt8cd023194; Wed, 21 Mar 2012 11:55:08 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2LBt8cd023194 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1332330908; bh=OZyVavRXXgFMTOe/6uSYjVc03KQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=TUr8NETdAGCqFmm/1sUl3kiypA4ZmgQi0JPtZzgmEHAZ4xumB6h4Zw4ix+eQqpX/L 8gQ8SB/Avrntj/zh+wHgf4idOS7nJL4as8BKcAKdzgdPKo4VYldk+K0Txl71gif8ym 2y+8H4P40v+iUULM40/xVC3Op0QtYSWXIVBFU/rI= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o2KBy80543741358O3 ret-id none; Wed, 21 Mar 2012 11:55:08 +0000 Received: from [IPv6:2001:630:d0:ed03:c41f:eca9:3eba:be1c] ([IPv6:2001:630:d0:ed03:c41f:eca9:3eba:be1c]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2LBt4Jn031716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Mar 2012 11:55:04 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Tim Chown In-Reply-To: <4F68F5E5.7060901@gmail.com> Date: Wed, 21 Mar 2012 11:55:05 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4EB3F3D6.4090302@innovationslab.net> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-e! x 1> <4F68F5E5.7060901@gmail.com> <031E46EC-73ED-44A4-B966-B249DCAD367C@ecs.soton.ac.uk> To: 6man , "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2KBy8054374135800; tid=o2KBy80543741358O3; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2LBt8cd023194 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 11:55:11 -0000 On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: > On 2012-03-20 21:51, Anders Brandt wrote: >>=20 >> It is a surprise to me that ULA addresses are not by default routable = within the site. >> I can easily imagine a number of LLN border routers which = autonomously allocate >> different ULA prefixes for use within their individual LLN subnets. >=20 > IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if = they > cover an entire enterprise or home network, but not if they cover a = subset. >=20 >> Meeting a ULA address outside the local prefix will cause the LLN = node to forward >> its IP packets to the default gateway (border router) of the LLN = subnet. This way >> packets can travel between LLN subnets using normal routing with = long-term stable >> ULA addresses. We need the stable addresses for control-style = applications in LLNs. >>=20 >> Obviously it requires a routing protocol in the (homenet) LAN but are = there other issues? >=20 > It doesn't just require a routing protocol; it also requires a routing = policy > that knows which routers have to block the ULAs (plural). That seems a = lot > more complex that a rule that says only a border router originates and = delegates > a ULA prefix, because that border router would also know to block the > prefix across the border. So we need to determine what the homenet arch text will say on this.=20 I think the assumption so far has been that, as per PD8 in = draft-ietf-homenet-arch-02,=20 one router would be elected the "master" to delegate /64 ULA prefixes = within the homenet, both to ULA-only LLNs and to links that also have a GUA prefix. = If there's=20 an assumption an LLN router will not support that, and instead generate = its own /48=20 ULA, we need to talk about that, or any other scenario that will lead to = multiple /48 ULAs=20 in a single homenet site. The arch text currently says that ULAs should be used (CN1) and that = ULAs should be=20 preferred for internal communications to GUAs (section 2.4). It doesn't = say how connections=20 from outside the homenet can be made to internal ULA-only devices. The 3484-bis text has changed the default ULA preference to protect = against ULA leakage, so if you now want ULAs preferred you need to somehow inject the = specific site /48 ULA being used with high precedence into the policy table (and as also = pointed out here if your=20 site is using less than a /48, you should also have some way to learn = what the site prefix=20 length is). In the homenet case is that injection achieved on receipt of = an RA, or would it=20 require the proposed DHCPv6 option to be used (which may not be widely = implemented=20 for some time, and the DHCPv6 server still needs to learn the ULA to put = in the option)?=20 On the one hand homenet is saying "we'd prefer to use ULAs by default = without needing some magic to achieve it" while 6man is saying "we need to protect = against ULA leakage,=20 so if you want to prefer ULA for internal connection stability figure = out the magic". =20 This needs to be mapped to words for the homenet arch text. Tim >=20 > Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis > and discuss it over on v6ops. >=20 > Brian >=20 >>=20 >> Thanks, >> Anders >>>> You'll find the above logic in the current 3484bis draft. >>>>=20 >>>> -Dave >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >>=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From Anders_Brandt@sigmadesigns.com Wed Mar 21 05:13:28 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0B921F86A5; Wed, 21 Mar 2012 05:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 3z5kHnEx8PP3; Wed, 21 Mar 2012 05:13:28 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id D0DD321F86A1; Wed, 21 Mar 2012 05:13:27 -0700 (PDT) From: Anders Brandt To: Brian E Carpenter Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: AQHNBF/JLon5l3+WvUuFCR1klHlwqJZy4dkAgADEt4CAAQHN4A== Date: Wed, 21 Mar 2012 12:13:19 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC1B71@cph-ex1> References: <4EB3F3D6.4090302@innovationslab.net> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-e x1> <4F68F5E5.7060901@gmail.com> In-Reply-To: <4F68F5E5.7060901@gmail.com> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.120] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com Cc: Kerry Lynn , 6man , "homenet@ietf.org Group" Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:13:28 -0000 QnJpYW4gQ2FycGVudGVyIHdyaXRlczoNCj4gT24gMjAxMi0wMy0yMCAyMTo1MSwgQW5kZXJzIEJy YW5kdCB3cm90ZToNCj4gPiBLZXJyeSBMeW5uIHdyaXRlczoNCj4gPg0KPiA+PiBPbiBTYXQsIE1h ciAxNywgMjAxMiBhdCAyOjIyIEFNLCBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29t Pg0KPiA+PiB3cm90ZToNCj4gPj4+IEJyaWFuIENhcnBlbnRlciB3cml0ZXM6DQo+ID4+PiBbLi4u XQ0KPiA+DQo+ID4gSXQgaXMgYSBzdXJwcmlzZSB0byBtZSB0aGF0IFVMQSBhZGRyZXNzZXMgYXJl IG5vdCBieSBkZWZhdWx0IHJvdXRhYmxlIHdpdGhpbg0KPiB0aGUgc2l0ZS4NCj4gPiBJIGNhbiBl YXNpbHkgaW1hZ2luZSBhIG51bWJlciBvZiBMTE4gYm9yZGVyIHJvdXRlcnMgd2hpY2ggYXV0b25v bW91c2x5DQo+ID4gYWxsb2NhdGUgZGlmZmVyZW50IFVMQSBwcmVmaXhlcyBmb3IgdXNlIHdpdGhp biB0aGVpciBpbmRpdmlkdWFsIExMTiBzdWJuZXRzLg0KPiANCj4gSU1ITyB0aGF0IHNob3VsZCBi ZSBhIE5PVCBSRUNPTU1FTkRFRCBiZWhhdmlvdXIuIFVMQXMgbWFrZSBzZW5zZSBpZg0KPiB0aGV5 IGNvdmVyIGFuIGVudGlyZSBlbnRlcnByaXNlIG9yIGhvbWUgbmV0d29yaywgYnV0IG5vdCBpZiB0 aGV5IGNvdmVyIGENCj4gc3Vic2V0Lg0KDQpJIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWUgYXJndW1l bnRzIGZvciB0aGF0IG9waW5pb24/DQoNClRvIG1lIHN1Ym5ldCBVTEFzIG1ha2UgYSBsb3Qgc2Vu c2UgdG8gbWUgaW4gZW52aXJvbm1lbnRzIHdoZXJlDQoxMDAlIGF1dG9jb25maWd1cmF0aW9uIGlz IHJlcXVpcmVkIHdoaWxlIHJlbWFpbmluZyByb2J1c3QgdG93YXJkcw0KY2hhbmdpbmcgSVNQIHBy ZWZpeGVzIGFuZCBiYWNrYm9uZSB0b3BvbG9naWVzLg0KDQpUaGUgYmFzaWMgcHJlbWlzZSBmb3Ig dGhlIGF2ZXJhZ2UgaG9tZW5ldCB1c2VyIGlzIHRoYXQgaGUvc2hlIGhhcw0KYWJzb2x1dGVseSBu byBjbHVlIHdoYXQgZ29lcyBvbiBpbiB0aGUgbmV0d29yay4gQW5kIHNob3VsZCBub3QgaGF2ZS4N CiANCj4gPiBNZWV0aW5nIGEgVUxBIGFkZHJlc3Mgb3V0c2lkZSB0aGUgbG9jYWwgcHJlZml4IHdp bGwgY2F1c2UgdGhlIExMTiBub2RlDQo+ID4gdG8gZm9yd2FyZCBpdHMgSVAgcGFja2V0cyB0byB0 aGUgZGVmYXVsdCBnYXRld2F5IChib3JkZXIgcm91dGVyKSBvZg0KPiA+IHRoZSBMTE4gc3VibmV0 LiBUaGlzIHdheSBwYWNrZXRzIGNhbiB0cmF2ZWwgYmV0d2VlbiBMTE4gc3VibmV0cyB1c2luZw0K PiA+IG5vcm1hbCByb3V0aW5nIHdpdGggbG9uZy10ZXJtIHN0YWJsZSBVTEEgYWRkcmVzc2VzLiBX ZSBuZWVkIHRoZSBzdGFibGUNCj4gYWRkcmVzc2VzIGZvciBjb250cm9sLXN0eWxlIGFwcGxpY2F0 aW9ucyBpbiBMTE5zLg0KPiA+DQo+ID4gT2J2aW91c2x5IGl0IHJlcXVpcmVzIGEgcm91dGluZyBw cm90b2NvbCBpbiB0aGUgKGhvbWVuZXQpIExBTiBidXQgYXJlDQo+IHRoZXJlIG90aGVyIGlzc3Vl cz8NCj4gDQo+IEl0IGRvZXNuJ3QganVzdCByZXF1aXJlIGEgcm91dGluZyBwcm90b2NvbDsgaXQg YWxzbyByZXF1aXJlcyBhIHJvdXRpbmcgcG9saWN5DQo+IHRoYXQga25vd3Mgd2hpY2ggcm91dGVy cyBoYXZlIHRvIGJsb2NrIHRoZSBVTEFzIChwbHVyYWwpLiBUaGF0IHNlZW1zIGEgbG90DQo+IG1v cmUgY29tcGxleCB0aGF0IGEgcnVsZSB0aGF0IHNheXMgb25seSBhIGJvcmRlciByb3V0ZXIgb3Jp Z2luYXRlcyBhbmQNCj4gZGVsZWdhdGVzIGEgVUxBIHByZWZpeCwgYmVjYXVzZSB0aGF0IGJvcmRl ciByb3V0ZXIgd291bGQgYWxzbyBrbm93IHRvIGJsb2NrDQo+IHRoZSBwcmVmaXggYWNyb3NzIHRo ZSBib3JkZXIuDQoNClRoaXMgIm1hc3RlciIgcm91dGVyIG1heSBiZSBhZGRlZCB0byB0aGUgaG9t ZW5ldCBhdCBhIGxhdGVyIHN0YWdlIC0gZS5nLiB3aGVuDQpjaGFuZ2luZyBJU1AuIE15IGxpZ2h0 c3dpdGNoLXRvLWxhbXAgYWRkcmVzcyBhc3NvY2lhdGlvbnMgYmV0d2VlbiB0d28gc3VibmV0cw0K aGF2ZSB0byBzdXJ2aXZlIHN1Y2ggY2hhbmdlcy4NCkkgY2Fubm90IHJlbHkgb24gYW55IHByZWZp eCBkZWxlZ2F0ZWQgZnJvbSBhbiB1bnJlbGlhYmxlIHNvdXJjZSBzdWNoIGFzIGFuIElTUCByb3V0 ZXIuDQoNCkkgY2Fubm90IHJlbHkgb24gbXkgdXNlciBoYW5kLWNhcnJ5aW5nIGEgVUxBIHByZWZp eCBkZWxlZ2F0ZWQgYnkgdGhlIG9sZCBJU1ANCnJvdXRlciBpbnRvIHRoZSBuZXcgSVNQIHJvdXRl ci4gVGhpcyBJU1Agcm91dGVyIG1heSBldmVuIGJlIGJsb2NrZWQgZm9yIHVzZXINCm1hbmlwdWxh dGlvbi4gQW5kIGFnYWluLCBteSB1c2VyIGhhcyBubyBxdWFsaWZpY2F0aW9ucyBmb3IgZG9pbmcg dGhpcy4NCg0KTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgaG9tZW5ldCBDRVIgaXMgdGhhdCBpdCBi eSBkZWZhdWx0IHdpbGwgZmlsdGVyIGFueQ0KVUxBIGFkZHJlc3NlZCB0cmFmZmljICg/KS4gVGh1 cywgbm8gVUxBcyBsZWF2ZSBvciBlbnRlciBpbnRvIHRoZSBJbnRlcm5ldC4NCg0KPiBBbnl3YXkg LSBtYXliZSB5b3Ugc2hvdWxkIGxvb2sgYXQgZHJhZnQtbGl1LXY2b3BzLXVsYS11c2FnZS1hbmFs eXNpcw0KPiBhbmQgZGlzY3VzcyBpdCBvdmVyIG9uIHY2b3BzLg0KDQpJIGFtIGZhbWlsaWFyIHdp dGggQmluZyBMaXUncyBkcmFmdC4gQWN0dWFsbHkgSSBzZWUgbm8gb2JqZWN0aW9ucyBhZ2FpbnN0 DQptdWx0aXBsZSBVTEEgcHJlZml4ZXMgaW4gaG9tZW5ldHMgaW4gdGhpcyBkcmFmdC4NCkNvbnRy YXJ5LCB0aGUgZHJhZnQgc2F5cyANCg0KPHF1b3RlPmhvc3RzIGFzc2lnbmVkIHdpdGggVUxBIG1h eSBvY2Nhc2lvbmFsbHkgYmUgbWVyZ2VkIGludG8gb25lDQogIG5ldHdvcms8L3F1b3RlPi4uLi4N CjxxdW90ZT5tYWtlIG1lcmdpbmcgb2YgbmV0d29ya3Mgc2ltcGxlIGFuZA0KICB3aXRob3V0IHRo ZSBuZWVkIHRvIHJlbnVtYmVyaW5nIG92ZXJsYXBwaW5nIElQIGFkZHJlc3Mgc3BhY2UuIDwvcXVv dGU+DQoNCkkgYWdyZWUgaW4gdGhpcyB0ZXh0Lg0KDQpJIGFncmVlIHRoYXQgdGhlIGRpc2N1c3Np b24gaXMgYWxzbyBpbnRlcmVzdGluZyB0byB2Nm9wcyBidXQgSSB3b3VsZCBsaWtlIHRvDQpjb252 ZXJnZSBvbiB0aGUgYXBwbGljYWJpbGl0eSB3aXRoaW4gaG9tZW5ldHMgYmVmb3JlICJ0YWtpbmcg aXQgdG8gdGhlIG5leHQgbGV2ZWwiLg0KDQpBbmRlcnMNCiANCj4gICAgIEJyaWFuDQo+IA0KPiA+ DQo+ID4gVGhhbmtzLA0KPiA+ICAgQW5kZXJzDQo+ID4+PiBZb3UnbGwgZmluZCB0aGUgYWJvdmUg bG9naWMgaW4gdGhlIGN1cnJlbnQgMzQ4NGJpcyBkcmFmdC4NCj4gPj4+DQo+ID4+PiAtRGF2ZQ0K PiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdCBpcHY2QGlldGYub3JnIEFkbWluaXN0cmF0aXZlDQo+ID4+PiBSZXF1ZXN0czogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ PiBob21lbmV0IG1haWxpbmcgbGlzdA0KPiA+PiBob21lbmV0QGlldGYub3JnDQo+ID4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5ldA0KPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gaG9tZW5ldCBtYWlsaW5n IGxpc3QNCj4gPiBob21lbmV0QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9ob21lbmV0DQo+ID4NCg== From Anders_Brandt@sigmadesigns.com Wed Mar 21 05:19:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5336D21F84CD; Wed, 21 Mar 2012 05:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 muemSxaGI02d; Wed, 21 Mar 2012 05:19:10 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7114321F84B4; Wed, 21 Mar 2012 05:19:10 -0700 (PDT) From: Anders Brandt To: Tim Chown , 6man , "homenet@ietf.org Group" Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: AQHNBF/JLon5l3+WvUuFCR1klHlwqJZy4dkAgADEt4CAAPLVgIAAFlFA Date: Wed, 21 Mar 2012 12:18:36 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC1B91@cph-ex1> References: <4EB3F3D6.4090302@innovationslab.net> <9B57C850BB53634CACEC56EF4853FF653B3C3777@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B3EDB9E@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <4F3ABFBA.8060605@gmail.com> <29EBA88D-BDB1-464C-915F-B9063578DC51@nttv6.net> <9B57C850BB53634CACEC56EF4853FF653B45BB08@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <4F63896E.10607@gmail.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22C2@XMB-RCD-109.cisco.com> <4F64026B.8080308@gmail.com> <9B57C850BB53634CACEC56EF4853FF653B4A639F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <03F31C213F2C6941BFDDBB4336E9E6CD0ABC058C@cph-e! x 1> <4F68F5E5.7060901@gmail.com> <031E46EC-73ED-44A4-B966-B249DCAD367C@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:19:11 -0000 Tim Chown wrote: >Wednesday, March 21, 2012 12:55 > On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: >=20 > > On 2012-03-20 21:51, Anders Brandt wrote: > >> > >> It is a surprise to me that ULA addresses are not by default routable > within the site. > >> I can easily imagine a number of LLN border routers which > >> autonomously allocate different ULA prefixes for use within their > individual LLN subnets. > > > > IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if > > they cover an entire enterprise or home network, but not if they cover = a > subset. > > > >> Meeting a ULA address outside the local prefix will cause the LLN > >> node to forward its IP packets to the default gateway (border router) > >> of the LLN subnet. This way packets can travel between LLN subnets > >> using normal routing with long-term stable ULA addresses. We need the > stable addresses for control-style applications in LLNs. > >> > >> Obviously it requires a routing protocol in the (homenet) LAN but are > there other issues? > > > > It doesn't just require a routing protocol; it also requires a routing > > policy that knows which routers have to block the ULAs (plural). That > > seems a lot more complex that a rule that says only a border router > > originates and delegates a ULA prefix, because that border router > > would also know to block the prefix across the border. >=20 > So we need to determine what the homenet arch text will say on this. >=20 > I think the assumption so far has been that, as per PD8 in draft-ietf- > homenet-arch-02, one router would be elected the "master" to delegate /64 > ULA prefixes within the homenet, both to ULA-only LLNs and to links that > also have a GUA prefix. If there's an assumption an LLN router will not > support that, and instead generate its own /48 ULA, we need to talk about > that, or any other scenario that will lead to multiple /48 ULAs in a sing= le > homenet site. >=20 > The arch text currently says that ULAs should be used (CN1) and that ULAs > should be preferred for internal communications to GUAs (section 2.4). I= t > doesn't say how connections from outside the homenet can be made to > internal ULA-only devices. Is it obvious that you want to do that? I thought the entire ULA discussion was homenet internal only? Access from the outside will require tunneling or an additional global address, I guess? - Anders > The 3484-bis text has changed the default ULA preference to protect again= st > ULA leakage, so if you now want ULAs preferred you need to somehow > inject the specific site /48 ULA being used with high precedence into the > policy table (and as also pointed out here if your site is using less tha= n a /48, > you should also have some way to learn what the site prefix length is). I= n > the homenet case is that injection achieved on receipt of an RA, or would= it > require the proposed DHCPv6 option to be used (which may not be widely > implemented for some time, and the DHCPv6 server still needs to learn the > ULA to put in the option)? >=20 > On the one hand homenet is saying "we'd prefer to use ULAs by default > without needing some magic to achieve it" while 6man is saying "we need > to protect against ULA leakage, so if you want to prefer ULA for internal > connection stability figure out the magic". >=20 > This needs to be mapped to words for the homenet arch text. >=20 > Tim >=20 > > > > Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis > > and discuss it over on v6ops. > > > > Brian > > > >> > >> Thanks, > >> Anders > >>>> You'll find the above logic in the current 3484bis draft. > >>>> > >>>> -Dave > >>>> ------------------------------------------------------------------- > >>>> - IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> ------------------------------------------------------------------- > >>>> - > >>> _______________________________________________ > >>> homenet mailing list > >>> homenet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/homenet > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > >> > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From d.sturek@att.net Wed Mar 21 05:25:13 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5D121F860D for ; Wed, 21 Mar 2012 05:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6] 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 jr4aGn0MLYbc for ; Wed, 21 Mar 2012 05:25:12 -0700 (PDT) Received: from nm4.bullet.mail.ac4.yahoo.com (nm4.bullet.mail.ac4.yahoo.com [98.139.52.201]) by ietfa.amsl.com (Postfix) with SMTP id 3876121F8616 for ; Wed, 21 Mar 2012 05:25:12 -0700 (PDT) Received: from [98.139.52.195] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 21 Mar 2012 12:25:08 -0000 Received: from [209.191.108.96] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 21 Mar 2012 12:25:08 -0000 Received: from [66.94.237.125] by t3.bullet.mud.yahoo.com with NNFMP; 21 Mar 2012 12:25:08 -0000 Received: from [127.0.0.1] by omp1030.access.mail.mud.yahoo.com with NNFMP; 21 Mar 2012 12:25:08 -0000 X-Yahoo-Newman-Id: 168040.62474.bm@omp1030.access.mail.mud.yahoo.com Received: (qmail 35076 invoked from network); 21 Mar 2012 12:25:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1332332708; bh=mjY9BrCMTYTSJpsfwDlbOVVC/JKH0bYL8c3rayzfqxk=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=FeMdTyxF/eK5bVCUXIR3/46PQo+M2/MIBr1mXkjMznoDdnHdiRwTHC11hF88s+GyU7PbKfulAVwWsAhaGIjWbP83L/34i/f57nMe7vEnFuZulMgA89+Vpl6TQw2+rBBgUVWJDNVuBSKrnioFWQ6Yn8SYFF2S87P08ywlvygYru0= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: adGvrmIVM1n2jKNXQTMb6KZywrB8DRd8CRXDuqJbTiwlZjX x_70IDUQUbEJo32BbXaMXk_VHvFpzalwihCImdC3GZmXwgHcBZTT9uCnECIW aLzaJb6149_nxCEGKyXQBaFY3LA00_aCAnXNoF9A3E0xaOya_QTWlK55muLx R6bxPU7xMwBF7C5cuR1tFdub6BQnjFqi8qEeTYtAlkVWQj2WdmMIcFh_SBeB DFyIFN9gEkSKGtA11Oid4.XWAHXo6xNz.2meb2mRYHHs7y5JkpxbMCveJPaz aU8DxISadgsVyNhJ_M3H1P.yBVGWj3X.XJysr0HzajST.2FmWOCi8DMgTJ3N hrm25kbpMRml.G1X2OHX9..fwZLODcBD5UOHH362Q_A1hM1huKzUieyY.MuP TiZjO5XuhGUxukc0OYLBymTQ_M.iDIw1VzPG5 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.0.0.234] (d.sturek@12.201.251.253 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 21 Mar 2012 05:25:07 -0700 PDT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 21 Mar 2012 05:24:55 -0700 From: Don Sturek To: Tim Chown , 6man , "homenet@ietf.org Group" Message-ID: Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 12:25:13 -0000 Hi Tim, One more consideration: In the home, it is possible that multiple independent subnets could be combined, each with their own ULA prefix. This would happen in cases where the homeowner buys multiple silo'ed solutions (like a home automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a cross connect device that integrates these solutions. Don On 3/21/12 4:55 AM, "Tim Chown" wrote: > >On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: > >> On 2012-03-20 21:51, Anders Brandt wrote: >>> >>> It is a surprise to me that ULA addresses are not by default routable >>>within the site. >>> I can easily imagine a number of LLN border routers which autonomously >>>allocate >>> different ULA prefixes for use within their individual LLN subnets. >> >> IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they >> cover an entire enterprise or home network, but not if they cover a >>subset. >> >>> Meeting a ULA address outside the local prefix will cause the LLN node >>>to forward >>> its IP packets to the default gateway (border router) of the LLN >>>subnet. This way >>> packets can travel between LLN subnets using normal routing with >>>long-term stable >>> ULA addresses. We need the stable addresses for control-style >>>applications in LLNs. >>> >>> Obviously it requires a routing protocol in the (homenet) LAN but are >>>there other issues? >> >> It doesn't just require a routing protocol; it also requires a routing >>policy >> that knows which routers have to block the ULAs (plural). That seems a >>lot >> more complex that a rule that says only a border router originates and >>delegates >> a ULA prefix, because that border router would also know to block the >> prefix across the border. > >So we need to determine what the homenet arch text will say on this. > >I think the assumption so far has been that, as per PD8 in >draft-ietf-homenet-arch-02, >one router would be elected the "master" to delegate /64 ULA prefixes >within the >homenet, both to ULA-only LLNs and to links that also have a GUA prefix. >If there's >an assumption an LLN router will not support that, and instead generate >its own /48 >ULA, we need to talk about that, or any other scenario that will lead to >multiple /48 ULAs >in a single homenet site. > >The arch text currently says that ULAs should be used (CN1) and that ULAs >should be >preferred for internal communications to GUAs (section 2.4). It doesn't >say how connections >from outside the homenet can be made to internal ULA-only devices. > >The 3484-bis text has changed the default ULA preference to protect >against ULA leakage, >so if you now want ULAs preferred you need to somehow inject the specific >site /48 ULA >being used with high precedence into the policy table (and as also >pointed out here if your >site is using less than a /48, you should also have some way to learn >what the site prefix >length is). In the homenet case is that injection achieved on receipt of >an RA, or would it >require the proposed DHCPv6 option to be used (which may not be widely >implemented >for some time, and the DHCPv6 server still needs to learn the ULA to put >in the option)? > >On the one hand homenet is saying "we'd prefer to use ULAs by default >without needing >some magic to achieve it" while 6man is saying "we need to protect >against ULA leakage, >so if you want to prefer ULA for internal connection stability figure out >the magic". > >This needs to be mapped to words for the homenet arch text. > >Tim > >> >> Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis >> and discuss it over on v6ops. >> >> Brian >> >>> >>> Thanks, >>> Anders >>>>> You'll find the above logic in the current 3484bis draft. >>>>> >>>>> -Dave >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> ipv6@ietf.org >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From brian.e.carpenter@gmail.com Wed Mar 21 12:21:06 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E723E21F85A0 for ; Wed, 21 Mar 2012 12:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.346 X-Spam-Level: X-Spam-Status: No, score=-103.346 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] 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 7Vemk7ZOQdIG for ; Wed, 21 Mar 2012 12:21:06 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E18D821F858E for ; Wed, 21 Mar 2012 12:20:57 -0700 (PDT) Received: by eeke51 with SMTP id e51so473740eek.31 for ; Wed, 21 Mar 2012 12:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2VvaK2gX8+YUIOUHnZrOIgYqjS+vw5pScfD3TzgzbSU=; b=tWP/ffFBGByNgwgUJPil3ybjDunoAWS8wZwnb/pUIFTcz2ezlMR+FtYeKBevZO1RS+ 5exFLfGhI9EQS2Ue3KD3/j0Egq3LMjsZEDINGtZjcAUo88YDSuESPXcdwmoHSTzQYTBC BVJS3u89vFfrSUzyXVkehPy5CVa5nDYVfZEqRqHtwFyW28NFU6gZiMyyEHTGztc8lOiM bT9yJdB/hEJ1Wu4vS6alKTuXozYdC3cBpTT+0/beA5eW7CVapTOKBsODU1awHBgCjgvz WSpKPdNCtsBbTNLwl+7ZVQA19Q/neASwqkbn8qoBlhhof/vGAg9LkZaNBHn5MVLzbPWj qc7Q== Received: by 10.14.204.3 with SMTP id g3mr702171eeo.75.1332357657029; Wed, 21 Mar 2012 12:20:57 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n56sm9110195eeb.4.2012.03.21.12.20.53 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 12:20:56 -0700 (PDT) Message-ID: <4F6A2A0C.30208@gmail.com> Date: Thu, 22 Mar 2012 08:20:44 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Chown References: <651BA61B-1585-4F8B-84D8-5BCD8397E496@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] I-D Action: draft-gmann-homenet-relay-autoconf-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:21:07 -0000 On 2012-03-22 00:20, Tim Chown wrote: > On 20 Mar 2012, at 23:13, Chris Grundemann wrote: > >> On 3/15/12 1:43 PM, "Brian E Carpenter" >> wrote: >>> It's very likely that many homenets will have two providers >>> (e.g. wireline and wireless) and therefore the issues that MIF is >>> discussing all affect homenet, as far as I can see. >> That's an interesting assertion. My personal read is that if we apply the >> 80/20 rule, it will be the 80% (or more) of residential internet >> subscribers (homenets) who choose not to pay for two providers. > > One of the things to nail down in/by Paris is the level of multihoming support required in the homenet arch text. > > Currently single CER, multiple uplink is required, beyond that multiple CER, multiple uplink support is only "desirable". Realistically, if a random customer ends up with an ADSL box and a 4G device, both capable of operating as a CER, they will both try to connect. If this happens in 20%, 10% or 5% of homes, we're looking at hundreds of millions of instances. It seems more than "desirable" that this works. Brian From brian.e.carpenter@gmail.com Wed Mar 21 12:35:42 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E85721E80A9; Wed, 21 Mar 2012 12:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=-0.502, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 h1zYvnFmpipN; Wed, 21 Mar 2012 12:35:41 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4C44521E8092; Wed, 21 Mar 2012 12:35:41 -0700 (PDT) Received: by eeke51 with SMTP id e51so476723eek.31 for ; Wed, 21 Mar 2012 12:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f3exOZNW9KF5ruyhsYTnE6Y7FVk6+R4WwtbcCrNs35k=; b=GJhH1pPak7Z6LH4vcc8q2eJdXyzPvF7yzakTzs1U9QRYuDAoZop9ZQTusZMcjAVueR pb2E1RwtSZaerPZByV2tQUDrPWshCR3VBSQEh7CjuOaRO2+xxKxj+2OJfdi4/3nYYuuJ 08fKyQgrZHt/QBe7Mbq7GGKjXb96uIKCwz8bEBhOtsjBTXpI2uiTDNUun3OtM24ICi/P E9eEbKOmQPJRKRlnSi4xpud0nkdQfbhwWNFL3eB09Net9q0cdtBPCnX+YfTBkRuFRQwr BDEXroSDUL6LwLoZ59wTamv3qAqawhnxr6WtXTZHLdc68mETtcdC8icD7EayFRnY8tyI wtiA== Received: by 10.14.136.16 with SMTP id v16mr696553eei.126.1332358540487; Wed, 21 Mar 2012 12:35:40 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x8sm9192394eea.10.2012.03.21.12.35.36 (version=SSLv3 cipher=OTHER); Wed, 21 Mar 2012 12:35:39 -0700 (PDT) Message-ID: <4F6A2D7F.1030901@gmail.com> Date: Thu, 22 Mar 2012 08:35:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Tim Chown , 6man , "homenet@ietf.org Group" Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:35:42 -0000 Don, On 2012-03-22 01:24, Don Sturek wrote: > Hi Tim, > > One more consideration: > In the home, it is possible that multiple independent subnets could be > combined, each with their own ULA prefix. This would happen in cases > where the homeowner buys multiple silo'ed solutions (like a home > automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a > cross connect device that integrates these solutions. Yes, anything could happen and probably will. So while a single ULA per site is the simple and obvious case (and I don't have any argument for Anders except KISS), there *will* be cases where several ULAs pop up, and I think resolving routing issues in that situation is likely to be troublesome. We can't resolve it as we do for enterprise networks by saying that the network's manager will manually configure appropriate routes. Brian > Don > > > > > > On 3/21/12 4:55 AM, "Tim Chown" wrote: > >> On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: >> >>> On 2012-03-20 21:51, Anders Brandt wrote: >>>> It is a surprise to me that ULA addresses are not by default routable >>>> within the site. >>>> I can easily imagine a number of LLN border routers which autonomously >>>> allocate >>>> different ULA prefixes for use within their individual LLN subnets. >>> IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they >>> cover an entire enterprise or home network, but not if they cover a >>> subset. >>> >>>> Meeting a ULA address outside the local prefix will cause the LLN node >>>> to forward >>>> its IP packets to the default gateway (border router) of the LLN >>>> subnet. This way >>>> packets can travel between LLN subnets using normal routing with >>>> long-term stable >>>> ULA addresses. We need the stable addresses for control-style >>>> applications in LLNs. >>>> >>>> Obviously it requires a routing protocol in the (homenet) LAN but are >>>> there other issues? >>> It doesn't just require a routing protocol; it also requires a routing >>> policy >>> that knows which routers have to block the ULAs (plural). That seems a >>> lot >>> more complex that a rule that says only a border router originates and >>> delegates >>> a ULA prefix, because that border router would also know to block the >>> prefix across the border. >> So we need to determine what the homenet arch text will say on this. >> >> I think the assumption so far has been that, as per PD8 in >> draft-ietf-homenet-arch-02, >> one router would be elected the "master" to delegate /64 ULA prefixes >> within the >> homenet, both to ULA-only LLNs and to links that also have a GUA prefix. >> If there's >> an assumption an LLN router will not support that, and instead generate >> its own /48 >> ULA, we need to talk about that, or any other scenario that will lead to >> multiple /48 ULAs >> in a single homenet site. >> >> The arch text currently says that ULAs should be used (CN1) and that ULAs >> should be >> preferred for internal communications to GUAs (section 2.4). It doesn't >> say how connections >>from outside the homenet can be made to internal ULA-only devices. >> The 3484-bis text has changed the default ULA preference to protect >> against ULA leakage, >> so if you now want ULAs preferred you need to somehow inject the specific >> site /48 ULA >> being used with high precedence into the policy table (and as also >> pointed out here if your >> site is using less than a /48, you should also have some way to learn >> what the site prefix >> length is). In the homenet case is that injection achieved on receipt of >> an RA, or would it >> require the proposed DHCPv6 option to be used (which may not be widely >> implemented >> for some time, and the DHCPv6 server still needs to learn the ULA to put >> in the option)? >> >> On the one hand homenet is saying "we'd prefer to use ULAs by default >> without needing >> some magic to achieve it" while 6man is saying "we need to protect >> against ULA leakage, >> so if you want to prefer ULA for internal connection stability figure out >> the magic". >> >> This needs to be mapped to words for the homenet arch text. >> >> Tim >> >>> Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis >>> and discuss it over on v6ops. >>> >>> Brian >>> >>>> Thanks, >>>> Anders >>>>>> You'll find the above logic in the current 3484bis draft. >>>>>> >>>>>> -Dave >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>> ipv6@ietf.org >>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>> -------------------------------------------------------------------- >>>>> _______________________________________________ >>>>> homenet mailing list >>>>> homenet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/homenet >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From trac+homenet@trac.tools.ietf.org Wed Mar 21 16:25:00 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C370121E805A for ; Wed, 21 Mar 2012 16:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 R3p9+SKry3tz for ; Wed, 21 Mar 2012 16:25:00 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4557521E801A for ; Wed, 21 Mar 2012 16:24:59 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SAUtK-0007pT-Kx; Wed, 21 Mar 2012 19:24:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "homenet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk X-Trac-Project: homenet Date: Wed, 21 Mar 2012 23:24:30 -0000 X-URL: http://tools.ietf.org/homenet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/homenet/trac/ticket/1 Message-ID: <061.6a445747e247b219642216b1fa46f68c@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk, homenet@ietf.org X-SA-Exim-Mail-From: trac+homenet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120321232500.4557521E801A@ietfa.amsl.com> Resent-Date: Wed, 21 Mar 2012 16:24:59 -0700 (PDT) Resent-From: trac+homenet@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 21 Mar 2012 16:27:08 -0700 Cc: homenet@ietf.org Subject: [homenet] #1: Multihoming support X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:25:00 -0000 #1: Multihoming support Currently the -02 arch text talks about multihoming in MH2, MH7, MH8, RT11 and RT12. We say that single CER, multiple uplink multihoming is supported, but multi-CER, multiple uplink multihoming is only desirable. Do we want to make the latter a requirement as well, or "strongly desirable"? -- -------------------+--------------------------------------- Reporter: tjc@… | Owner: draft-ietf-homenet-arch@… Type: task | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: -------------------+--------------------------------------- Ticket URL: homenet From trac+homenet@trac.tools.ietf.org Wed Mar 21 16:26:33 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC49D21E8098 for ; Wed, 21 Mar 2012 16:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 OdDZVrdonW+d for ; Wed, 21 Mar 2012 16:26:33 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6F60621E805A for ; Wed, 21 Mar 2012 16:26:33 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SAUvE-00055p-VG; Wed, 21 Mar 2012 19:26:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "homenet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk X-Trac-Project: homenet Date: Wed, 21 Mar 2012 23:26:28 -0000 X-URL: http://tools.ietf.org/homenet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/homenet/trac/ticket/2 Message-ID: <061.0df9252fb8a222d2b56d520dc0b2c598@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk, homenet@ietf.org X-SA-Exim-Mail-From: trac+homenet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120321232633.6F60621E805A@ietfa.amsl.com> Resent-Date: Wed, 21 Mar 2012 16:26:33 -0700 (PDT) Resent-From: trac+homenet@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 21 Mar 2012 16:27:08 -0700 Cc: homenet@ietf.org Subject: [homenet] #2: Operations and management support X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:26:34 -0000 #2: Operations and management support Do we keep operations and management out of scope, or is user-oriented service monitoring required, or the ability for an ISP or 3rd party to manage the homenet for the user required? The default position should be a working network with no user intervention. This could be a sixth area to add to the existing five. -- -------------------+--------------------------------------- Reporter: tjc@… | Owner: draft-ietf-homenet-arch@… Type: task | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: -------------------+--------------------------------------- Ticket URL: homenet From trac+homenet@trac.tools.ietf.org Wed Mar 21 16:30:28 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907A821E80AB for ; Wed, 21 Mar 2012 16:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 SatZQoFGr9Vy for ; Wed, 21 Mar 2012 16:30:28 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1302821E8092 for ; Wed, 21 Mar 2012 16:30:28 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SAUz2-0007Nq-9x; Wed, 21 Mar 2012 19:30:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "homenet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk X-Trac-Project: homenet Date: Wed, 21 Mar 2012 23:30:24 -0000 X-URL: http://tools.ietf.org/homenet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/homenet/trac/ticket/3 Message-ID: <061.fcef3f73826409c11b00747c7350ae3e@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk, homenet@ietf.org X-SA-Exim-Mail-From: trac+homenet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120321233028.1302821E8092@ietfa.amsl.com> Resent-Date: Wed, 21 Mar 2012 16:30:28 -0700 (PDT) Resent-From: trac+homenet@trac.tools.ietf.org Cc: homenet@ietf.org Subject: [homenet] #3: Use of "Simple security" X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:30:28 -0000 #3: Use of "Simple security" As per EE2 and EE3 in the -02 text, do we keep "Simple Security" as the default, with an associated requirement for a signalling protocol (e.g. PCP or UPnP IGD v2), and an option for a user to select a "transparent mode", or should we take a position like RFC6204 which says: "S-1: The IPv6 CE router SHOULD support [RFC6092]. In particular, the IPv6 CE router SHOULD support functionality sufficient for implementing the set of recommendations in [RFC6092], Section 4. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure it." -- -------------------+--------------------------------------- Reporter: tjc@… | Owner: draft-ietf-homenet-arch@… Type: task | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: -------------------+--------------------------------------- Ticket URL: homenet From trac+homenet@trac.tools.ietf.org Wed Mar 21 16:33:12 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3151021E80A2 for ; Wed, 21 Mar 2012 16:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 bi7H2peIRdM9 for ; Wed, 21 Mar 2012 16:33:11 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD8D21E8101 for ; Wed, 21 Mar 2012 16:33:10 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SAV1Y-0000Ce-2T; Wed, 21 Mar 2012 19:33:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "homenet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk X-Trac-Project: homenet Date: Wed, 21 Mar 2012 23:33:00 -0000 X-URL: http://tools.ietf.org/homenet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/homenet/trac/ticket/4 Message-ID: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk, homenet@ietf.org X-SA-Exim-Mail-From: trac+homenet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120321233310.5DD8D21E8101@ietfa.amsl.com> Resent-Date: Wed, 21 Mar 2012 16:33:10 -0700 (PDT) Resent-From: trac+homenet@trac.tools.ietf.org Cc: homenet@ietf.org Subject: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:33:12 -0000 #4: Use of ULAs CN1 in the -02 text says ULAs should be provisioned by default. Do we agree? And if so, should they be preferred over globals? The new 3484-bis has changed so they are not *unless* a specific /48 for the site is added to the 3484 policy table with higher precedence than globals. We should design something that works when disconnected from the Internet. Also, we currently say nothing about ULA-only devices and their reachability from outside the homenet; do we want to? -- -------------------+--------------------------------------- Reporter: tjc@… | Owner: draft-ietf-homenet-arch@… Type: task | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: -------------------+--------------------------------------- Ticket URL: homenet From trac+homenet@trac.tools.ietf.org Wed Mar 21 16:36:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D41421E812C for ; Wed, 21 Mar 2012 16:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 U+54ypUcTW50 for ; Wed, 21 Mar 2012 16:36:16 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1D46F21E8121 for ; Wed, 21 Mar 2012 16:36:15 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SAV4X-0007Aj-5R; Wed, 21 Mar 2012 19:36:05 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "homenet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk X-Trac-Project: homenet Date: Wed, 21 Mar 2012 23:36:05 -0000 X-URL: http://tools.ietf.org/homenet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/homenet/trac/ticket/5 Message-ID: <061.291a707258a462ecf19477dc3364e5c2@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk, homenet@ietf.org X-SA-Exim-Mail-From: trac+homenet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120321233616.1D46F21E8121@ietfa.amsl.com> Resent-Date: Wed, 21 Mar 2012 16:36:15 -0700 (PDT) Resent-From: trac+homenet@trac.tools.ietf.org Cc: homenet@ietf.org Subject: [homenet] #5: Support for "flash" renumbering X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:36:16 -0000 #5: Support for "flash" renumbering In PD13 and AD3 we say that flash renumbering should be supported. This is due to many ISPs saying they may provision prefixes to residential networks that may change over time. What exactly should we say about what we mean by the minimum support for such renumbering? This topic is linked to the ULA use topic. -- -------------------+--------------------------------------- Reporter: tjc@… | Owner: draft-ietf-homenet-arch@… Type: task | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: -------------------+--------------------------------------- Ticket URL: homenet From trac+homenet@trac.tools.ietf.org Wed Mar 21 16:37:29 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7BD21E812F for ; Wed, 21 Mar 2012 16:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 sLR-fXi1ajic for ; Wed, 21 Mar 2012 16:37:29 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5156721E80ED for ; Wed, 21 Mar 2012 16:37:29 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SAV5q-0002E7-PL; Wed, 21 Mar 2012 19:37:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "homenet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk X-Trac-Project: homenet Date: Wed, 21 Mar 2012 23:37:26 -0000 X-URL: http://tools.ietf.org/homenet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/homenet/trac/ticket/6 Message-ID: <061.90de23b8a14a673d9c6b0086ae165167@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk, homenet@ietf.org X-SA-Exim-Mail-From: trac+homenet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120321233729.5156721E80ED@ietfa.amsl.com> Resent-Date: Wed, 21 Mar 2012 16:37:29 -0700 (PDT) Resent-From: trac+homenet@trac.tools.ietf.org Cc: homenet@ietf.org Subject: [homenet] #6: Support for arbitrary topologies X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:37:29 -0000 #6: Support for arbitrary topologies We currently state that homenets should support arbitrary topologies (SD1). There have been some comments that this might not be realistic. Should we continue to shoot for that? -- -------------------+--------------------------------------- Reporter: tjc@… | Owner: draft-ietf-homenet-arch@… Type: task | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: -------------------+--------------------------------------- Ticket URL: homenet From trac+homenet@trac.tools.ietf.org Wed Mar 21 16:39:58 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4941E21F85C4 for ; Wed, 21 Mar 2012 16:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 xUCyTTXPUqf0 for ; Wed, 21 Mar 2012 16:39:57 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id BFD5E21F85C0 for ; Wed, 21 Mar 2012 16:39:57 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SAV8E-00089Y-6F; Wed, 21 Mar 2012 19:39:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "homenet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk X-Trac-Project: homenet Date: Wed, 21 Mar 2012 23:39:54 -0000 X-URL: http://tools.ietf.org/homenet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/homenet/trac/ticket/7 Message-ID: <061.025e3d5199941f4bf1b75228b143cd51@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk, homenet@ietf.org X-SA-Exim-Mail-From: trac+homenet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120321233957.BFD5E21F85C0@ietfa.amsl.com> Resent-Date: Wed, 21 Mar 2012 16:39:57 -0700 (PDT) Resent-From: trac+homenet@trac.tools.ietf.org Cc: homenet@ietf.org Subject: [homenet] #7: Defining home, guest and internet realms/borders X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:39:58 -0000 #7: Defining home, guest and internet realms/borders Consider two routers fully within a homenet Now, list all the types of traffic and information that might be exchanged between those routers, e.g., - Datalink establishment - IP addressing for the link - IP Prefixes reachable by the router (what a "routing protocol" would do) - Services present on the router itself - Services on connected links propagated via the router - User traffic - etc... Our job is to determine what kind of link exists between two routers and start crossing out items, in whole or in part, based on how promiscuous we wish the routers to be on that link. In effect, we are deciding where to break the network and where not to, but it is by doing this that we carve out the separate "home", "guest" and "Internet" realms that we are targeting to create. I think that what is most important at this moment is to nail down what knobs we want to try and have available, what their "out of the box" defaults are for the above 3 combinations of border types, and allow for super-users, ISP-managed devices, etc. monkey around with them as they wish according to what vendors and providers can dream up. If we can agree on these, and still remain blocked on what kind of firewall to recommend to be enabled by default, we will still have accomplished quite a bit. What do we wish to say about such borders/realms? -- -------------------+--------------------------------------- Reporter: tjc@… | Owner: draft-ietf-homenet-arch@… Type: task | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: -------------------+--------------------------------------- Ticket URL: homenet From trac+homenet@trac.tools.ietf.org Wed Mar 21 16:42:43 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F277821E8142 for ; Wed, 21 Mar 2012 16:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 wqwWGDBkZ2SD for ; Wed, 21 Mar 2012 16:42:42 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 773F021E80ED for ; Wed, 21 Mar 2012 16:42:42 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SAVAp-0002wJ-VH; Wed, 21 Mar 2012 19:42:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "homenet issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk X-Trac-Project: homenet Date: Wed, 21 Mar 2012 23:42:35 -0000 X-URL: http://tools.ietf.org/homenet/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/homenet/trac/ticket/8 Message-ID: <061.0f56e01bdeae967db6e91124c7a45ce1@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-homenet-arch@tools.ietf.org, tjc@ecs.soton.ac.uk, homenet@ietf.org X-SA-Exim-Mail-From: trac+homenet@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120321234242.773F021E80ED@ietfa.amsl.com> Resent-Date: Wed, 21 Mar 2012 16:42:42 -0700 (PDT) Resent-From: trac+homenet@trac.tools.ietf.org Cc: homenet@ietf.org Subject: [homenet] #8: Proxy or extend? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:42:43 -0000 #8: Proxy or extend? Do we wish to state a preference for how protocols that currently work within a single subnet can be made to work within a multi-subnet homenet site? Proxies could be defined at subnet boundaries (e.g. as per DHCPv6 relays) or protocols could be extended to site scope (e.g. the recent xmDNS proposal). Or is this a per-protocol decision? -- -------------------+--------------------------------------- Reporter: tjc@… | Owner: draft-ietf-homenet-arch@… Type: task | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: -------------------+--------------------------------------- Ticket URL: homenet From tjc@ecs.soton.ac.uk Wed Mar 21 16:47:23 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB42D21E80BA for ; Wed, 21 Mar 2012 16:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] 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 Azw5zVRmfURf for ; Wed, 21 Mar 2012 16:47:23 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 2296E21E8024 for ; Wed, 21 Mar 2012 16:47:22 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2LNlGgh013290 for ; Wed, 21 Mar 2012 23:47:16 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2LNlGgh013290 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1332373636; bh=E5UQyoEsq4W3hEnbVoNi5WTU9yI=; h=From:Subject:Date:To:Mime-Version:References; b=ZnMicx77WLnDD9sUctctU/WYqfxMsgJmVfwNoDO6boNjizLWgb+18Q9Uu6tLm4Gm4 edzzZiGBuxHSHVJUBpGX0nD5AgSU9ySHHVAQlcrUPOeHsDMiYFOvDoDgcie0yCYwYo Iwo+2rLnZxDXjggo2GJ2wFivdWACj1/Z4Om7T1SE= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o2KNlG0543746391qq ret-id none; Wed, 21 Mar 2012 23:47:16 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2LNjv2R007149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 21 Mar 2012 23:45:58 GMT From: Tim Chown Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Mar 2012 23:45:57 +0000 Message-ID: To: "homenet@ietf.org Group" Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2KNlG054374639100; tid=o2KNlG0543746391qq; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2LNlGgh013290 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [homenet] Issue tracker X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 23:47:24 -0000 Hi, The chairs have suggested using the issue tracker for the architecture = text. These should appear to the list soon. We can split out additional issues with the tracker as they're = identified. The naming and service discovery areas are still in their = relative infancy. Please feel free to comment on the tracker topics so we can see if we = have consensus forming prior to the Paris session. Tim= From v6ops@globis.net Thu Mar 22 01:29:32 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910F121F8613; Thu, 22 Mar 2012 01:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[AWL=-2.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_42=0.6, MANGLED_PAIN=2.3] 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 2B3mtXNr6kxn; Thu, 22 Mar 2012 01:29:31 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6A90221F8604; Thu, 22 Mar 2012 01:29:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 226428700EA; Thu, 22 Mar 2012 09:29:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yROnIobVxZ3; Thu, 22 Mar 2012 09:29:16 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 2068C8700E7; Thu, 22 Mar 2012 09:29:16 +0100 (CET) Message-ID: <4F6AE2DB.2000007@globis.net> Date: Thu, 22 Mar 2012 09:29:15 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Brian E Carpenter References: <4F6A2D7F.1030901@gmail.com> In-Reply-To: <4F6A2D7F.1030901@gmail.com> Content-Type: multipart/alternative; boundary="------------070607050602030603040503" Cc: 6man , Tim Chown , Don Sturek , "homenet@ietf.org Group" Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 08:29:32 -0000 This is a multi-part message in MIME format. --------------070607050602030603040503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 Firstly, I have been lurking on the 3484-revise discussion in 6man for a long time. I agree with Brian's proposal: [source & destination of a /48 ULA prefix match => prefer over 2000:/3 space. Otherwise don't (by default).] Secondly, I think Homenet still has a lot of work to do, especially due to the autoconfig requirements. Everyone wants autoconfig. Concurrent ULA + PA + both with autoconfig + invariant addresses is likely going to be tough, if not downright impossible. So why do we think we really need concurrent ULA+PA in Homenet as a base requirement? I'm not entirely convinced yet. One reason ULA seems to be mentioned is "time-invariance of addressing for use by sensor networks." I don't see how "complete time-invariance of addressing" is achievable together with autoconfig, even if we call for an equivalent site-local addressing with a fixed /48 prefix that is common to all Homenet implementations everywhere. We've been down that rathole before. Site-local has been deprecated in RFC3879. And realistically speaking, any time someone replaces or adds or re-plugs any router hardware, the LAN's /64 prefix will change when using autoconfig. I think it would be useful for the Homenet WG to propose a scheme for sensor networks to be able to maintain simple peerings despite the presence of time-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. In fact, it would seem to me that a peering solution should use something that is long-term invariant as an identifier for keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at all. The invariant identifier could be automatically registered by each sensor as a name in the Homenet naming service. Peers could resolve that name to the current IPv6 address and then verify the peering using their own protocol like HMAC_MD5 with a shared secret (RFC2104). Loss of connection would trigger a new address resolution, reconnection, and peer check. Agreeing the shared secret is peering specific (and has to be solved anyway even with fixed addresses). I have an asterisk hardware phone that does something similar to this, so it can't require much code. A reason concurrent ULA+PA seems to be required was that "intra-homenet communication should survive a long term ISP outage, and must be able to be established without any ISP connection present." The first linkage would appear to be when ISP PA-derived prefixes within Homenet timeout via DHCPv6 PD meaning that a long-running session based on this address would drop. That has nothing directly to do with ULA, and may have other solutions. Question: How long are ISP's setting their DHCPv6 PD timers in practice? Simply recommending very long timers for the DHCPv6 PD PA-derived prefix might be a practical solution. How often has your ISP connection been down for say 10 days? Another solution might be for the application to reconnect using another PA-derived address (if the user has two providers). The second linkage may also have other solutions, such as only configuring a ULA prefix when no PA-derived prefixes are present. That would mean at any one time the Homenet could potentially be running either ULA or multiple PA, but not both, which completely avoids any address selection conflicts and having to redistribute new RFC3484 address selection rules to all nodes. Simply put: "Please reboot or reconnect to fix any problems." So I humbly suggest the WG should first concentrate on properly formulating and clarifying the high level architectural requirements, rather than on ULA in and of itself. regards, RayH Brian E Carpenter wrote: > Don, > > On 2012-03-22 01:24, Don Sturek wrote: > >> Hi Tim, >> >> One more consideration: >> In the home, it is possible that multiple independent subnets could be >> combined, each with their own ULA prefix. This would happen in cases >> where the homeowner buys multiple silo'ed solutions (like a home >> automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a >> cross connect device that integrates these solutions. >> > > Yes, anything could happen and probably will. So while a single ULA per > site is the simple and obvious case (and I don't have any argument for > Anders except KISS), there *will* be cases where several ULAs pop > up, and I think resolving routing issues in that situation is likely > to be troublesome. We can't resolve it as we do for enterprise networks > by saying that the network's manager will manually configure appropriate > routes. > > Brian > > >> Don >> >> >> >> >> >> On 3/21/12 4:55 AM, "Tim Chown" wrote: >> >> >>> On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: >>> >>> >>>> On 2012-03-20 21:51, Anders Brandt wrote: >>>> >>>>> It is a surprise to me that ULA addresses are not by default routable >>>>> within the site. >>>>> I can easily imagine a number of LLN border routers which autonomously >>>>> allocate >>>>> different ULA prefixes for use within their individual LLN subnets. >>>>> >>>> IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they >>>> cover an entire enterprise or home network, but not if they cover a >>>> subset. >>>> >>>> >>>>> Meeting a ULA address outside the local prefix will cause the LLN node >>>>> to forward >>>>> its IP packets to the default gateway (border router) of the LLN >>>>> subnet. This way >>>>> packets can travel between LLN subnets using normal routing with >>>>> long-term stable >>>>> ULA addresses. We need the stable addresses for control-style >>>>> applications in LLNs. >>>>> >>>>> Obviously it requires a routing protocol in the (homenet) LAN but are >>>>> there other issues? >>>>> >>>> It doesn't just require a routing protocol; it also requires a routing >>>> policy >>>> that knows which routers have to block the ULAs (plural). That seems a >>>> lot >>>> more complex that a rule that says only a border router originates and >>>> delegates >>>> a ULA prefix, because that border router would also know to block the >>>> prefix across the border. >>>> >>> So we need to determine what the homenet arch text will say on this. >>> >>> I think the assumption so far has been that, as per PD8 in >>> draft-ietf-homenet-arch-02, >>> one router would be elected the "master" to delegate /64 ULA prefixes >>> within the >>> homenet, both to ULA-only LLNs and to links that also have a GUA prefix. >>> If there's >>> an assumption an LLN router will not support that, and instead generate >>> its own /48 >>> ULA, we need to talk about that, or any other scenario that will lead to >>> multiple /48 ULAs >>> in a single homenet site. >>> >>> The arch text currently says that ULAs should be used (CN1) and that ULAs >>> should be >>> preferred for internal communications to GUAs (section 2.4). It doesn't >>> say how connections >>> >> >from outside the homenet can be made to internal ULA-only devices. >> >>> The 3484-bis text has changed the default ULA preference to protect >>> against ULA leakage, >>> so if you now want ULAs preferred you need to somehow inject the specific >>> site /48 ULA >>> being used with high precedence into the policy table (and as also >>> pointed out here if your >>> site is using less than a /48, you should also have some way to learn >>> what the site prefix >>> length is). In the homenet case is that injection achieved on receipt of >>> an RA, or would it >>> require the proposed DHCPv6 option to be used (which may not be widely >>> implemented >>> for some time, and the DHCPv6 server still needs to learn the ULA to put >>> in the option)? >>> >>> On the one hand homenet is saying "we'd prefer to use ULAs by default >>> without needing >>> some magic to achieve it" while 6man is saying "we need to protect >>> against ULA leakage, >>> so if you want to prefer ULA for internal connection stability figure out >>> the magic". >>> >>> This needs to be mapped to words for the homenet arch text. >>> >>> Tim >>> >>> >>>> Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis >>>> and discuss it over on v6ops. >>>> >>>> Brian >>>> >>>> >>>>> Thanks, >>>>> Anders >>>>> >>>>>>> You'll find the above logic in the current 3484bis draft. >>>>>>> >>>>>>> -Dave >>>>>>> -------------------------------------------------------------------- >>>>>>> IETF IPv6 working group mailing list >>>>>>> ipv6@ietf.org >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> -------------------------------------------------------------------- >>>>>>> >>>>>> _______________________________________________ >>>>>> homenet mailing list >>>>>> homenet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/homenet >>>>>> >>>>> _______________________________________________ >>>>> homenet mailing list >>>>> homenet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/homenet >>>>> >>>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > > --------------070607050602030603040503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

Firstly, I have been lurking on the 3484-revise discussion in 6man for a long time. I agree with Brian's proposal:
[source & destination of a /48 ULA prefix match => prefer over 2000:/3 space. Otherwise don't (by default).]



Secondly, I think Homenet still has a lot of work to do, especially due to the autoconfig requirements.
Everyone wants autoconfig. Concurrent ULA + PA + both with autoconfig + invariant addresses is likely going to be tough, if not downright impossible.

So why do we think we really need concurrent ULA+PA in Homenet as a base requirement? I'm not entirely convinced yet.

One reason ULA seems to be mentioned is "time-invariance of addressing for use by sensor networks." I don't see how "complete time-invariance of addressing"  is achievable together with autoconfig, even if we call for an equivalent site-local addressing with a fixed /48 prefix that is common to all Homenet implementations everywhere. We've been down that rathole before. Site-local has been deprecated in RFC3879. And realistically speaking, any time someone replaces or adds or re-plugs any router hardware, the LAN's /64 prefix will change when using autoconfig.

I think it would be useful for the Homenet WG to propose a scheme for sensor networks to be able to maintain simple peerings despite the presence of time-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. In fact, it would seem to me that a peering solution should use something that is long-term invariant as an identifier for keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at all. The invariant identifier could be automatically registered by each sensor as a name in the Homenet naming service. Peers could resolve that name to the current IPv6 address and then verify the peering using their own protocol like HMAC_MD5 with a shared secret (RFC2104). Loss of connection would trigger a new address resolution, reconnection, and peer check. Agreeing the shared secret is peering specific (and has to be solved anyway even with fixed addresses). I have an asterisk hardware phone that does something similar to this, so it can't require much code.


A reason concurrent ULA+PA seems to be required was that "intra-homenet communication should survive a long term ISP outage, and must be able to be established without any ISP connection present."

The first linkage would appear to be when ISP PA-derived prefixes within Homenet timeout via DHCPv6 PD meaning that a long-running session based on this address would drop. That has nothing directly to do with ULA, and may have other solutions.

Question: How long are ISP's setting their DHCPv6 PD timers in practice? Simply recommending very long timers for the DHCPv6 PD PA-derived prefix might be a practical solution. How often has your ISP connection been down for say 10 days?

Another solution might be for the application to reconnect using another PA-derived address (if the user has two providers).


The second linkage may also have other solutions, such as only configuring a ULA prefix when no PA-derived prefixes are present.

That would mean at any one time the Homenet could potentially be running either ULA or multiple PA, but not both, which completely avoids any address selection conflicts and having to redistribute new RFC3484 address selection rules to all nodes. Simply put: "Please reboot or reconnect to fix any problems."

So I humbly suggest the WG should first concentrate on properly formulating and clarifying the high level architectural requirements, rather than on ULA in and of itself.

regards,
RayH


Brian E Carpenter wrote: 

Don,

On 2012-03-22 01:24, Don Sturek wrote:
  
Hi Tim,

One more consideration:
In the home, it is possible that multiple independent subnets could be
combined, each with their own ULA prefix.  This would happen in cases
where the homeowner buys multiple silo'ed solutions (like a home
automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a
cross connect device that integrates these solutions.
    

Yes, anything could happen and probably will. So while a single ULA per
site is the simple and obvious case (and I don't have any argument for
Anders except KISS), there *will* be cases where several ULAs pop
up, and I think resolving routing issues in that situation is likely
to be troublesome. We can't resolve it as we do for enterprise networks
by saying that the network's manager will manually configure appropriate
routes.

    Brian

  
Don





On 3/21/12 4:55 AM, "Tim Chown" <tjc@ecs.soton.ac.uk> wrote:

    
On 20 Mar 2012, at 21:25, Brian E Carpenter wrote:

      
On 2012-03-20 21:51, Anders Brandt wrote:
        
It is a surprise to me that ULA addresses are not by default routable
within the site.
I can easily imagine a number of LLN border routers which autonomously
allocate
different ULA prefixes for use within their individual LLN subnets.
          
IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they
cover an entire enterprise or home network, but not if they cover a
subset.

        
Meeting a ULA address outside the local prefix will cause the LLN node
to forward
its IP packets to the default gateway (border router) of the LLN
subnet. This way
packets can travel between LLN subnets using normal routing with
long-term stable
ULA addresses. We need the stable addresses for control-style
applications in LLNs.

Obviously it requires a routing protocol in the (homenet) LAN but are
there other issues?
          
It doesn't just require a routing protocol; it also requires a routing
policy
that knows which routers have to block the ULAs (plural). That seems a
lot
more complex that a rule that says only a border router originates and
delegates
a ULA prefix, because that border router would also know to block the
prefix across the border.
        
So we need to determine what the homenet arch text will say on this.

I think the assumption so far has been that, as per PD8 in
draft-ietf-homenet-arch-02,
one router would be elected the "master" to delegate /64 ULA prefixes
within the
homenet, both to ULA-only LLNs and to links that also have a GUA prefix.
If there's 
an assumption an LLN router will not support that, and instead generate
its own /48 
ULA, we need to talk about that, or any other scenario that will lead to
multiple /48 ULAs 
in a single homenet site.

The arch text currently says that ULAs should be used (CN1) and that ULAs
should be 
preferred for internal communications to GUAs (section 2.4).  It doesn't
say how connections
      
>from outside the homenet can be made to internal ULA-only devices.
    
The 3484-bis text has changed the default ULA preference to protect
against ULA leakage,
so if you now want ULAs preferred you need to somehow inject the specific
site /48 ULA
being used with high precedence into the policy table (and as also
pointed out here if your
site is using less than a /48, you should also have some way to learn
what the site prefix
length is). In the homenet case is that injection achieved on receipt of
an RA, or would it
require the proposed DHCPv6 option to be used (which may not be widely
implemented 
for some time, and the DHCPv6 server still needs to learn the ULA to put
in the option)? 

On the one hand homenet is saying "we'd prefer to use ULAs by default
without needing
some magic to achieve it" while 6man is saying "we need to protect
against ULA leakage,
so if you want to prefer ULA for internal connection stability figure out
the magic".  

This needs to be mapped to words for the homenet arch text.

Tim

      
Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis
and discuss it over on v6ops.

   Brian

        
Thanks,
 Anders
          
You'll find the above logic in the current 3484bis draft.

-Dave
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
              
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
            
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

          
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
        
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
      
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------070607050602030603040503-- From Anders_Brandt@sigmadesigns.com Thu Mar 22 02:07:16 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BCF21F85EF; Thu, 22 Mar 2012 02:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-1.850, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_42=0.6, MANGLED_PAIN=2.3] 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 KXQP2oz-no5g; Thu, 22 Mar 2012 02:07:14 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 20B6221F85BD; Thu, 22 Mar 2012 02:07:08 -0700 (PDT) From: Anders Brandt To: Ray Hunter , Brian E Carpenter Thread-Topic: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] Thread-Index: AQHNBF/JLon5l3+WvUuFCR1klHlwqJZy4dkAgADEt4CAAPLVgIAACFaAgAB4SoCAANgzgIAAGDFg Date: Thu, 22 Mar 2012 09:06:22 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC2053@cph-ex1> References: <4F6A2D7F.1030901@gmail.com> <4F6AE2DB.2000007@globis.net> In-Reply-To: <4F6AE2DB.2000007@globis.net> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.120] Content-Type: multipart/alternative; boundary="_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC2053cphex1_" MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com Cc: Don Sturek , Tim Chown , 6man , "homenet@ietf.org Group" Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 09:07:16 -0000 --_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC2053cphex1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, > So I humbly suggest the WG should first concentrate on properly formulati= ng and clarifying the high level architectural requirements, > rather than on ULA in and of itself. I agree that we must concentrate on the architecture requirements first. It would however be unfortunate if these requirements ruled out the case of= routing between homenet subnets based on stable addresses when we have a couple of use cases for LLNs that call such functionality. Maybe I should provide some use cases to Bing's draft to outline why this m= atters to us LLN guys. I think I need some education on ULA routing - starting new thread... - Anders From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Ray Hunter Sent: Thursday, March 22, 2012 09:29 To: Brian E Carpenter Cc: 6man; Tim Chown; Don Sturek; homenet@ietf.org Group Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.txt] +1 Firstly, I have been lurking on the 3484-revise discussion in 6man for a lo= ng time. I agree with Brian's proposal: [source & destination of a /48 ULA prefix match =3D> prefer over 2000:/3 sp= ace. Otherwise don't (by default).] Secondly, I think Homenet still has a lot of work to do, especially due to = the autoconfig requirements. Everyone wants autoconfig. Concurrent ULA + PA + both with autoconfig + inv= ariant addresses is likely going to be tough, if not downright impossible. So why do we think we really need concurrent ULA+PA in Homenet as a base re= quirement? I'm not entirely convinced yet. One reason ULA seems to be mentioned is "time-invariance of addressing for = use by sensor networks." I don't see how "complete time-invariance of addre= ssing" is achievable together with autoconfig, even if we call for an equi= valent site-local addressing with a fixed /48 prefix that is common to all = Homenet implementations everywhere. We've been down that rathole before. Si= te-local has been deprecated in RFC3879. And realistically speaking, any ti= me someone replaces or adds or re-plugs any router hardware, the LAN's /64 = prefix will change when using autoconfig. I think it would be useful for the Homenet WG to propose a scheme for senso= r networks to be able to maintain simple peerings despite the presence of t= ime-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. I= n fact, it would seem to me that a peering solution should use something th= at is long-term invariant as an identifier for keying the peering e.g. EUI-= 64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at all. The invari= ant identifier could be automatically registered by each sensor as a name i= n the Homenet naming service. Peers could resolve that name to the current = IPv6 address and then verify the peering using their own protocol like HMAC= _MD5 with a shared secret (RFC2104). Loss of connection would trigger a new= address resolution, reconnection, and peer check. Agreeing the shared secr= et is peering specific (and has to be solved anyway even with fixed address= es). I have an asterisk hardware phone that does something similar to this,= so it can't require much code. A reason concurrent ULA+PA seems to be required was that "intra-homenet com= munication should survive a long term ISP outage, and must be able to be es= tablished without any ISP connection present." The first linkage would appear to be when ISP PA-derived prefixes within Ho= menet timeout via DHCPv6 PD meaning that a long-running session based on th= is address would drop. That has nothing directly to do with ULA, and may ha= ve other solutions. Question: How long are ISP's setting their DHCPv6 PD timers in practice? Si= mply recommending very long timers for the DHCPv6 PD PA-derived prefix migh= t be a practical solution. How often has your ISP connection been down for = say 10 days? Another solution might be for the application to reconnect using another PA= -derived address (if the user has two providers). The second linkage may also have other solutions, such as only configuring = a ULA prefix when no PA-derived prefixes are present. That would mean at any one time the Homenet could potentially be running ei= ther ULA or multiple PA, but not both, which completely avoids any address = selection conflicts and having to redistribute new RFC3484 address selectio= n rules to all nodes. Simply put: "Please reboot or reconnect to fix any pr= oblems." So I humbly suggest the WG should first concentrate on properly formulating= and clarifying the high level architectural requirements, rather than on U= LA in and of itself. regards, RayH Brian E Carpenter wrote: Don, On 2012-03-22 01:24, Don Sturek wrote: Hi Tim, One more consideration: In the home, it is possible that multiple independent subnets could be combined, each with their own ULA prefix. This would happen in cases where the homeowner buys multiple silo'ed solutions (like a home automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchases a cross connect device that integrates these solutions. Yes, anything could happen and probably will. So while a single ULA per site is the simple and obvious case (and I don't have any argument for Anders except KISS), there *will* be cases where several ULAs pop up, and I think resolving routing issues in that situation is likely to be troublesome. We can't resolve it as we do for enterprise networks by saying that the network's manager will manually configure appropriate routes. Brian Don On 3/21/12 4:55 AM, "Tim Chown" wrote: On 20 Mar 2012, at 21:25, Brian E Carpenter wrote: On 2012-03-20 21:51, Anders Brandt wrote: It is a surprise to me that ULA addresses are not by default routable within the site. I can easily imagine a number of LLN border routers which autonomously allocate different ULA prefixes for use within their individual LLN subnets. IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if they cover an entire enterprise or home network, but not if they cover a subset. Meeting a ULA address outside the local prefix will cause the LLN node to forward its IP packets to the default gateway (border router) of the LLN subnet. This way packets can travel between LLN subnets using normal routing with long-term stable ULA addresses. We need the stable addresses for control-style applications in LLNs. Obviously it requires a routing protocol in the (homenet) LAN but are there other issues? It doesn't just require a routing protocol; it also requires a routing policy that knows which routers have to block the ULAs (plural). That seems a lot more complex that a rule that says only a border router originates and delegates a ULA prefix, because that border router would also know to block the prefix across the border. So we need to determine what the homenet arch text will say on this. I think the assumption so far has been that, as per PD8 in draft-ietf-homenet-arch-02, one router would be elected the "master" to delegate /64 ULA prefixes within the homenet, both to ULA-only LLNs and to links that also have a GUA prefix. If there's an assumption an LLN router will not support that, and instead generate its own /48 ULA, we need to talk about that, or any other scenario that will lead to multiple /48 ULAs in a single homenet site. The arch text currently says that ULAs should be used (CN1) and that ULAs should be preferred for internal communications to GUAs (section 2.4). It doesn't say how connections >from outside the homenet can be made to internal ULA-only devices. The 3484-bis text has changed the default ULA preference to protect against ULA leakage, so if you now want ULAs preferred you need to somehow inject the specific site /48 ULA being used with high precedence into the policy table (and as also pointed out here if your site is using less than a /48, you should also have some way to learn what the site prefix length is). In the homenet case is that injection achieved on receipt of an RA, or would it require the proposed DHCPv6 option to be used (which may not be widely implemented for some time, and the DHCPv6 server still needs to learn the ULA to put in the option)? On the one hand homenet is saying "we'd prefer to use ULAs by default without needing some magic to achieve it" while 6man is saying "we need to protect against ULA leakage, so if you want to prefer ULA for internal connection stability figure out the magic". This needs to be mapped to words for the homenet arch text. Tim Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis and discuss it over on v6ops. Brian Thanks, Anders You'll find the above logic in the current 3484bis draft. -Dave -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC2053cphex1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ray,

 

> So I humbly suggest the WG should first concent= rate on properly formulating and clarifying the high level architectural re= quirements,

> rather than on ULA in and of itself.

 

I agree that we must concentrate on the architecture= requirements first.
It would however be unfortunate if these requirements ruled out the case of= routing between homenet subnets based on stable addresses when<= /p>

we have a couple of use cases for LLNs that call suc= h functionality.

Maybe I should provide some use cases to Bing's draf= t to outline why this matters to us LLN guys.


I think I need some education on ULA routing - s= tarting new thread...

 <= /p>

- Anders

 <= /p>

From: homenet-bounces@ietf.org [mailto:homenet-bounces@= ietf.org] On Behalf Of Ray Hunter
Sent: Thursday, March 22, 2012 09:29
To: Brian E Carpenter
Cc: 6man; Tim Chown; Don Sturek; homenet@ietf.org Group
Subject: Re: [homenet] ULA scope [draft-ietf-6man-rfc3484-revise-05.= txt]

 

+1

Firstly, I have been lurking on the 3484-revise discussion in 6man for a lo= ng time. I agree with Brian's proposal:
[source & destination of a /48 ULA prefix match =3D> prefer over 200= 0:/3 space. Otherwise don't (by default).]



Secondly, I think Homenet still has a lot of work to do, especially due to = the autoconfig requirements.
Everyone wants autoconfig. Concurrent ULA + PA + both with autoconf= ig + invariant addresses is likely going to be tough, if not downright = impossible.

So why do we think we really need concurrent ULA+PA in Homenet as a bas= e requirement? I'm not entirely convinced yet.

One reason ULA seems to be mentioned is "time-invariance of addressing= for use by sensor networks." I don't see how "complete time-inva= riance of addressing"  is achievable together with autoconfig, ev= en if we call for an equivalent site-local addressing with a fixed /48 prefix that is common to all Homenet implementations everywher= e. We've been down that rathole before. Site-local has been deprecated in R= FC3879. And realistically speaking, any time someone replaces or adds or re= -plugs any router hardware, the LAN's /64 prefix will change when using autoconfig.

I think it would be useful for the Homenet WG to propose a scheme for senso= r networks to be able to maintain simple peerings despite the presence of t= ime-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. I= n fact, it would seem to me that a peering solution should use something that is long-term invariant as an = identifier for keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, = and not the IPv6 address at all. The invariant identifier could be automati= cally registered by each sensor as a name in the Homenet naming service. Peers could resolve that name to = the current IPv6 address and then verify the peering using their own protoc= ol like HMAC_MD5 with a shared secret (RFC2104). Loss of connection would t= rigger a new address resolution, reconnection, and peer check. Agreeing the shared secret is peering specif= ic (and has to be solved anyway even with fixed addresses). I have an aster= isk hardware phone that does something similar to this, so it can't require= much code.


A reason concurrent ULA+PA seems to be required was that "intra-ho= menet communication should survive a long term ISP outage, and must be able= to be established without any ISP connection present."

The first linkage would appear to be when ISP PA-derived prefixes within Ho= menet timeout via DHCPv6 PD meaning that a long-running session based on th= is address would drop. That has nothing directly to do with ULA, and may ha= ve other solutions.

Question: How long are ISP's setting their DHCPv6 PD timers in practice? Si= mply recommending very long timers for the DHCPv6 PD PA-derived prefix migh= t be a practical solution. How often has your ISP connection been down for = say 10 days?

Another solution might be for the application to reconnect using another PA= -derived address (if the user has two providers).


The second linkage may also have other solutions, such as only configuring = a ULA prefix when no PA-derived prefixes are present.

That would mean at any one time the Homenet could potentially be running ei= ther ULA or multiple PA, but not both, which completely avoids any address = selection conflicts and having to redistribute new RFC3484 address selectio= n rules to all nodes. Simply put: "Please reboot or reconnect to fix any problems."

So I humbly suggest the WG should first concentrate on properly formulating= and clarifying the high level architectural requirements, rather than on U= LA in and of itself.

regards,
RayH


Brian E Carpenter wrote: 

Don,
 
On 2012-03-22 01:24, Don Sturek wrote:
  
Hi Tim,
 
One more consideration:
In the home, it is possible that multiple independent subnets could be=

combined, each with their own ULA prefix.  This would happen in c=
ases
where the homeowner buys multiple silo'ed solutions (like a home<=
/o:p>
automation system, Wi-Fi AP with connected MACs/Pcs, etc) then purchas=
es a
cross connect device that integrates these solutions.
    
 
Yes, anything could happen and probably will. So while a single ULA pe=
r
site is the simple and obvious case (and I don't have any argument for=

Anders except KISS), there *will* be cases where several ULAs pop=

up, and I think resolving routing issues in that situation is likely
to be troublesome. We can't resolve it as we do for enterprise network=
s
by saying that the network's manager will manually configure appropria=
te
routes.
 
    Brian
 
  
Don
 
 
 
 
 
On 3/21/12 4:55 AM, "Tim Chown" <tjc@ecs.soton.ac.uk> wrote:
 
    
On 20 Mar 2012, at 21:25, Brian E Carpenter wrote:
 
      
On 2012-03-20 21:51, Anders Brandt wrote:
        
It is a surprise to me that ULA addresses are not by default routable<=
o:p>
within the site.
I can easily imagine a number of LLN border routers which autonomously=

allocate
different ULA prefixes for use within their individual LLN subnets.
          

IMHO that should be a NOT RECOMMENDED behaviour. ULAs make sense if th=
ey
cover an entire enterprise or home network, but not if they cover a
subset.
 
        
Meeting a ULA address outside the local prefix will cause the LLN node=

to forward
its IP packets to the default gateway (border router) of the LLN<=
/o:p>
subnet. This way
packets can travel between LLN subnets using normal routing with<=
/o:p>
long-term stable
ULA addresses. We need the stable addresses for control-style
applications in LLNs.
 
Obviously it requires a routing protocol in the (homenet) LAN but are<=
o:p>
there other issues?
          

It doesn't just require a routing protocol; it also requires a routing=

policy
that knows which routers have to block the ULAs (plural). That seems a=

lot
more complex that a rule that says only a border router originates and=

delegates
a ULA prefix, because that border router would also know to block the<=
o:p>
prefix across the border.
        
So we need to determine what the homenet arch text will say on this.
 
I think the assumption so far has been that, as per PD8 in<=
/pre>

draft-ietf-homenet-arch-02,


one router would be elected the "master" to delegate /64 ULA=
 prefixes


within the


homenet, both to ULA-only LLNs and to links that also have a GUA prefi=
x.


If there's 


an assumption an LLN router will not support that, and instead generat=
e


its own /48 


ULA, we need to talk about that, or any other scenario that will lead =
to


multiple /48 ULAs 


in a single homenet site.


 


The arch text currently says that ULAs should be used (CN1) and that U=
LAs


should be 


preferred for internal communications to GUAs (section 2.4).  It =
doesn't


say how connections


      


>from outside the homenet can be made to internal ULA-only devices.=

    
The 3484-bis text has changed the default ULA preference to protect
against ULA leakage,
so if you now want ULAs preferred you need to somehow inject the speci=
fic
site /48 ULA
being used with high precedence into the policy table (and as also
pointed out here if your
site is using less than a /48, you should also have some way to learn<=
o:p>
what the site prefix
length is). In the homenet case is that injection achieved on receipt =
of
an RA, or would it
require the proposed DHCPv6 option to be used (which may not be widely=

implemented 
for some time, and the DHCPv6 server still needs to learn the ULA to p=
ut
in the option)? 
 
On the one hand homenet is saying "we'd prefer to use ULAs by def=
ault
without needing
some magic to achieve it" while 6man is saying "we need to p=
rotect
against ULA leakage,
so if you want to prefer ULA for internal connection stability figure =
out
the magic".  
 
This needs to be mapped to words for the homenet arch text.=

 
Tim
 
      
Anyway - maybe you should look at draft-liu-v6ops-ula-usage-analysis
and discuss it over on v6ops.
 
   Brian
 
        
Thanks,
 Anders
          





You'll find the above logic in the current 3484bis draft.

 


-Dave


--------------------------------------------------------------------


IETF IPv6 working group mailing list


ipv6@ietf.org


Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6


--------------------------------------------------------------------


           &nbs=
p;  




_______________________________________________


homenet mailing list


homenet@ietf.org

https://www.=
ietf.org/mailman/listinfo/homenet


            




_______________________________________________


homenet mailing list


homenet@ietf.org

https://www.=
ietf.org/mailman/listinfo/homenet


 


          

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
        
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
      
 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
 
    
 
 
--_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC2053cphex1_-- From Anders_Brandt@sigmadesigns.com Thu Mar 22 03:01:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3026121F8656; Thu, 22 Mar 2012 03:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 aUpP+F+-zZcq; Thu, 22 Mar 2012 03:01:39 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 40EEB21F8650; Thu, 22 Mar 2012 03:01:39 -0700 (PDT) From: Anders Brandt To: 6man , Tim Chown , Don Sturek , "homenet@ietf.org Group" , Ray Hunter , Brian E Carpenter , Thomas Herbst Thread-Topic: Routing between hosts in ULA subnets Thread-Index: Ac0ICzMLeb6p7jSYSAG4znR5jr2Gqw== Date: Thu, 22 Mar 2012 10:00:56 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC216F@cph-ex1> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.120] Content-Type: multipart/alternative; boundary="_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC216Fcphex1_" MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com Subject: [homenet] Routing between hosts in ULA subnets X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 10:01:40 -0000 --_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC216Fcphex1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a branch of the discussion [homenet] ULA scope [draft-ietf-6man-rfc3484-= revise-05.txt], I would like some clear explanation of the actual issues related to routing= between hosts in ULA subnets. Some people seems to be concerned for a reason that seems pretty unclear to= me. Here is my use case: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I have a new house. The electrician installs lighting devices from two vend= ors using different LLN technologies, e.g. power line and RF. The ISP has not installed a CER router yet, so there is no central source o= f prefixes or naming service. The electrician completes his installation by including devices with their = respective border routers and testing with a stand-alone tool that all devices communicate correctly. Now a technician sets up advanced rules for how timers and sensors control = lights and window blinds. He plugs a cable between the two LLN border routers and connects a PC. He uses mDNS to discover the devices via Resource Directories in the LLN bo= rder routers. Devices are configured to control other devices using some application prot= ocol. Everything works when the technician leaves the house. A week later the ISP installs the CER router. Everything still works. Here is my question(s): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Why should homenet require the subnet ULAs to be distributed from another r= outer? It works without extra routers in the scenario described above. (Actually, the technician's configuration would break if new ULAs were dist= ributed by another router later on). Why cannot two border routers connected to the homenet LAN make routing pro= tocol announcements for two different ULA prefixes - such as: "I am the router with LAN link-local address X and you can use me to reach = ULA subnet XX" ? In a homenet case, why cannot the default ULA policy be boiled down to "Dis= card ULA packets trying to pass the CER"? Thanks, Anders --_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC216Fcphex1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As a branch of the discussion [homenet] ULA scope [draft-ietf-6man-rfc= 3484-revise-05.txt],
I would like some clear explanation of the actual issues related to ro= uting between hosts in ULA subnets.
Some people seems to be concerned for a reason that seems pretty uncle= ar to me.
 
Here is my use case:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
I have a new house. The electrician installs lighting devices from two= vendors using different LLN technologies,
e.g. power line and RF.
The ISP has not installed a CER router yet, so there is no central sou= rce of prefixes or naming service.
 
The electrician completes his installation by including devices with t= heir respective border routers and testing
with a stand-alone tool that all devices communicate correctly.
 
Now a technician sets up advanced rules for how timers and sensors con= trol lights and window blinds.
He plugs a cable between the two LLN border routers and connects a PC.=
He uses mDNS to discover the devices via Resource Directories in the L= LN border routers.
Devices are configured to control other devices using some application= protocol.
Everything works when the technician leaves the house.
 
A week later the ISP installs the CER router. Everything still works.<= /div>
 
 
Here is my question(s):
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Why should homenet require the subnet ULAs to be distributed from anot= her router?
It works without extra routers in the scenario described above.
(Actually, the technician's configuration would break if new ULAs were dist= ributed by another router later on).
 
Why cannot two border routers connected to the homenet LAN make routin= g protocol announcements
for two different ULA prefixes - such as:
"I am the router with LAN link-local address X and you can use me= to reach ULA subnet XX"  ?
 
In a homenet case, why cannot the default ULA policy be boiled down to= "Discard ULA packets trying to pass the CER"?
 
 
Thanks,
  Anders
 
 
 --_000_03F31C213F2C6941BFDDBB4336E9E6CD0ABC216Fcphex1_-- From v6ops@globis.net Thu Mar 22 06:49:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E6421F8419 for ; Thu, 22 Mar 2012 06:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.026 X-Spam-Level: X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-1.327, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MANGLED_PAIN=2.3] 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 V15sxEwFniBP for ; Thu, 22 Mar 2012 06:49:58 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id D37D821F8619 for ; Thu, 22 Mar 2012 06:49:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 997FA8700E2; Thu, 22 Mar 2012 14:49:56 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7eCW5XYCZ9y; Thu, 22 Mar 2012 14:49:44 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 2B6FD870070; Thu, 22 Mar 2012 14:49:44 +0100 (CET) Message-ID: <4F6B2DF7.30500@globis.net> Date: Thu, 22 Mar 2012 14:49:43 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: homenet issue tracker References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> In-Reply-To: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tjc@ecs.soton.ac.uk, homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 13:49:59 -0000 As requested by Tim: My comments on ULA use in Homenet posted in consolidated manner to the issue tracker. I think Homenet still has a lot of work to do, especially due to the autoconfig requirements. Everyone wants autoconfig. Concurrent ULA + PA + both with autoconfig + invariant addresses is likely going to be tough, if not downright impossible. So why do we think we really need concurrent ULA+PA in Homenet as a base requirement? I'm not entirely convinced yet. Issue 1: One reason ULA seems to be mentioned is "time-invariance of addressing for use by sensor networks." Using the example of an electrician setting up a sensor network in a home before an ISP is present, and expecting time-invariant ULA addresses. Firstly, the electrician would have to generate a Global ID for ULA when the lights are installed. The electrician can generate a unique Global ID (and hence the /48 prefix of ULA) using the procedure in RFC4193. Problems with this are: 1) The /48 ULA prefix is tied to a time (when the electrician pressed the "generate ULA" button) If a user regenerates the ULA prefix later, the algorithm will generate a different /48 prefix: all addresses in the house will change 2) The /48 ULA prefix is tied to a MAC address (of the router or device used to seed the ULA prefix generation algorithm) If a user changes router hardware, the /48 prefix will change. Or else the seed stored in non-volatile memory will be lost when hardware is replaced. Again all addresses in the house will change 3) The Global ID portion of the ULA has to be manually assigned to each of the routers (if there's more than one) as there's no mechanism to distribute Global IDs today. Homenet needs autoconfiguration. 4) Even if the /48 prefix is made invariant, the /64 LAN prefix generated from it probably won't be invariant as hardware is added, replugged or removed. Again, OK for manual configuration like an enterprise network, but Homenet wants autoconfig. I don't see how "complete time-invariance of addressing" is achievable together with autoconfig, even if we call for an equivalent site-local addressing with a fixed /48 prefix that is common to all Homenet implementations everywhere. We've been down that rathole before. Site-local has been deprecated in RFC3879. And realistically speaking, any time someone replaces or adds or re-plugs any router hardware, the LAN's /64 prefix will change when using autoconfig. I think it would be useful for the Homenet WG to propose a scheme for sensor networks to be able to maintain simple peerings despite the presence of time-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. In fact, it would seem to me that a peering solution should use something that is long-term invariant as an identifier for keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at all. The invariant identifier could be automatically registered by each sensor as a name in the Homenet naming service. Peers could resolve that name to the current IPv6 address and then verify the peering using their own protocol like HMAC_MD5 with a shared secret (RFC2104). Loss of connection would trigger a new address resolution, reconnection, and peer check. Agreeing the shared secret is peering specific (and has to be solved anyway even with fixed addresses). I have an asterisk hardware phone that does something similar to this, so it can't require much code. Issue 2: Use of multiple ULA Global ID's in Homenet may also cause problems with source address selection (3484-revise). There is no way to know which ULA's are connected to the local Homenet, and which are distributed on remote Homenets spread over the Internet. This causes problems with potential ULA leakage, and in determining priority between PA-derived addresses and ULA addresses when both are available and the default 3484 or 3484-revise rules are followed. A workaround might be to be redistribute a non-default RFC3484-revise policy table to all end nodes via draft-fujisaki-dhc-addr-select-opt-07, but its not clear that all end nodes will support this mechanism, nor how the contents of the policy table would be managed in a distributed and automated manner. Issue 3: A reason concurrent ULA+PA seems to be required was that "intra-homenet communication should survive a long term ISP outage, and must be able to be established without any ISP connection present." The first linkage would appear to be when ISP PA-derived prefixes within Homenet timeout via DHCPv6 PD meaning that a long-running session based on this address would drop. That has nothing directly to do with ULA, and may have other solutions. Question: How long are ISP's setting their DHCPv6 PD timers in practice? Simply recommending very long timers for the DHCPv6 PD PA-derived prefix might be a practical solution. How often has your ISP connection been down for say 10 days? Another solution might be for the application to reconnect using another PA-derived address (if the user has two providers). The second linkage may also have other solutions, such as only configuring a ULA prefix when no PA-derived prefixes are present. That would mean at any one time the Homenet could potentially be running either ULA or multiple PA, but not both, which completely avoids any address selection conflicts and having to redistribute new RFC3484 address selection rules to all nodes. Simply put: "Please reboot or reconnect to fix any problems." regards, RayH homenet issue tracker wrote: > #4: Use of ULAs > > CN1 in the -02 text says ULAs should be provisioned by default. Do we > agree? And if so, should they be preferred over globals? The new > 3484-bis has changed so they are not *unless* a specific /48 for the site > is added to the 3484 policy table with higher precedence than globals. We > should design something that works when disconnected from the Internet. > Also, we currently say nothing about ULA-only devices and their > reachability from outside the homenet; do we want to? > > From rogerj@gmail.com Thu Mar 22 13:03:11 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D8221F8566 for ; Thu, 22 Mar 2012 13:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.16 X-Spam-Level: X-Spam-Status: No, score=-3.16 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 lc7TyrtjaCfs for ; Thu, 22 Mar 2012 13:03:10 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7A121F855B for ; Thu, 22 Mar 2012 13:03:10 -0700 (PDT) Received: by iazz13 with SMTP id z13so4149451iaz.31 for ; Thu, 22 Mar 2012 13:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=f7B7wi2hfjx9GBa4FOFLFvqim+Nu+W+1g+3E9QiBfyk=; b=lMfG3ch2/qJ6lKmd34x6xuPX3Tsfm8Nq72F8fdtTpZTE/ozktfoc7F+yXo2cltGkFV pUzoS6YAEmOV6Lc7CXZBPbakxBUo+H39VxrS4oZaxDY4Ktf56b8rEgSchjmnJ5CETpE5 j024YZw/1vo6Zo35AjPWF+CXi+lU/BB184QLKcWGyrac8fYHfdnA9Pt3omfcpLotIFjR sev5Vmm/L5fNxdlsfROMP7H8kI664uXSt052ezP4D4O/fK6cIj8muuGAJRyosMxBYFFx r89xC8FrG+08eDoizBsnaSpwYS5tPj4ZNdTAdnldF4I5s7bBbk3PVERhqtIGqhzqBVTl XpAw== MIME-Version: 1.0 Received: by 10.50.192.134 with SMTP id hg6mr72730igc.59.1332446590264; Thu, 22 Mar 2012 13:03:10 -0700 (PDT) Received: by 10.42.117.200 with HTTP; Thu, 22 Mar 2012 13:03:10 -0700 (PDT) In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC216F@cph-ex1> References: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC216F@cph-ex1> Date: Thu, 22 Mar 2012 21:03:10 +0100 Message-ID: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= To: Anders Brandt , "homenet@ietf.org Group" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [homenet] Routing between hosts in ULA subnets X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 20:03:11 -0000 On Thu, Mar 22, 2012 at 11:00 AM, Anders Brandt wrote: > As a branch of the discussion [homenet] ULA scope > [draft-ietf-6man-rfc3484-revise-05.txt], > I would like some clear explanation of the actual issues related to routi= ng > between hosts in ULA subnets. > Some people seems to be concerned for a reason that seems pretty unclear = to > me. > > Here is my use case: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > I have a new house. The electrician installs lighting devices from two > vendors using different LLN technologies, > e.g. power line and RF. > The ISP has not installed a CER router yet, so there is no central source= of > prefixes or naming service. > > The electrician completes his installation by including devices with thei= r > respective border routers and testing > with a stand-alone tool that all devices communicate correctly. > > Now a technician sets up advanced rules for how timers and sensors contro= l > lights and window blinds. > He plugs a cable between the two LLN border routers and connects a PC. > He uses mDNS to discover the devices via Resource Directories in the LLN > border routers. > Devices are configured to control other devices using some application > protocol. > Everything works when the technician leaves the house. > > A week later the ISP installs the CER router. Everything still works. > > > Here is my question(s): > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Why should homenet require the subnet ULAs to be distributed from another > router? > It works without extra routers in the scenario described above. > (Actually, the technician's configuration would break if new ULAs were > distributed by another router later on). > > Why cannot two border routers connected to the homenet LAN make routing > protocol announcements > for two different ULA prefixes - such as: > "I am the router with LAN link-local address X and you can use me to reac= h > ULA subnet XX"=A0 ? > > In a homenet case, why cannot the default ULA policy be boiled down to > "Discard ULA packets trying to pass the CER"? Your descriptions was better than the one I started to write so I just +1 t= his. But just to add another idea/thought, what about let all devices, no matter if it's routed or bridged or whatnot, intercommunicate using their own "closed" ULA based network? One place to manage it all through https or similar... --=20 Roger Jorgensen=A0 =A0 =A0 =A0 =A0=A0 | rogerj@gmail.com=A0 =A0 =A0 =A0 =A0 | - IPv6 is The Key! http://www.jorgensen.no=A0=A0 | roger@jorgensen.no From brian.e.carpenter@gmail.com Thu Mar 22 15:41:34 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCDC21F84EF for ; Thu, 22 Mar 2012 15:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.342 X-Spam-Level: X-Spam-Status: No, score=-103.342 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] 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 zersas48+M8N for ; Thu, 22 Mar 2012 15:41:33 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFFF21F84EE for ; Thu, 22 Mar 2012 15:41:33 -0700 (PDT) Received: by eeke51 with SMTP id e51so863841eek.31 for ; Thu, 22 Mar 2012 15:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yiskJSB1Tu7PQXQUbC3qXD+R1piPqQLQuLOoMWyeLIE=; b=BaKq7Z+tybXpAmAFTgSDt5oZk4TVnFKNKl0pVPpUw3VEsJMcQMBe2OCNPwp47fOLmV UOVUckKR92G1ykYdn/IOw00mXlNu6f2Faf0Sifjij9nhDeKM+5QJMshLuLPR7AOJFqDv beApqvmHoNMKR39rltgYQvR37m0oY9i+FvdoH7CLbi4GBigetUcIRMqIhvSS9uE5A+O3 WYj/hi9Oo9qCDlej+onNWhnv7u0embUj94RxqI2Fpjnelly1auYQP5bI2xyVRh2RfocK KYeKDSCfLKjMcwmJXbsi7tIKzkc+ceqXKNRmge+kpysOVlXz7izbu/RlR8U8TLJ7RArh sE2Q== Received: by 10.213.21.206 with SMTP id k14mr765392ebb.9.1332456092878; Thu, 22 Mar 2012 15:41:32 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id e56sm21600065eea.11.2012.03.22.15.41.28 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 15:41:32 -0700 (PDT) Message-ID: <4F6BAA92.8090108@gmail.com> Date: Fri, 23 Mar 2012 11:41:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: homenet issue tracker References: <061.6a445747e247b219642216b1fa46f68c@trac.tools.ietf.org> In-Reply-To: <061.6a445747e247b219642216b1fa46f68c@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tjc@ecs.soton.ac.uk, homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #1: Multihoming support X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 22:41:34 -0000 On 2012-03-22 12:24, homenet issue tracker wrote: > #1: Multihoming support > > Currently the -02 arch text talks about multihoming in MH2, MH7, MH8, RT11 > and RT12. We say that single CER, multiple uplink multihoming is > supported, but multi-CER, multiple uplink multihoming is only desirable. > Do we want to make the latter a requirement as well, or "strongly > desirable"? To confirm what I've already said: I think multi-CER with *one* uplink per CER will be a common scenario (tens or hundreds of millions of cases) and needs to be covered. A single CER with multi-uplink will also be common. Maybe multi-CER with multi-uplink per CER can be deferred. Brian From brian.e.carpenter@gmail.com Thu Mar 22 15:50:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B6221F84A5 for ; Thu, 22 Mar 2012 15:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 gzOx26YzFE6B for ; Thu, 22 Mar 2012 15:50:19 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9D021F8478 for ; Thu, 22 Mar 2012 15:50:19 -0700 (PDT) Received: by eeke51 with SMTP id e51so864910eek.31 for ; Thu, 22 Mar 2012 15:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7Xp+zvkeLymgZBuUc28Z+/U8tR9K1LFsatFA75oCaiE=; b=Sj8tvUT5LbLQ2nCru8F6vIuy01qKYfEDQyHwSSetKYdeGjdVtMU9GYmRiMzm0Pr77M 5VleSoN2t0zZAtv8O+4dknanbtszeERutKwYVh5esUwXOX5AMAX+dLav+3qAGSKJDoEP +fhqKCMj4zDhLxethc3M2L4TeZykCcZJNwWMU0j7IZNrKiqMziZSJVCrrYJv3SWFXJiF vgPXQz1gSa76zaZ+l56wAJE9HZN5B225vhxEeWJgU54FYxTP3WXN8rxBF0lRzt3VszKe mFNmMNXyZdgCd3prVB7s3TCE87ApTXQhB3S46Wscm0WrDduouuMjumOAu7/Mbl6NNNL0 9tHQ== Received: by 10.213.110.17 with SMTP id l17mr766508ebp.42.1332456618395; Thu, 22 Mar 2012 15:50:18 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id p57sm21644340eei.8.2012.03.22.15.50.14 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 15:50:17 -0700 (PDT) Message-ID: <4F6BAC9F.10903@gmail.com> Date: Fri, 23 Mar 2012 11:50:07 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: homenet issue tracker References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> In-Reply-To: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tjc@ecs.soton.ac.uk, homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 22:50:20 -0000 On 2012-03-22 12:33, homenet issue tracker wrote: > #4: Use of ULAs > > CN1 in the -02 text says ULAs should be provisioned by default. Do we > agree? Yes, by the CER (MUST). It's much less clear for all other routers on site. I would prefer that no other router provisions a ULA prefix if the CER has already delegated one. > And if so, should they be preferred over globals? Yes. > The new > 3484-bis has changed so they are not *unless* a specific /48 for the site > is added to the 3484 policy table with higher precedence than globals. We > should design something that works when disconnected from the Internet. We'll have to deal with whatever 3484bis ends up saying. If it does require an explicit policy table entry table, that will require a mechanism, associated with the prefix delegation mechanism. > Also, we currently say nothing about ULA-only devices and their > reachability from outside the homenet; do we want to? I don't see what there is to say; they aren't reachable, and that's a feature. Brian From brian.e.carpenter@gmail.com Thu Mar 22 15:56:14 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0348821E801F for ; Thu, 22 Mar 2012 15:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.5 X-Spam-Level: X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Q982WGsTr9jw for ; Thu, 22 Mar 2012 15:56:13 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4424B21E801B for ; Thu, 22 Mar 2012 15:56:13 -0700 (PDT) Received: by eeke51 with SMTP id e51so865599eek.31 for ; Thu, 22 Mar 2012 15:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tXaz/Od6qLJQM34jpxhGDknaiJyFf0NHJLNaiUlQlgQ=; b=FwfX9s4/6QZoxJW4NUQ/ITy+R44rghYTU4UT17rEfc9oK5e/6f7JSiQHFhmZabqJMx Bq+KxCXTrG1tpsr/1nuQPNxUNLPuaKw38z5pXWES/AU8na5mcNOAsmZ5whNPYHQXtHu1 woVjD4wfJW/zYur9dzKot19Vi7RUCqlDQAIvARYpO4KC79C1NJczR+7eI4YbrZa2G+rv 2v3NGBs0ZZzari92Fy8sNTQHcVr69T0T/EmBdRBp1hRQglmgWRuLGPWV+vTEv9BX5BP2 M6RzKiOSR0eG0H0HMC1s4xQ/RCq2X3UOVXMO6t2k6SYpHnfH83Gs02iWiH6qiTqlgsf4 5fxQ== Received: by 10.213.21.130 with SMTP id j2mr737526ebb.52.1332456972416; Thu, 22 Mar 2012 15:56:12 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n56sm21701246eeb.4.2012.03.22.15.56.08 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 15:56:11 -0700 (PDT) Message-ID: <4F6BAE02.7010501@gmail.com> Date: Fri, 23 Mar 2012 11:56:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: homenet issue tracker References: <061.291a707258a462ecf19477dc3364e5c2@trac.tools.ietf.org> In-Reply-To: <061.291a707258a462ecf19477dc3364e5c2@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tjc@ecs.soton.ac.uk, homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #5: Support for "flash" renumbering X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 22:56:14 -0000 On 2012-03-22 12:36, homenet issue tracker wrote: > #5: Support for "flash" renumbering > > In PD13 and AD3 we say that flash renumbering should be supported. This is > due to many ISPs saying they may provision prefixes to residential > networks that may change over time. What exactly should we say about what > we mean by the minimum support for such renumbering? This topic is linked > to the ULA use topic. IMHO it's also linked to clearly understanding the implications of a total power loss followed by a cold start of every non-battery device. If that works, then flash renumbering is really a subset of a cold start; in the worst case, the help desk will be telling the user to switch *everything* off and on again. I think this is quite a hairy topic, and it's hard to quickly define the minimum support. Brian From brian.e.carpenter@gmail.com Thu Mar 22 15:57:15 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD8E21E801B for ; Thu, 22 Mar 2012 15:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.5 X-Spam-Level: X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 rUKLbs4ICBQ2 for ; Thu, 22 Mar 2012 15:57:14 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93B2421E802C for ; Thu, 22 Mar 2012 15:57:14 -0700 (PDT) Received: by eeke51 with SMTP id e51so865715eek.31 for ; Thu, 22 Mar 2012 15:57:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Nxa/STc/HXcPKG1y66Kf5cWonhemb2mEkMbqPj8WNYw=; b=APomv6Xf3nG72xmqnUdaobyxiM3EC6b2vBYYrsrCWkZygbZcC0Nd4PgonskQnTf9KR aE16rZ3/FKlaiCMrLNGdHdZijZLjGh0cIT8tDGlfYyKf/qCNKEaZkE7AUocgHpySAjTG dM2BGxQime9Rd5a1BdKEMrwQFu0gTxdoFMRGTu52+VSEdNuREqbobVnYYWQPBu0kdajW nJiFBI1w+wdk9f1JFqi/7SWfH5okI60tVGbL/1yTddLsX8kiR0t6NGBV2edn/6MTsSBm 6Kimn3YfFxOA9dsfwBbT5YSQ98WimkvHJERCF3yz7h2jG92EGhgRBPO+XspzBQ3EVj0f mpMw== Received: by 10.14.194.72 with SMTP id l48mr1383927een.100.1332457033835; Thu, 22 Mar 2012 15:57:13 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id z47sm21702378een.5.2012.03.22.15.57.10 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 15:57:13 -0700 (PDT) Message-ID: <4F6BAE40.4020005@gmail.com> Date: Fri, 23 Mar 2012 11:57:04 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: homenet issue tracker References: <061.90de23b8a14a673d9c6b0086ae165167@trac.tools.ietf.org> In-Reply-To: <061.90de23b8a14a673d9c6b0086ae165167@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: tjc@ecs.soton.ac.uk, homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #6: Support for arbitrary topologies X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 22:57:15 -0000 On 2012-03-22 12:37, homenet issue tracker wrote: > #6: Support for arbitrary topologies > > We currently state that homenets should support arbitrary topologies > (SD1). There have been some comments that this might not be realistic. > Should we continue to shoot for that? The users will create arbitrary topologies. How can we stop them? Brian From leo.liubing@huawei.com Thu Mar 22 22:34:02 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6BE21F8469; Thu, 22 Mar 2012 22:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753] 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 OfIR8Qw9lA09; Thu, 22 Mar 2012 22:34:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B9DA521F8468; Thu, 22 Mar 2012 22:34:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEP96741; Fri, 23 Mar 2012 01:34:01 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 22:31:02 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 22:31:09 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 13:31:03 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , IPv6 Operations Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 Thread-Index: AQHNCKO8Z4KSGk/lHk+mkdEjskALJpZ3UmnA Date: Fri, 23 Mar 2012 05:31:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F4524A26650@szxeml509-mbs> References: <4F6BEB95.60608@gmail.com> In-Reply-To: <4F6BEB95.60608@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "homenet@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [homenet] [v6ops] draft-liu-v6ops-ula-usage-analysis-02 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 05:34:02 -0000 SGksIEJyaWFuDQoNClRoZXJlIGNvbWVzIGNvbW1lbnRzIGZpbmFsbHkgOi0pIFRoYW5rcyBmb3Ig eW91ciBjb25jZXJuIGFib3V0IHRoZSBkcmFmdC4gIA0KDQpJJ3ZlIG5vdGljZWQgdGhlIGRpc2N1 c3Npb24gaW4gNm1hbiBhbmQgaG9tZW5ldCwgd2hpY2ggaXMgbW9yZSBpbi1kZXB0aCB0ZWNobmlj YWwgaXNzdWUgd2hpbGUgdGhlIFVMQSB1c2FnZSBkcmFmdCBpcyBtb3JlIGdlbmVyYWwgdXNlIGNh c2VzLiBCdXQgSSB0aGluayBpdCBpcyBleGFjdGx5IHZhbHVhYmxlIGlucHV0IGFuZCBjb25zaWRl cmF0aW9uIHRvIHRoZSBVTEEgZHJhZnQgZm9yIHRoZSBmdXJ0aGVyIHN0ZXAuICANCg0KSSBhbSBh bHNvIGNvbmZ1c2VkIGFib3V0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgZGlzY3Vzc2lv biBpbiB2YXJpb3VzIFdHcyBhbmQgdGhlIFVMQSBkcmFmdC4NCldlIHNob3VsZCBjb3ZlciBhbGwg dGhlIHNwZWNpZmljIGlzc3VlcyBpbiB0aGUgZHJhZnQsIG9yIGp1c3QgbGltaXQgdGhlIGRpc2N1 c3Npb24gd2l0aGluIGVhY2ggV0cgd2hpbGUgdGhlIGRyYWZ0IG9ubHkgZm9jdXMgb24gZ2VuZXJh bCB1c2UgY2FzZXOjvw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog djZvcHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZg0KPiBCcmlhbiBFIENhcnBlbnRlcg0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDIz LCAyMDEyIDExOjE5IEFNDQo+IFRvOiBJUHY2IE9wZXJhdGlvbnMNCj4gU3ViamVjdDogW3Y2b3Bz XSBkcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzLTAyDQo+IA0KPiBIaSwNCj4gDQo+ IEkgdGhpbmsgdGhpcyBkcmFmdCBpcyBhIGNvbnNpZGVyYWJsZSBpbXByb3ZlbWVudCBvbiB0aGUg LTAwIHZlcnNpb24uDQo+IEl0IHN0aWxsIG5lZWRzIHNvbWUgd29yayBvbiB0aGUgRW5nbGlzaCwg YnV0IEkgdGhpbmsgdGhlIG1haW4gcG9pbnRzDQo+IGFyZSBjb3ZlcmVkIG5vdyBhbmQgdGhlIHdv cmsgc2hvdWxkIGNvbnRpbnVlLg0KPiANCj4gSG93ZXZlciwgdGhlcmUgaXMgY2xlYXJseSBhIGNv bXBsaWNhdGlvbiwgd2hpY2ggaXMgdGhhdCB0aGlzIGRvY3VtZW50DQo+IG5lZWRzIHRvIGJlIGFs aWduZWQgd2l0aCB3aGF0ZXZlciBjb25zZW5zdXMgYXBwZWFycyBpbiBob21lbmV0IGFib3V0DQo+ IFVMQXMsIGFuZCB3aXRoIHdoYXRldmVyIGNvbnNlbnN1cyBhcHBlYXJzIGluIDZtYW4gYWJvdXQg UkZDMzQ4NGJpcy4NCj4gDQo+IEluIHBhcnRpY3VsYXIsIGhvbWVuZXQgaXMgaGl0dGluZyB0aGUg cHJvYmxlbSBvZiB3aGF0IGhhcHBlbnMgd2hlbg0KPiBtdWx0aXBsZSBVTEEgcHJlZml4ZXMgc2hv dyB1cCBhdXRvbWF0aWNhbGx5IGluIHRoZSBzYW1lIG5ldHdvcmsuIFRoYXQNCj4gbWF5IG5vdCBi ZSByZWNvbW1lbmRlZCBwcmFjdGljZSwgYnV0IGl0IHNlZW1zIHZlcnkgbGlrZWx5IHRvIGhhcHBl biwNCj4gYW5kIHJhaXNlcyByb3V0aW5nIGFuZCBhZGRyZXNzLXNlbGVjdGlvbiBxdWVzdGlvbnMu DQo+IA0KPiBJIHRoaW5rIHRoZSB2YXJpb3VzIFdHIENoYWlycyBuZWVkIHRvIGFncmVlIGhvdyB0 aGUgZGlzY3Vzc2lvbiBzaG91bGQNCj4gYmUgbWFuYWdlZCwgYmVjYXVzZSBpdCBtaWdodCBnZXQg Y29tcGxpY2F0ZWQgd2l0aCB0aHJlZSBXR3MgaW52b2x2ZWQNCj4gKG9yIGZvdXIsIGlmIHlvdSBj b3VudCA2cmVudW0pLg0KPiANCj4gUmVnYXJkcw0KPiAgICBCcmlhbg0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBs aXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCg== From fred@cisco.com Fri Mar 23 16:18:37 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8272321F8552; Fri, 23 Mar 2012 16:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.499 X-Spam-Level: X-Spam-Status: No, score=-110.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 7BC2PrSTAhPT; Fri, 23 Mar 2012 16:18:36 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3E78221F854D; Fri, 23 Mar 2012 16:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4543; q=dns/txt; s=iport; t=1332544716; x=1333754316; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=iIxCD6vq29ipb7Ter8Hain3bjR/qPW2STxKbrZl5Eto=; b=caLFMCTSr60QibdS5c+cDUPOn+GAG+uI29MImd6SoGdj65X/9dmlc2vZ X8R2im5FuFb6iDKxVr+8Q7uNa2UdTGv94MDGShs3JoCl/7LCZTjE2Gk1G o9aea/HlQghTwm7d5sntxPaMvVATDgOmsHlQTpPlNZRo4ZrBSoRpQInQn k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACcEbU+Q/khL/2dsb2JhbABEuBqBB4IJAQEBAwESASc/BQsLEjRJDgYuBQKHYwWZZ55skCJjBJVghW6IVoFogmg X-IronPort-AV: E=Sophos;i="4.73,639,1325462400"; d="scan'208";a="69228948" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 23 Mar 2012 23:18:34 +0000 Received: from Freds-Computer.local (ams3-vpn-dhcp4219.cisco.com [10.61.80.122]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2NNIXBg026352; Fri, 23 Mar 2012 23:18:34 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 24 Mar 2012 00:18:34 +0100 X-PGP-Universal: processed; by Freds-Computer.local on Sat, 24 Mar 2012 00:18:34 +0100 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC216F@cph-ex1> Date: Sat, 24 Mar 2012 00:18:18 +0100 Message-Id: <2834C1C8-DCCB-4D91-8CD4-B5E48EB6AC0A@cisco.com> References: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC216F@cph-ex1> To: Anders Brandt X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: 6man , Don Sturek , Ray Hunter , Tim Chown , Thomas Herbst , "homenet@ietf.org Group" Subject: Re: [homenet] Routing between hosts in ULA subnets X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 23:18:37 -0000 On Mar 22, 2012, at 11:00 AM, Anders Brandt wrote: > As a branch of the discussion [homenet] ULA scope = [draft-ietf-6man-rfc3484-revise-05.txt], > I would like some clear explanation of the actual issues related to = routing between hosts in ULA subnets. > Some people seems to be concerned for a reason that seems pretty = unclear to me. Speaking strictly for myself here... =46rom my perspective, you need at least one prefix for use for = addressing systems in your home/SOHO/whatever. Multiple prefixes are = explicitly supported by the architecture. If you have multiple LANs = within the home, they should under normal circumstances be separate /64s = taken out of a common less specific prefix, such as a /48, /56, /60, = etc. There are arguments for link-local (fe80::/10) as *the* prefix if you = have no upstream and and exactly one LAN. I'm not sure I would recommend = it for the long term, because it can be unmanagable. But for the special = case in which one is configuring a router that has never been connected = to another network, I could well imagine finding a way to address it = using its link-local address. You could use mDNS to translate it from a = well-known name like BRAND-SPANKING-NEW-BRAND-X-ROUTER. If the network has no global prefix (has not ever, or not recently, been = connected to an IPv6 upstream), and either you WANT to have a = non-link-local prefix or you have more than one LAN, ULAs are your = friend, and I'm not sure what else you would use. A ULA is a /48 prefix. If you do have an assigned prefix from one or more upstreams (or, I = suppose, have a PI prefix, which would surprise me), you have at least = one prefix to use that isn't a ULA. It might be a /48, a /56, a /60, or = whatever you were assigned. So, you have one of three obvious prefixes: link-local, a /48 ULA, and s = globally-routed prefix. Each of those, BTW, has a lifetime. The = link-local prefix has an infinite lifetime (infinity is still a number), = you got a lifetime when you got the PA/PI prefix, and you can pick one = for your ULA. Given a prefix, I expect you to allocate a /64 from it for each LAN in = your home. True whether you are using link-local on one LAN, a ULA, or a = global prefix. I can think of error conditions - race conditions - in which a home = might get two or more /48 ULAs floating around in it. I would expect = that the lifetime you place on a ULA eventually clears that up. Until it = does, every LAN in your home has a /64 from each ULA. However, a = persistent condition in which your home has more than one /48 ULA = floating around in it is a bug. Someone needs to fix their code. The $64,000 question is how /64s will be allocated from the prefix(es) = in question. If you use DHCP/DHCPv6 (Ralph and my DHCP draft), a system = is somehow chosen to be the place that DHCP server application runs, and = I would suggest the CPE router that received the DHCP-PD prefix from the = upstream ISP. If you're running ZOSPF, some router (and I would suggest = the same one) is generating an LSA that informs the routers in the home = of the prefix they should allocate from. If you're doing it manually, do = it manually. Whatever the mechanism, and whatever the prefix is (or = prefixes are), the expectation is the same. Speaking strictly for myself, I think the reason we have had so much = trouble getting 3484bis right is that it depends on the host to make = what amounts to a routing decision. The destination address you pick for = your peer system forces the packet to be delivered to that ISP and to = your peer through that ISP's interface to the remote network. In a BCP = 38 world, the source address you pick says that the only exit from your = network that actually works is through the ISP that allocated that = prefix to you (RFC 3704). So, the choice of a source and a destination = address fixes two points on a line connecting your two systems, and that = line is a route. But hosts know little to nothing about routing, and = cannot even predict which egress (if there are more than one) a given = packet will take. So the host fundamentally lacks the information to = make an informed choice. RFC 3484 can't be fixed without changing that. So to my way of thinking, the right solution is Happy Eyeballs, for all = applications (or, preferably, as an OS API service). It will try routes = (source/destination pairs) until it finds a pair that works or runs out = of options.= From rajiva@cisco.com Fri Mar 23 12:51:57 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C367121F85F0; Fri, 23 Mar 2012 12:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 WHwP36VLueK0; Fri, 23 Mar 2012 12:51:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 58C8721F85E3; Fri, 23 Mar 2012 12:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3136; q=dns/txt; s=iport; t=1332532313; x=1333741913; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=1DXCX6PY58i2PiFDy9FzkyAbthXoZ+mX6U7JiAnSCmU=; b=MGadmurNjOYViTaoqe7NMB0re9M5rWxy5A2JyY7IJ0bCs+doqZstz9Wt PqlXyRXDCkzZ0eDY3qEB4Arpxuz6xoRtOMdN61CPYNQofHyWWZEo0TGBT n74gqcDVza2D1eh+EuZr+bu2rOU7N6+9KXyUX7VH9E1dd0FJFZXyWr8sF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOPTbE+tJV2Z/2dsb2JhbABFDrgHgQeCCQEBAQMBAQEBDwEnAgExEAcHCBEDAQJQBigIBgESIodjBQuZeJ51BIlthxgElWCFboVCgxSBaIIwUw X-IronPort-AV: E=Sophos;i="4.73,637,1325462400"; d="scan'208";a="68994671" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 23 Mar 2012 19:51:53 +0000 Received: from [64.102.202.94] (dhcp-64-102-202-94.cisco.com [64.102.202.94]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2NJpjKl006982; Fri, 23 Mar 2012 19:51:48 GMT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 23 Mar 2012 15:51:43 -0400 From: Rajiv Asati To: Anders Brandt , 6man , Tim Chown , Don Sturek , "homenet@ietf.org Group" , Ray Hunter , Brian E Carpenter , Thomas Herbst Message-ID: Thread-Topic: Routing between hosts in ULA subnets In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0ABC216F@cph-ex1> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Sat, 24 Mar 2012 08:45:33 -0700 Subject: Re: [homenet] Routing between hosts in ULA subnets X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 19:51:57 -0000 Andres, Thanks for writing up this use-case. Quick Q - What global ID would get used in the ULA (assuming GUA is not known yet)? > In a homenet case, why cannot the default ULA policy be boiled down to >"Discard > ULA packets trying to pass the CER"? That would be reasonable. Perhaps, just deny forwarding any traffic over an interface that doesn't have any ULA assigned. Cheers, Rajiv -----Original Message----- From: Anders Brandt Date: Thu, 22 Mar 2012 10:00:56 +0000 To: 6man , Tim Chown , Don Sturek , "homenet@ietf.org Group" , Ray Hunter , Brian E Carpenter , Thomas Herbst Subject: Routing between hosts in ULA subnets >As a branch of the discussion [homenet] ULA scope >[draft-ietf-6man-rfc3484-revise-05.txt], >I would like some clear explanation of the actual issues related to >routing between hosts in ULA subnets. >Some people seems to be concerned for a reason that seems pretty unclear >to me. > >Here is my use case: >================= > >I have a new house. The electrician installs lighting devices from two >vendors using different LLN technologies, >e.g. power line and RF. >The ISP has not installed a CER router yet, so there is no central source >of prefixes or naming service. > >The electrician completes his installation by including devices with >their respective border routers and testing > >with a stand-alone tool that all devices communicate correctly. > >Now a technician sets up advanced rules for how timers and sensors >control lights and window blinds. >He plugs a cable between the two LLN border routers and connects a PC. >He uses mDNS to discover the devices via Resource Directories in the LLN >border routers. >Devices are configured to control other devices using some application >protocol. >Everything works when the technician leaves the house. > >A week later the ISP installs the CER router. Everything still works. > > >Here is my question(s): >================== > >Why should homenet require the subnet ULAs to be distributed from another >router? > >It works without extra routers in the scenario described above. > >(Actually, the technician's configuration would break if new ULAs were >distributed by another router later on). > >Why cannot two border routers connected to the homenet LAN make routing >protocol announcements > >for two different ULA prefixes - such as: >"I am the router with LAN link-local address X and you can use me to >reach ULA subnet XX" ? > >In a homenet case, why cannot the default ULA policy be boiled down to >"Discard ULA packets trying to pass the CER"? > > >Thanks, > Anders > > > > >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >ipv6@ietf.org >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- From bs7652@att.com Sat Mar 24 12:45:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E23A21F856F for ; Sat, 24 Mar 2012 12:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.324 X-Spam-Level: X-Spam-Status: No, score=-106.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Y6kxnmv4gBEc for ; Sat, 24 Mar 2012 12:45:40 -0700 (PDT) Received: from nbfkord-smmo04.seg.att.com (nbfkord-smmo04.seg.att.com [209.65.160.86]) by ietfa.amsl.com (Postfix) with ESMTP id 7050921F857D for ; Sat, 24 Mar 2012 12:45:40 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo04.seg.att.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) with ESMTP id 4642e6f4.5a434940.2160945.00-577.5942363.nbfkord-smmo04.seg.att.com (envelope-from ); Sat, 24 Mar 2012 19:45:40 +0000 (UTC) X-MXL-Hash: 4f6e246438627dfa-36a249b5a3af602835a81f9b66f5e070373d5b43 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo04.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 9342e6f4.0.2160813.00-342.5942000.nbfkord-smmo04.seg.att.com (envelope-from ); Sat, 24 Mar 2012 19:45:24 +0000 (UTC) X-MXL-Hash: 4f6e24547e457478-f499b76e5fc0981ee8aff7e402224de1b9dc8b26 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2OJivva024024; Sat, 24 Mar 2012 15:44:57 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2OJinmV023968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Mar 2012 15:44:49 -0400 Received: from GAALPA1MSGHUB9E.ITServices.sbc.com (gaalpa1msghub9e.itservices.sbc.com [130.8.36.91]) by sflint04.pst.cso.att.com (RSA Interceptor); Sat, 24 Mar 2012 15:44:15 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.156]) by GAALPA1MSGHUB9E.ITServices.sbc.com ([130.8.36.91]) with mapi id 14.01.0355.002; Sat, 24 Mar 2012 15:44:14 -0400 From: "STARK, BARBARA H" To: Brian E Carpenter , homenet issue tracker Thread-Topic: [homenet] #6: Support for arbitrary topologies Thread-Index: AQHNCH8jrlWQmMqJLUeYcikGxA7YVpZ5jqnA Date: Sat, 24 Mar 2012 19:44:14 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110779AE@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <061.90de23b8a14a673d9c6b0086ae165167@trac.tools.ietf.org> <4F6BAE40.4020005@gmail.com> In-Reply-To: <4F6BAE40.4020005@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.227.164] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=1.0 c=1 a=hTPaqnw6BcEA:10 a=pmD3xjpMgCoA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=Qs8R1XBwmid1qB] X-AnalysisOut: [FB/a8mmA==:17 a=ubtkrUKghdzUYK7QzPUA:9 a=CjuIK1q_8ugA:10 a] X-AnalysisOut: [=fJrBLPVz_pqNnM6a:21 a=x7iKWcc_p5au7WSQ:21] Cc: "tjc@ecs.soton.ac.uk" , "homenet@ietf.org" , "draft-ietf-homenet-arch@tools.ietf.org" Subject: Re: [homenet] #6: Support for arbitrary topologies X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 19:45:41 -0000 > > #6: Support for arbitrary topologies > > > > We currently state that homenets should support arbitrary topologies > > (SD1). There have been some comments that this might not be > realistic. > > Should we continue to shoot for that? >=20 > The users will create arbitrary topologies. How can we stop them? I don't think it should be a question of trying to stop anybody from doing = anything. It's a question of what do we want to make easy (via auto-configu= ration or minimal configuration like turning something on/off).=20 Certainly somebody could put an Ethernet switch between the CE router WAN a= nd service provider bridged modem, and also connect a LAN port to that Ethe= rnet switch and then connect the rest of the home network off that Ethernet= switch. We don't have to stop them. We just don't have to make things auto= -magically work in this case. I, for one, wouldn't even have a clue as to w= hat they were trying to do. So how could the homenet elements guess what wa= s wanted? IMO, they shouldn't even try. My recommendation would be to focus first and foremost on topologies that h= ave redeeming value. Topologies that users want to have work, because there= is something very specific that they want to achieve. In some cases, there= may be more than one topology that would achieve the same purpose. In that= case, I would suggest that we try to identify the "best" (more intuitive f= or the user, less code involved, less that can go wrong, less guessing what= it is the user is trying to do, etc.) way to achieve the goal and focus on= making that easy for the user, rather than trying to make all ways easy. Any case where it isn't clear what in the world the user is trying to do, w= e shouldn't require the homenet to guess. Here are just a few of the specific goals users want to achieve, but often = run in to trouble accomplishing: 1. ISP provides a CE router and provides IPTV service via set-top boxes (ST= Bs) connected to that CE router. User doesn't want ISP CE router prying int= o his home network (topology discovery, available services, etc) and wants = to put his own router between the ISP CE router and his home network, and m= ake sure no multicast services bleed through. 2. ISP provides a CE router and provides IPTV service via set-top boxes (ST= Bs) connected to that CE router. User has an existing home network setup wi= th an existing router, and wants to leave all of that in place. But he does= want his home network to be able to interact with the STBs (yes to topolog= y discovery, available services, multicast, etc.), and get to the Internet. 3. User wants to have Wi-Fi served from the opposite end of the house from = the ISP CE router. So he uses powerline-Ethernet bridges and plugs a Wi-Fi = router into a powerline-Ethernet bridge on the other end of the house. He w= ants everything to behave like one big happy network. 4. User's Wi-Fi CE router (from the ISP, with built-in PHY modem to the WAN= ) doesn't support multiple SSIDs, and user wants to set up a special "guest= " SSID that will let guests get to the Internet, but not the user's home ne= twork. So the user gets another Wi-Fi router and wants to use it to accompl= ish this separate Guest-net. 5. User's ISP provides just a single IP(v6) address (not so the user can se= t up a home network, but just so the user can connect a single device). Use= r wants to set up a home network, through that one device with just a singl= e IPv6 address (and, no, requiring the ISP to delegate a prefix is not the = solution -- this is homenet and not ISPnet; the single IPv6 address is a gi= ven and the question is how to deal with it to let the user do what he want= s to do, assuming it's not prohibited). Anyway, that's just a few. I can think of many more.=20 And my experience with users is that they're thrilled if there is "a" way t= o make things work, that's simple and reasonably intuitive. They aren't stu= ck on needing all possible ways to work. Barbara From brian.e.carpenter@gmail.com Sat Mar 24 13:04:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2B221F8535 for ; Sat, 24 Mar 2012 13:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.503 X-Spam-Level: X-Spam-Status: No, score=-103.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 GBYRkjZ3xP4t for ; Sat, 24 Mar 2012 13:04:20 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2B7F21F84EC for ; Sat, 24 Mar 2012 13:04:20 -0700 (PDT) Received: by eeke51 with SMTP id e51so1257349eek.31 for ; Sat, 24 Mar 2012 13:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Cib/JKj/n35VqJr709nefHpbcsCUSv/XPSUBi1tdxTc=; b=xcxp6dUNgLGmOXdpL9UJOIk36tLpba1KX6K0gst1fnJcLeNTvueWkeU1tSJITidNzD koTCivkf+hca4zGmHYo/65hLhJ+YqJwbhFscRmXzZbSwMsPcEnUa1vGWQ5Eiq8aWcTjW dYtaQ+tVgc+Vd7tvcRWNSB5hL9pykN45VeY7GqP5QwjtL5gld1ald/w6PWNv79Santr8 3mK0ziOTb/q6cUPjNmleJpRspaYehQNiPeMDl3++rjsiq43vK76tONIQ4e3HQVOQQNNO HkzlN5Qpiq9f5dtHlh7qTdRdocYAlTsvzpj9UUKQVnacc84BlM7oq3Is0iBnGikxe1Jj IYjA== Received: by 10.14.37.78 with SMTP id x54mr2228402eea.42.1332619459667; Sat, 24 Mar 2012 13:04:19 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id d54sm41020532eei.9.2012.03.24.13.04.15 (version=SSLv3 cipher=OTHER); Sat, 24 Mar 2012 13:04:18 -0700 (PDT) Message-ID: <4F6E28B3.4090708@gmail.com> Date: Sun, 25 Mar 2012 09:04:03 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "STARK, BARBARA H" References: <061.90de23b8a14a673d9c6b0086ae165167@trac.tools.ietf.org> <4F6BAE40.4020005@gmail.com> <2D09D61DDFA73D4C884805CC7865E6110779AE@GAALPA1MSGUSR9N.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110779AE@GAALPA1MSGUSR9N.ITServices.sbc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tjc@ecs.soton.ac.uk" , homenet issue tracker , "homenet@ietf.org" , "draft-ietf-homenet-arch@tools.ietf.org" Subject: Re: [homenet] #6: Support for arbitrary topologies X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 20:04:21 -0000 Barbara, On 2012-03-25 08:44, STARK, BARBARA H wrote: >>> #6: Support for arbitrary topologies ... > I don't think it should be a question of trying to stop anybody from doing anything. It's a question of what do we want to make easy (via auto-configuration or minimal configuration like turning something on/off). ... (Much good sense deleted) > And my experience with users is that they're thrilled if there is "a" way to make things work, that's simple and reasonably intuitive. They aren't stuck on needing all possible ways to work. I agree entirely, and it's clear that somebody (not necessarily vendors) will need to write a simple guide on ways to connect up your homenet. What we should perhaps worry about is tools (beyond classical loop prevention in bridging and routing protocols) to detect broken topologies and tell the user about them in a meaningful way. In other words, instead of "support" arbitrary topologies, "diagnose" unsupported topologies. Brian From palm@broadcom.com Sat Mar 24 18:54:35 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7600821F851C for ; Sat, 24 Mar 2012 18:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hnDzzDSp0aLL for ; Sat, 24 Mar 2012 18:54:34 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 8D05321F8514 for ; Sat, 24 Mar 2012 18:54:29 -0700 (PDT) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Sat, 24 Mar 2012 19:03:45 -0700 X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD Received: from mail-irva-13.broadcom.com (10.11.16.103) by IRVEXCHHUB02.corp.ad.broadcom.com (10.9.200.133) with Microsoft SMTP Server id 8.2.247.2; Sat, 24 Mar 2012 18:53:45 -0700 Received: from [10.9.254.220] (unknown [10.9.254.220]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 654E9BC394; Sat, 24 Mar 2012 18:54:20 -0700 (PDT) Message-ID: <4F6E7ACA.7000102@broadcom.com> Date: Sat, 24 Mar 2012 18:54:18 -0700 From: "Stephen [kiwin] PALM" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.28) Gecko/20120306 Lightning/1.0b2 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Brian E Carpenter" References: <061.90de23b8a14a673d9c6b0086ae165167@trac.tools.ietf.org> <4F6BAE40.4020005@gmail.com> <2D09D61DDFA73D4C884805CC7865E6110779AE@GAALPA1MSGUSR9N.ITServices.sbc.com> <4F6E28B3.4090708@gmail.com> In-Reply-To: <4F6E28B3.4090708@gmail.com> X-WSS-ID: 6370A28B3E08849111-01-01 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tjc@ecs.soton.ac.uk" , "homenet@ietf.org" , homenet issue tracker , "STARK, BARBARA H" , "draft-ietf-homenet-arch@tools.ietf.org" Subject: Re: [homenet] #6: Support for arbitrary topologies X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 01:54:35 -0000 IEEE P1905 is one tool that helps in that regard... http://grouper.ieee.org/groups/1905/1/ regards, kiwin On 3/24/2012 1:04 PM, Brian E Carpenter wrote: > Barbara, > > > On 2012-03-25 08:44, STARK, BARBARA H wrote: >>>> #6: Support for arbitrary topologies > > ... >> I don't think it should be a question of trying to stop anybody from doing anything. It's a question of what do we want to make easy (via auto-configuration or minimal configuration like turning something on/off). > ... > (Much good sense deleted) > >> And my experience with users is that they're thrilled if there is "a" way to make things work, that's simple and reasonably intuitive. They aren't stuck on needing all possible ways to work. > > I agree entirely, and it's clear that somebody (not necessarily vendors) > will need to write a simple guide on ways to connect up your homenet. > What we should perhaps worry about is tools (beyond classical loop > prevention in bridging and routing protocols) to detect broken topologies > and tell the user about them in a meaningful way. In other words, > instead of "support" arbitrary topologies, "diagnose" unsupported > topologies. > > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenpalm@alumni.uci.edu palm@broadcom.com s.palm@ieee.org palm@itu.ch spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp From shemant@cisco.com Sat Mar 24 19:16:30 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A34D21E8037 for ; Sat, 24 Mar 2012 19:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.237 X-Spam-Level: X-Spam-Status: No, score=-10.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 WMqhlVezN9Za for ; Sat, 24 Mar 2012 19:16:29 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 54F2E21E8034 for ; Sat, 24 Mar 2012 19:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2020; q=dns/txt; s=iport; t=1332641789; x=1333851389; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ANWTOIDt2q9roMwMmczC95/iEvZprFsPfKF0nlYmDQ4=; b=OXLHhiKxCI5Dr8iOyeGyrPss8ItByevWBCnUWSIBnhzZsjbEhcomnaro z3g6Vb/4r6UmWb7EZs9a93Vyr2FhYd8Yb2atIaygEbtm6SEO0Ncn1fSiM RbsV80fTyKkxakFWuM3GFGZgSxbLKYVNqf4Dfxm8zjEuSXsYqz3mgNdFN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAL1+bk+tJXG+/2dsb2JhbABDDoUxsWSBAIEHggkBAQEEAQEBDwEQDQQ6CwwEAgEIEQQBAQMCBgYXAQICAgEBJR8JCAEBBAESCBqHaAuZQo0IkH6BL45hNWMEiFeOGoojgxGBaIIwVQ X-IronPort-AV: E=Sophos;i="4.73,644,1325462400"; d="scan'208";a="69168187" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 25 Mar 2012 02:16:29 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2P2GS67009490; Sun, 25 Mar 2012 02:16:28 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Mar 2012 21:16:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sat, 24 Mar 2012 21:16:27 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30444B339@XMB-RCD-109.cisco.com> In-Reply-To: <061.0f56e01bdeae967db6e91124c7a45ce1@trac.tools.ietf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [homenet] #8: Proxy or extend? Thread-Index: Ac0HvFG7djdPDYzpSTyZdtCYW1OYzgCcLCBg References: <061.0f56e01bdeae967db6e91124c7a45ce1@trac.tools.ietf.org> From: "Hemant Singh (shemant)" To: "homenet issue tracker" , , X-OriginalArrivalTime: 25 Mar 2012 02:16:28.0669 (UTC) FILETIME=[49823AD0:01CD0A2D] Cc: homenet@ietf.org Subject: Re: [homenet] #8: Proxy or extend? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 02:16:30 -0000 TWFrZSBpdCBwZXItdXNlLWNhc2UgYW5kIHRoZSB1c2UtY2FzZSB0ZWxscyBvbmUgd2hhdCBwcm90 b2NvbCB0byBwcm94eS4gIFRodXMgdGhlIGRlc2lnbiBpcyBmb2N1c2VkIHJhdGhlciB0aGF0IGxv b2tpbmcgYXQgZXZlcnkgcHJvdG9jb2wgb24gdGhlIHBsYW5ldCB0aGF0IHRoZSBDRSBvciB0aGUg aG9tZW5ldCBjb3VsZCB1c2UuIA0KDQpSZWdhcmRzLA0KDQpIZW1hbnQNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IGhvbWVuZXQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmhv bWVuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGhvbWVuZXQgaXNzdWUgdHJhY2tl cg0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyMSwgMjAxMiA3OjQzIFBNDQpUbzogZHJhZnQtaWV0 Zi1ob21lbmV0LWFyY2hAdG9vbHMuaWV0Zi5vcmc7IHRqY0BlY3Muc290b24uYWMudWsNCkNjOiBo b21lbmV0QGlldGYub3JnDQpTdWJqZWN0OiBbaG9tZW5ldF0gIzg6IFByb3h5IG9yIGV4dGVuZD8N Cg0KIzg6IFByb3h5IG9yIGV4dGVuZD8NCg0KIERvIHdlIHdpc2ggdG8gc3RhdGUgYSBwcmVmZXJl bmNlIGZvciBob3cgcHJvdG9jb2xzIHRoYXQgY3VycmVudGx5IHdvcmsNCiB3aXRoaW4gYSBzaW5n bGUgc3VibmV0IGNhbiBiZSBtYWRlIHRvIHdvcmsgd2l0aGluIGEgbXVsdGktc3VibmV0IGhvbWVu ZXQNCiBzaXRlPyAgUHJveGllcyBjb3VsZCBiZSBkZWZpbmVkIGF0IHN1Ym5ldCBib3VuZGFyaWVz IChlLmcuIGFzIHBlciBESENQdjYNCiByZWxheXMpIG9yIHByb3RvY29scyBjb3VsZCBiZSBleHRl bmRlZCB0byBzaXRlIHNjb3BlIChlLmcuIHRoZSByZWNlbnQNCiB4bUROUyBwcm9wb3NhbCkuIE9y IGlzIHRoaXMgYSBwZXItcHJvdG9jb2wgZGVjaXNpb24/DQoNCi0tIA0KLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiBSZXBvcnRlcjog IHRqY0DigKYgIHwgICAgICBPd25lcjogIGRyYWZ0LWlldGYtaG9tZW5ldC1hcmNoQOKApg0KICAg ICBUeXBlOiAgdGFzayAgIHwgICAgIFN0YXR1czogIG5ldw0KIFByaW9yaXR5OiAgbWFqb3IgIHwg IE1pbGVzdG9uZToNCkNvbXBvbmVudDogIGFyY2ggICB8ICAgIFZlcnNpb246DQogU2V2ZXJpdHk6 ICAtICAgICAgfCAgIEtleXdvcmRzOg0KLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGlja2V0IFVSTDogPGh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL3dnL2hvbWVuZXQvdHJhYy90aWNrZXQvOD4NCmhvbWVuZXQgPGh0dHA6Ly90 b29scy5pZXRmLm9yZy9ob21lbmV0Lz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCmhvbWVuZXQgbWFpbGluZyBsaXN0DQpob21lbmV0QGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hvbWVuZXQNCg== From teco@inf-net.nl Sun Mar 25 13:41:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C06B21E8020 for ; Sun, 25 Mar 2012 13:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 E5USrkrcd2ad for ; Sun, 25 Mar 2012 13:41:51 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE93C21E801B for ; Sun, 25 Mar 2012 13:41:50 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1343431eaa.31 for ; Sun, 25 Mar 2012 13:41:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=d/d+Od749dVcxiFLX/wSbBs27fErkEgaWKiq/uyNYFw=; b=Aw0MPM9xRhSTO/fU1bLS8MID2DjjQt3UHnGqXEg5asHcXC8G/MoqM9b7ft2+4GN21I 5ifyVjVZK57sFuZeCIOSN/IIzgSIaXb6gRgyBl9RYNaw0FUp5aJGhbRrvP216AGstxKE IJuMFmjpLbFK4RFpPAWxBIn4JHxmJ+iA7EO7767jxX0/z+hltXKdfz65dKmO38NSIrHq O/7G8mZfAelP0rpNhhtKkyuw93rtn06nnuRKzrmCrQR5FJQST2TJqAXL1plvvwVoPcX6 WsLSACSi7grH3kHDX8cPA5ynd8n7WZN3BMaBmwiVd/u4XifKeoIxXdqNN2y5VxiPO1zp hCPQ== Received: by 10.14.205.67 with SMTP id i43mr2526748eeo.33.1332708109955; Sun, 25 Mar 2012 13:41:49 -0700 (PDT) Received: from [192.168.101.161] (212-123-27-210.iFiber.telenet-ops.be. [212.123.27.210]) by mx.google.com with ESMTPS id d54sm51025255eei.9.2012.03.25.13.40.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Mar 2012 13:41:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <4F6BAA92.8090108@gmail.com> Date: Sun, 25 Mar 2012 22:33:27 +0200 Content-Transfer-Encoding: 7bit Message-Id: <32FF5512-C413-416D-B5C3-8509F877C018@inf-net.nl> References: <061.6a445747e247b219642216b1fa46f68c@trac.tools.ietf.org> <4F6BAA92.8090108@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmDFsf9CxONG5szcYfk6I+oWc6gJi8IQcWi4vSP1pxtTv5FOJH0nWbiwixH2ZQJggfYko6L Cc: homenet issue tracker , tjc@ecs.soton.ac.uk, homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #1: Multihoming support X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:41:52 -0000 Op 22 mrt. 2012, om 23:41 heeft Brian E Carpenter het volgende geschreven: > On 2012-03-22 12:24, homenet issue tracker wrote: >> #1: Multihoming support >> >> Currently the -02 arch text talks about multihoming in MH2, MH7, MH8, RT11 >> and RT12. We say that single CER, multiple uplink multihoming is >> supported, but multi-CER, multiple uplink multihoming is only desirable. >> Do we want to make the latter a requirement as well, or "strongly >> desirable"? > > To confirm what I've already said: I think multi-CER with *one* uplink > per CER will be a common scenario (tens or hundreds of millions of > cases) and needs to be covered. A single CER with multi-uplink will > also be common. Maybe multi-CER with multi-uplink per CER can be deferred. +1 I think the three network models are somewhat over-simplified, ISPs may provide different services. I think we need source routing and source address selection being used to select a service. This relates CER prefix advertisement to service discovery. Teco > > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From teco@inf-net.nl Sun Mar 25 13:46:46 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA58221E8026 for ; Sun, 25 Mar 2012 13:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.158, 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 bOhQTBl4B6hY for ; Sun, 25 Mar 2012 13:46:46 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B60D821E801A for ; Sun, 25 Mar 2012 13:46:45 -0700 (PDT) Received: by eeke51 with SMTP id e51so1376129eek.31 for ; Sun, 25 Mar 2012 13:46:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer:x-gm-message-state; bh=9684+wiyR+XWrl4/1mIfPvFZLC+k7ryj+T4MHCvyd7U=; b=VQZ2nwFIw+0lUQDNJkOUvbAdTvOANlO1tOpVcQrDsgzKZayyqZQCCWOhh5zkC3xYOS kiWqpeMF6U9JJr+krALIvajpsBTz7xXKqD9JkPwAvXKXjrRUmuKcNgKOkYqi+WTbkEXx Y4F+//Sg9YVEA7HpuoGmCjLocm7Sj5lStsS7Oohy16xFK/hn1d9OPX/HGJqG/a+uvBg4 dVj9fM4oMlgzjV3m85sIAbA4yR0YF5r8kgTBXJ3bCKoISwIJqAkTRhRcKrsU6j2LHw+U grtFmRfTLApjb8UROnj/8Ftbt4//IBiImOdctFmbQLBn6Kw1f4lxslroPTOGN6MJmXUk qtjg== Received: by 10.213.35.133 with SMTP id p5mr1304321ebd.71.1332708404891; Sun, 25 Mar 2012 13:46:44 -0700 (PDT) Received: from [192.168.101.161] (212-123-27-210.iFiber.telenet-ops.be. [212.123.27.210]) by mx.google.com with ESMTPS id n56sm51078515eeb.4.2012.03.25.13.46.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 25 Mar 2012 13:46:44 -0700 (PDT) From: Teco Boot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 25 Mar 2012 22:46:16 +0200 Message-Id: <16122166-F628-48F6-B281-868036536550@inf-net.nl> To: homenet@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlROhOkb5BVr+EVBDXLzRKLHSD12jCUJkfN+feYg8neATUlIpWlHGK6TpuWoafYgHU7IE7x Subject: [homenet] homenet-arch - RT6) - convergence time X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:46:47 -0000 On: > RT6) Minimising convergence time should be a goal in any routed > environment, but as a guideline a maximum convergence time of > a couple of minutes should be the target. I was thinking of a couple of seconds. During tutorials, I found it hard to explain why there is no connectivity when a LED was green. Many users will not wait minutes before taking next steps finding a way to get gear work. That is power cycle several times or take a hammer. Minutes convergence time is yesterdays technology. Teco From frank.denhartog@tno.nl Sun Mar 25 21:26:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB3121E8048 for ; Sun, 25 Mar 2012 21:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 R21qC5Q6I7WT for ; Sun, 25 Mar 2012 21:26:26 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id C161521E8034 for ; Sun, 25 Mar 2012 21:26:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.73,649,1325458800"; d="scan'208";a="66467193" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 26 Mar 2012 06:26:20 +0200 Received: from EXC-MBX01.tsn.tno.nl ([169.254.1.248]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0283.003; Mon, 26 Mar 2012 06:26:20 +0200 From: "Hartog, F.T.H. (Frank) den" To: "'Stephen [kiwin] PALM'" , 'Brian E Carpenter' , "'homenet@ietf.org'" Thread-Topic: [homenet] #6: Support for arbitrary topologies Thread-Index: AQHNCH8jrlWQmMqJLUeYcikGxA7YVpZ5jqnAgABCGoCAAGHbAIABwi7w Date: Mon, 26 Mar 2012 04:26:20 +0000 Message-ID: <4A80242C19A4CB47987936B106A8BF71076D4FA9@EXC-MBX01.tsn.tno.nl> References: <061.90de23b8a14a673d9c6b0086ae165167@trac.tools.ietf.org> <4F6BAE40.4020005@gmail.com> <2D09D61DDFA73D4C884805CC7865E6110779AE@GAALPA1MSGUSR9N.ITServices.sbc.com> <4F6E28B3.4090708@gmail.com> <4F6E7ACA.7000102@broadcom.com> In-Reply-To: <4F6E7ACA.7000102@broadcom.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "'tjc@ecs.soton.ac.uk'" , 'homenet issue tracker' , "'STARK, BARBARA H'" , "'draft-ietf-homenet-arch@tools.ietf.org'" Subject: Re: [homenet] #6: Support for arbitrary topologies X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 04:26:27 -0000 And so is HTIP (ITU G.9973) : http://www.itu.int/rec/T-REC-G.9973-201110-P = . On performance evaluation of topology discovery protocols, see also Erik = Diaz Castellanos et al, IEEE CCNC 2012: http://goo.gl/ldPZj (here applied t= o the legacy protocols LLTD and LLDP (IEEE 802.1AB) ; not yet to IEEE P1905= or G.9973). HGI is requiring topology discovery in their draft standard "R= equirements for home networks service diagnostics", HGI- RWD016-R3: http://www.homegateway.org/documents/release_3.asp . = Kind regards, = Frank -----Original Message----- From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On Behalf = Of Stephen [kiwin] PALM Sent: Sunday, March 25, 2012 3:54 AM To: Brian E Carpenter Cc: tjc@ecs.soton.ac.uk; homenet@ietf.org; homenet issue tracker; STARK, BA= RBARA H; draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #6: Support for arbitrary topologies IEEE P1905 is one tool that helps in that regard... http://grouper.ieee.org/groups/1905/1/ regards, kiwin On 3/24/2012 1:04 PM, Brian E Carpenter wrote: > Barbara, > > > On 2012-03-25 08:44, STARK, BARBARA H wrote: >>>> #6: Support for arbitrary topologies > > ... >> I don't think it should be a question of trying to stop anybody from doi= ng anything. It's a question of what do we want to make easy (via auto-conf= iguration or minimal configuration like turning something on/off). > ... > (Much good sense deleted) > >> And my experience with users is that they're thrilled if there is "a" wa= y to make things work, that's simple and reasonably intuitive. They aren't = stuck on needing all possible ways to work. > > I agree entirely, and it's clear that somebody (not necessarily = > vendors) will need to write a simple guide on ways to connect up your hom= enet. > What we should perhaps worry about is tools (beyond classical loop = > prevention in bridging and routing protocols) to detect broken = > topologies and tell the user about them in a meaningful way. In other = > words, instead of "support" arbitrary topologies, "diagnose" = > unsupported topologies. > > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- = Stephen [kiwin] Palm Ph.D. E: palm@kiwin.com Senior Technical Director T: +1-949-926-PALM Broadcom Broadband Communications Group F: +1-949-926-7256 Irvine, California W: http://www.kiwin.com Secondary email accounts: stephenpalm@alumni.uci.edu palm@broadcom.com s.= palm@ieee.org palm@itu.ch spalm@cs.cmu.edu palm@ics.t.u-tokyo.ac.jp _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From robert.cragie@gridmerge.com Mon Mar 26 03:22:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB7621F8522 for ; Mon, 26 Mar 2012 03:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 5y4WUvX8T9kX for ; Mon, 26 Mar 2012 03:22:58 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 34C4221F84B6 for ; Mon, 26 Mar 2012 03:22:58 -0700 (PDT) Received: from client-86-25-39-116.midd-bam-1.adsl.virginmedia.com ([86.25.39.116] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SC74d-0006P8-Fm for homenet@ietf.org; Mon, 26 Mar 2012 11:22:55 +0100 Message-ID: <4F7043E5.3090706@gridmerge.com> Date: Mon, 26 Mar 2012 11:24:37 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: homenet@ietf.org References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020002090401070508090709" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 10:23:00 -0000 This is a cryptographically signed message in MIME format. --------------ms020002090401070508090709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable (catching up on the homenet ML...) Comments inline, bracketed by Robert On 14/03/2012 5:11 AM, Cameron Byrne wrote: > On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan wro= te: >> On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote: >> >> >>> That's reality, and much as I love the e2e principle I think the ordi= nary >>> citizen is better off behind default-deny. >>> >> I am not trying to be dense, but why? >> >> What is the negative scenario of not having a homenet firewall on? Usi= ng >> real examples from the last 5 years .... I would like to know how a cp= e >> firewall protects against real threats to modern software. >> >> It seems hard to predict a priori what a "real threat" is going to be.= And >> it seems unlikely that "modern software" is all that will be found in >> average homes. For example, will the Android version on the refrigerat= or >> display be updated? >> > Agreed about a priori. BUT! what else do we have to go on? I am > asking for a baseline to justify why a CPE firewall is required. In > fact, i have asked for it multiple times on this thread, and all i get > back is anecdotal hand waving, not technical reasons. > > Putting the E back in IETF, let's see some data about why this > function of the system must exist. > > My cursory research says you are not going to be able to present a > convincing amount of data to support the fact that a stateful > inspection firewall should be applied in a contemporary home > environment. I believe the spirit of Homenet is moving the internet > forward without being beholden to the Morris worm and X.25 > > You mention Android running on the refrigerator, as if i am supposed > to be concerned about that? Can you cite an example of an Android > security flaw that a CPE firewall would have ever prevented? My > guess is no, android does not listen on any ports (default > non-root)... thus no inbound connections... thus... stateful firewall > does not have a technical justification for obstructing e2e flows. That may indeed be the way devices work now (client only, pulling=20 information or setting up some arcane push mechanism) but in the future=20 we are much more likely to see devices running server communicating P2P=20 or asynchronously. Therefore these devices will be listening on ports,=20 and these devices may well need to be reached from outside the CP zone. > > If you want to talk about rooted devices running BIND 4.0, well... > that person that is wise enough to manually do that i likely wise > enough to allow the relevant firewall rules or PCP interactions to > allow the bad guys in as well. > >>> Personally I haven't run without an on-board firewall since I got my >>> first wireless card (late 1999?). But we can't assume that applies to= >>> every home device. >>> >> Most PC software has shipped with a firewall on for the last ~10 years= >> >> And these have to be then managed, and the triggers for "should this f= low be >> allowed" will then transition to the PC as opposed to the CPE. Did the= >> system become any simpler, really? >> > I think there is some 3rd party off the shelf software that does these > pop-ups.... but the PCs i run with native firewalls have never popped > up to me like that. But, i agree... pop ups are not helpful. > > As an end user, i can proudly say i have a host based firewalls, but i > have not once ever administered one (except sometimes i turn off the > FW so i can ping my PC) > >> But the real issue to my mind is _non-PC_ software; the firmware on so= me >> power-line bridge written for the cheapest dollar by pulling together = some >> version of Linux because the device had to sell for $25. Not only do a= ll >> these devices now need firewalls (unlikely), they now need an easy way= to >> manage these firewalls (next to impossible). >> > power-line bridge? > > Once again, please paint for me a realistic scenario of how a CPE > firewall will protect this device? > > My first statement is that this device should not have a globally > routable address, and therefore is not exposed to the internet, and > does not need the CPE to filter for it. This is a good case for ULA > in IPv6. So by using ULAs, you have a clear demarcation point for the CP=20 zone. I am not sure what the problem is in allowing policing at this=20 demarcation point to make the attack surface lower (Fred's "threading=20 two needles"). I also agree with Fred's statement that the primary=20 purpose of a firewall is for defending the bandwidth in the defended=20 domain. Sure, there is additional administration but it is much more=20 feasible to administer at a CPE router than a device which may have no=20 UI on it at all (e.g the pool pump controller) > > Second, crappy software should not be tolerated or compensated for in > Homenet. Setting the president that flawed software is acceptable is > a slippery slope to somewhere bad. If it takes making application and > host security requirements for endpoint, so be it. Passing the buck > to the CPE/Firewall to give the illusion of security is not the right > path. Tolerating broken software is also not the right path. I don't think anyone is proposing the use of a firewall as sticking = plaster for crappy software but there has never been anything wrong with = a belt 'n' braces approach. > > Homenet is a unique opportunity to restore end to end ... or as some > would say... the internet model.. Smart end points, dumb network. Some of these end points may not have the resources to be that=20 smart. We can't preclude these from homenet. > > If we need a smart network, then lets make a real solid fact based > exploration of threats and then we can select the appropriate > compensating security controls. > > CB > >> -Ashok >> >> Cb >>> Brian >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> >> > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --------------ms020002090401070508090709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMyNjEwMjQzN1owIwYJKoZI hvcNAQkEMRYEFJLTKBaVZba9qGiMaEkdyBWsLZx+MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQA3tGK0h7uVb4UBYlOCA+OG ngDyobQ7POnzvTWHjpYz3UscD2UXrle+Gfp1emTsnmrEAKTlWkclvj4cbcnm0oY+KWyLw0/c ObAz73oALRNEpyNrn7gUYVwt1O/PZlES3wdd0EFMdzn7FXNMFvXcxEJVFlQNe4ilDy1Klj/9 El17Np9r5dKy7KakMTY+W48nvGNZ/SeqO8QvXLhhngo3oKpDWaAUHztSehZnUL6OdT7VVOT4 MF4g0q1D/nrOglC2VNrZ9NKF3bJUHy9AyrPNXm+L8uIKmTasIxbU6mabkTnsIOn2sp8z7NK3 TO0U0p7gXl8reladGqHBJWolqGSDkWYnAAAAAAAA --------------ms020002090401070508090709-- From Ray.Bellis@nominet.org.uk Mon Mar 26 05:25:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F29C21F873E for ; Mon, 26 Mar 2012 05:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.317 X-Spam-Level: X-Spam-Status: No, score=-10.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 uvBNQF2kTRF6 for ; Mon, 26 Mar 2012 05:25:40 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 74E8121F8726 for ; Mon, 26 Mar 2012 05:25:40 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=mM64DwWaf8ZJ0QBUdJvo9Tj3+Sh3v2pGhZbCDZqxJc//bCt9LhhRoxgw lsPA3MID0WJGz9TNsn+nNMgWUI8fh54+NTC+C7o3gggbyBCNYqe6EoFyr 2t/mScCJpOLBwsn; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1332764740; x=1364300740; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Volunteers=20for=20minute=20takers,=20jabber =20relays?|Date:=20Mon,=2026=20Mar=202012=2012:25:34=20+0 000|Message-ID:=20|To:=20"homenet@ietf.org"=20|MIME-Version:=201.0|Content-Transfer-Encoding:=20quot ed-printable|Content-ID:=20<4bbb50a2-02c1-4a94-b278-fffe3 9a329e5>; bh=F3WmMD7rKZ/nKtfs1Jwsd88GwOmC9HTc51Jy45Isykk=; b=alVoOdIdQdRE2UtAdYVk/7YNT7NfQH5yj+0WJUv+vqAWiQW6fpFgNUYc wkEusa3cd6+2v+UX6g41nnFwYwJ0SNrejn86au/xMUy8pSx05HDi/zDdP ymYIbhOzZl+sMfF; X-IronPort-AV: E=Sophos;i="4.75,320,1330905600"; d="scan'208";a="32195664" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx4.nominet.org.uk with ESMTP; 26 Mar 2012 13:25:38 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Mon, 26 Mar 2012 13:25:38 +0100 From: Ray Bellis To: "homenet@ietf.org" Thread-Topic: Volunteers for minute takers, jabber relays? Thread-Index: AQHNC0uMV8R9JBtVJEe1nIrWy7wT6Q== Date: Mon, 26 Mar 2012 12:25:34 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <4bbb50a2-02c1-4a94-b278-fffe39a329e5> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Volunteers for minute takers, jabber relays? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 12:25:41 -0000 Mark and I would appreciate advance volunteers to take minutes, and to rela= y comments from jabber to the mic. If you're able to help, please let us know soonest so we can save time duri= ng the WG session itself. thanks, Ray From aakhter@cisco.com Tue Mar 27 00:39:01 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C810D21F8776 for ; Tue, 27 Mar 2012 00:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Vg-Cn11UmITl for ; Tue, 27 Mar 2012 00:39:00 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC3921F87A8 for ; Tue, 27 Mar 2012 00:39:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=901; q=dns/txt; s=iport; t=1332833940; x=1334043540; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Spnkldd8wKchPHscs1ZmL7JiZ36lkL8Fdp0zxtrbNlY=; b=mCmlYi/ORZHSDP9xF/PZrP/YmnHCgKVJw/FrMOSohMpIwHG5NM/ChcrS venHm54wzQg4tumUjhBVk3fq7M4eouaBfttTQIqSPPYyRVIMFTUoBVa1P Wy/RWBYWKXV7sSPK7VwsDm6NZXcZjiHJDZhParkfZsx3tHw15RMJx01Ll U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMIAGhucU+tJXG//2dsb2JhbABEgw6yKIMSgQeCCQEBAQMBEgElQAEQCxgJFAIPCQMCAQIBRQYNAQcBAR6HYwWaR58XkQ8ElWGFb4hWgWiDAw X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="69677525" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 27 Mar 2012 07:39:00 +0000 Received: from [10.81.8.159] (rtp-vpnasa1-159.cisco.com [10.81.8.159]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2R7cxSr016807; Tue, 27 Mar 2012 07:38:59 GMT Message-ID: <4F716E91.3040709@cisco.com> Date: Tue, 27 Mar 2012 03:38:57 -0400 From: Aamer Akhter User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Teco Boot References: <16122166-F628-48F6-B281-868036536550@inf-net.nl> In-Reply-To: <16122166-F628-48F6-B281-868036536550@inf-net.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] homenet-arch - RT6) - convergence time X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:39:01 -0000 On 3/25/2012 4:46 PM, Teco Boot wrote: > > On: >> RT6) Minimising convergence time should be a goal in any routed >> environment, but as a guideline a maximum convergence time of >> a couple of minutes should be the target. > > I was thinking of a couple of seconds. The 'several minutes' scope was interesting. It would be good to sate why the thinking is several minutes (or is it only for a specific portion of the network). My feeling is that most folks are looking for visual feedback of some kind but also sub-minute convergence. > > During tutorials, I found it hard to explain why there is no > connectivity when a LED was green. Many users will not wait > minutes before taking next steps finding a way to get gear work. > That is power cycle several times or take a hammer. > Minutes convergence time is yesterdays technology. > > Teco From aakhter@cisco.com Tue Mar 27 00:59:19 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85FE21F8800 for ; Tue, 27 Mar 2012 00:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.932 X-Spam-Level: X-Spam-Status: No, score=-109.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 YyMxxajxhbd3 for ; Tue, 27 Mar 2012 00:59:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id E6F0321F87F5 for ; Tue, 27 Mar 2012 00:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=aakhter@cisco.com; l=3428; q=dns/txt; s=iport; t=1332835159; x=1334044759; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=5HUJmVwZ07Ank4NictUWED3KEC/1oCWKRbC6rocIKiE=; b=hMKc6c4tvgaei8faB1ntpmqomsiuzaThhY9qwi/KYsh/bVOO0ObeBYvD 3Z7MvaJM2hzdlIEHANAHwxmrK8ePxN0GOb4aLTAYrzF8ViPwIwTt0ad6L ZjjWEzWq3ssvLqPRincpnuOXUQaxFhuyEinlP8z0jJVKKT+9KRXW6uvJ+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOdycU+tJV2b/2dsb2JhbABEuEiBB4IJAQEBBBIBHQpLBAIBCBEBAgECCwYYBgFFAwYIAQEEEwgBGYdoC5o9nxaKYoVKYwSIWIklkimBaIMFgTY X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="69680582" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 27 Mar 2012 07:59:18 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2R7xIgl021828 for ; Tue, 27 Mar 2012 07:59:18 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 02:59:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2012 02:59:14 -0500 Message-ID: <7F298ACC76CC154F832B6D02852D169F078D5B3C@XMB-RCD-101.cisco.com> In-Reply-To: <4F717066.8060703@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-ietf-homenet-arch-02.txt thread-index: Ac0L7cS4iBIvASkMRpy6oFWKLGJFzAAABfbQ References: <20120312221619.9612.79497.idtracker@ietfa.amsl.com> <4F717066.8060703@cisco.com> From: "Aamer Akhter (aakhter)" To: X-OriginalArrivalTime: 27 Mar 2012 07:59:18.0350 (UTC) FILETIME=[82D1F6E0:01CD0BEF] Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:59:20 -0000 A few minor comments on homenet-arch-02. I did a quick search of the archive and did not see these mentioned, apologies if the discussion has already taken place. Sec 3.1 Regarding homepna / homewire / MoCA / wireless bridging of architecture: there may be different and in some cases, changing bandwidth constraints imposed on parts of an L2 domain. Is this within the homenet problem domain? Or is QoS/bandwidth-management really limited to the CER? sec 3.4.2 -=20 "Some current devices work well with dual-stack but fail to recognize connectivity when IPv4 DHCP fails, for instance.".=20 Does this refer to IPv6 connectivity that continues to work? (I believe so, but it's unclear). Section 3.4.7 " ZC5) It is important that self-configuration with "unintended" devices is avoided. Methods are needed for devices to know whether they are intended to be part of the same homenet site or not." -=20 Can an example be provided? Are we talking about two completely separate networks (effectively different sites)? How does this relate to overall goal of no manual configuration? Sec 3.4.11 "The home network may receive an arbitrary length IPv6 prefix from its provider, e.g. /60 or /56. The offered prefix may be stable over time or change from time to time. "=20 It is unclear if only the prefix, or also the prefix-length would also be changing. Do we need to worry about both cases? -------- Original Message -------- Subject: I-D Action: draft-ietf-homenet-arch-02.txt Date: Mon, 12 Mar 2012 15:16:19 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: homenet@ietf.org Newsgroups: gmane.ietf.announce,gmane.ietf.homenet A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Architecture for IPv6 Author(s) : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-02.txt Pages : 36 Date : 2012-03-12 This text describes evolving networking technology within small residential home networks. The goal of this memo is to define the architecture for IPv6-based home networking and the associated principles, considerations and requirements. The text briefly highlights the implications of the introduction of IPv6 for home networking, discusses topology scenarios, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-homenet-arch-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-homenet-arch-02.txt From jari.arkko@piuha.net Tue Mar 27 13:01:59 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868E021E8156 for ; Tue, 27 Mar 2012 13:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.094 X-Spam-Level: X-Spam-Status: No, score=-101.094 tagged_above=-999 required=5 tests=[AWL=-1.395, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MANGLED_PAIN=2.3, USER_IN_WHITELIST=-100] 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 D6pkyQWQAYXH for ; Tue, 27 Mar 2012 13:01:58 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 8626D21E814F for ; Tue, 27 Mar 2012 13:01:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D30892D35A; Tue, 27 Mar 2012 23:01:57 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fktR22cMUQ8w; Tue, 27 Mar 2012 23:01:56 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9061F2CC56; Tue, 27 Mar 2012 23:01:56 +0300 (EEST) Message-ID: <4F721CB4.6000501@piuha.net> Date: Tue, 27 Mar 2012 22:01:56 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ray Hunter References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6B2DF7.30500@globis.net> In-Reply-To: <4F6B2DF7.30500@globis.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: tjc@ecs.soton.ac.uk, homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 20:01:59 -0000 I fully agree with these comments from Ray. Basically, when hardware chan= ges on some router it is pretty much given that some address will change = somewhere. And I don't think fully stable addressing is a good goal to be= gin with. Make the devices survive addressing changes, and we'll be fine.= Initial ULA generation before any connectivity with the Internet can be r= eached is fine, however. Jari On 22.03.2012 14:49, Ray Hunter wrote: > As requested by Tim: My comments on ULA use in Homenet posted in consol= idated manner to the issue tracker. > > I think Homenet still has a lot of work to do, especially due to the au= toconfig requirements. > > Everyone wants autoconfig. > > Concurrent ULA + PA + both with autoconfig + invariant addresses is lik= ely going to be tough, if not downright impossible. > > So why do we think we really need concurrent ULA+PA in Homenet as a bas= e requirement? I'm not entirely convinced yet. > > > Issue 1: One reason ULA seems to be mentioned is "time-invariance of ad= dressing for use by sensor networks." > > Using the example of an electrician setting up a sensor network in a ho= me before an ISP is present, and expecting time-invariant ULA addresses. = Firstly, the electrician would have to generate a Global ID for ULA when = the lights are installed. The electrician can generate a unique Global I= D (and hence the /48 prefix of ULA) using the procedure in RFC4193. > > Problems with this are: > 1) The /48 ULA prefix is tied to a time (when the electrician pressed t= he "generate ULA" button) > If a user regenerates the ULA prefix later, the algorithm will generate= a different /48 prefix: all addresses in the house will change > > 2) The /48 ULA prefix is tied to a MAC address (of the router or device= used to seed the ULA prefix generation algorithm) > If a user changes router hardware, the /48 prefix will change. Or else = the seed stored in non-volatile memory will be lost when hardware is repl= aced. Again all addresses in the house will change > > 3) The Global ID portion of the ULA has to be manually assigned to each= of the routers (if there's more than one) as there's no mechanism to dis= tribute Global IDs today. > Homenet needs autoconfiguration. > > 4) Even if the /48 prefix is made invariant, the /64 LAN prefix generat= ed from it probably won't be invariant as hardware is added, replugged or= removed. > Again, OK for manual configuration like an enterprise network, but Home= net wants autoconfig. > > I don't see how "complete time-invariance of addressing" is achievable= together with autoconfig, even if we call for an equivalent site-local a= ddressing with a fixed /48 prefix that is common to all Homenet implement= ations everywhere. We've been down that rathole before. Site-local has be= en deprecated in RFC3879. And realistically speaking, any time someone re= places or adds or re-plugs any router hardware, the LAN's /64 prefix will= change when using autoconfig. > > > I think it would be useful for the Homenet WG to propose a scheme for s= ensor networks to be able to maintain simple peerings despite the presenc= e of time-variant addressing [whether these are ULA, PA, PI, IPv4 or what= ever]. In fact, it would seem to me that a peering solution should use so= mething that is long-term invariant as an identifier for keying the peeri= ng e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at a= ll. The invariant identifier could be automatically registered by each se= nsor as a name in the Homenet naming service. Peers could resolve that na= me to the current IPv6 address and then verify the peering using their ow= n protocol like HMAC_MD5 with a shared secret (RFC2104). Loss of connecti= on would trigger a new address resolution, reconnection, and peer check. = Agreeing the shared secret is peering specific (and has to be solved anyw= ay even with fixed addresses). I have an asterisk hardware phone that doe= s something similar to this, so it can't=20 > require much code. > > > > > Issue 2: Use of multiple ULA Global ID's in Homenet may also cause prob= lems with source address selection (3484-revise). There is no way to know= which ULA's are connected to the local Homenet, and which are distribute= d on remote Homenets spread over the Internet. This causes problems with = potential ULA leakage, and in determining priority between PA-derived add= resses and ULA addresses when both are available and the default 3484 or = 3484-revise rules are followed. > > A workaround might be to be redistribute a non-default RFC3484-revise p= olicy table to all end nodes via draft-fujisaki-dhc-addr-select-opt-07, b= ut its not clear that all end nodes will support this mechanism, nor how = the contents of the policy table would be managed in a distributed and au= tomated manner. > > > Issue 3: A reason concurrent ULA+PA seems to be required was that "intr= a-homenet communication should survive a long term ISP outage, and must b= e able to be established without any ISP connection present." > > The first linkage would appear to be when ISP PA-derived prefixes withi= n Homenet timeout via DHCPv6 PD meaning that a long-running session based= on this address would drop. That has nothing directly to do with ULA, an= d may have other solutions. > > Question: How long are ISP's setting their DHCPv6 PD timers in practice= ? Simply recommending very long timers for the DHCPv6 PD PA-derived prefi= x might be a practical solution. How often has your ISP connection been d= own for say 10 days? > > Another solution might be for the application to reconnect using anothe= r PA-derived address (if the user has two providers). > > > The second linkage may also have other solutions, such as only configur= ing a ULA prefix when no PA-derived prefixes are present. > > That would mean at any one time the Homenet could potentially be runnin= g either ULA or multiple PA, but not both, which completely avoids any ad= dress selection conflicts and having to redistribute new RFC3484 address = selection rules to all nodes. Simply put: "Please reboot or reconnect to = fix any problems." > > > regards, > RayH > > > homenet issue tracker wrote: >> #4: Use of ULAs >> >> CN1 in the -02 text says ULAs should be provisioned by default. Do = we >> agree? And if so, should they be preferred over globals? The new >> 3484-bis has changed so they are not *unless* a specific /48 for the= site >> is added to the 3484 policy table with higher precedence than global= s. We >> should design something that works when disconnected from the Intern= et. >> Also, we currently say nothing about ULA-only devices and their >> reachability from outside the homenet; do we want to? >> > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From dave.taht@gmail.com Tue Mar 27 13:21:54 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C80E21E803C for ; Tue, 27 Mar 2012 13:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 QKUaDCzRufu5 for ; Tue, 27 Mar 2012 13:21:52 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7816721E8086 for ; Tue, 27 Mar 2012 13:21:50 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so207250wgb.13 for ; Tue, 27 Mar 2012 13:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C//Nl8BZuifq+yt/eN8/aoxSlrzp3t/QQ1X6BUAT9Is=; b=ssRGnRk8bhiLcGbtdBzl7fFcswqOKiEy2tTCQW7YCC3U2plIKDvZHKHhFXtUWae8Gj 7avOofx4WxguA64vsuSEnZ0endx4n40FHNw4GGHUV07BZ1WuQDD7vc4G2ac8P79yi32k 8tyGZTOb2NbVY3bzD9NVCFmG5btIAaaEr7waDp7UpPhmm81g4D8Olhzb0Arl94QQ7xI/ ns4Iks+pSKe0sagTAr9OEMEZ3qgGJ9VJV0W7gIjzM1bFyjMqIp3o7FHTaJvQg5m4Bv+W wzE5caKHRL/sc/0VqpLQjrDOihsBM34/MVJwBqsaVuUQaka6/h6hT6yn0e2YahnpYy+Q UunQ== MIME-Version: 1.0 Received: by 10.216.196.29 with SMTP id q29mr3370348wen.12.1332879705817; Tue, 27 Mar 2012 13:21:45 -0700 (PDT) Received: by 10.223.127.194 with HTTP; Tue, 27 Mar 2012 13:21:45 -0700 (PDT) In-Reply-To: <4F721CB4.6000501@piuha.net> References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6B2DF7.30500@globis.net> <4F721CB4.6000501@piuha.net> Date: Tue, 27 Mar 2012 13:21:45 -0700 Message-ID: From: Dave Taht To: Jari Arkko Content-Type: multipart/alternative; boundary=001636c599e864c3ea04bc3f3dfd Cc: Ray Hunter , tjc@ecs.soton.ac.uk, homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 20:21:54 -0000 --001636c599e864c3ea04bc3f3dfd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 27, 2012 at 1:01 PM, Jari Arkko wrote: > I fully agree with these comments from Ray. Basically, when hardware > changes on some router it is pretty much given that some address will > change somewhere. And I don't think fully stable addressing is a good goa= l > to begin with. Make the devices survive addressing changes, and we'll be > fine. > > Initial ULA generation before any connectivity with the Internet can be > reached is fine, however. > > While I agree that having a ULA at the getgo is a goodness, following RFC4193 to the letter is very difficult. 1) You need time. If you do not have a battery backed up clock in the device (set to an appropriate value), you need to get time from the internet, which you can't do until you are on the internet. Or you could mandate time come from a gps. If you are getting time from the internet, you need sntp, ntp, or equivalent. From gps, something like chronyd. Without this, generating the ULA is generally going to come from 'time since the epoch or build date', and other sorts of randomness would be useful. 2) The infrastructure mandated by that RFC requires a sha-1 digest. Many devices (at least at present) do not come with a SSL based infrastructure from which that is a single function thereof. 3) It is my hope that hardware based RNGs start showing up soon in many more devices. But thus far, no luck, so finding an essential source of randomness would be good. 4) Lastly, without a solid means of getting the ULA and a human usable name out to the users's dns system (be that mdns, normal dns, etc), there is no way to map the idea of that number to a presentation that a user can 'just use'. I could be humorous about this (As april 1st is coming up) - flashing the blinking lights on a switch or router in baudot code might suffice for some, but... > Jari > > > On 22.03.2012 14:49, Ray Hunter wrote: > >> As requested by Tim: My comments on ULA use in Homenet posted in >> consolidated manner to the issue tracker. >> >> I think Homenet still has a lot of work to do, especially due to the >> autoconfig requirements. >> >> Everyone wants autoconfig. >> >> Concurrent ULA + PA + both with autoconfig + invariant addresses is >> likely going to be tough, if not downright impossible. >> >> So why do we think we really need concurrent ULA+PA in Homenet as a base >> requirement? I'm not entirely convinced yet. >> >> >> Issue 1: One reason ULA seems to be mentioned is "time-invariance of >> addressing for use by sensor networks." >> >> Using the example of an electrician setting up a sensor network in a hom= e >> before an ISP is present, and expecting time-invariant ULA addresses. >> Firstly, the electrician would have to generate a Global ID for ULA when >> the lights are installed. The electrician can generate a unique Global = ID >> (and hence the /48 prefix of ULA) using the procedure in RFC4193. >> >> Problems with this are: >> 1) The /48 ULA prefix is tied to a time (when the electrician pressed th= e >> "generate ULA" button) >> If a user regenerates the ULA prefix later, the algorithm will generate = a >> different /48 prefix: all addresses in the house will change >> >> 2) The /48 ULA prefix is tied to a MAC address (of the router or device >> used to seed the ULA prefix generation algorithm) >> If a user changes router hardware, the /48 prefix will change. Or else >> the seed stored in non-volatile memory will be lost when hardware is >> replaced. Again all addresses in the house will change >> >> 3) The Global ID portion of the ULA has to be manually assigned to each >> of the routers (if there's more than one) as there's no mechanism to >> distribute Global IDs today. >> Homenet needs autoconfiguration. >> >> 4) Even if the /48 prefix is made invariant, the /64 LAN prefix generate= d >> from it probably won't be invariant as hardware is added, replugged or >> removed. >> Again, OK for manual configuration like an enterprise network, but >> Homenet wants autoconfig. >> >> I don't see how "complete time-invariance of addressing" is achievable >> together with autoconfig, even if we call for an equivalent site-local >> addressing with a fixed /48 prefix that is common to all Homenet >> implementations everywhere. We've been down that rathole before. Site-lo= cal >> has been deprecated in RFC3879. And realistically speaking, any time >> someone replaces or adds or re-plugs any router hardware, the LAN's /64 >> prefix will change when using autoconfig. >> >> >> I think it would be useful for the Homenet WG to propose a scheme for >> sensor networks to be able to maintain simple peerings despite the prese= nce >> of time-variant addressing [whether these are ULA, PA, PI, IPv4 or >> whatever]. In fact, it would seem to me that a peering solution should u= se >> something that is long-term invariant as an identifier for keying the >> peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 addres= s >> at all. The invariant identifier could be automatically registered by ea= ch >> sensor as a name in the Homenet naming service. Peers could resolve that >> name to the current IPv6 address and then verify the peering using their >> own protocol like HMAC_MD5 with a shared secret (RFC2104). Loss of >> connection would trigger a new address resolution, reconnection, and pee= r >> check. Agreeing the shared secret is peering specific (and has to be sol= ved >> anyway even with fixed addresses). I have an asterisk hardware phone tha= t >> does something similar to this, so it can't require much code. >> >> >> >> >> Issue 2: Use of multiple ULA Global ID's in Homenet may also cause >> problems with source address selection (3484-revise). There is no way to >> know which ULA's are connected to the local Homenet, and which are >> distributed on remote Homenets spread over the Internet. This causes >> problems with potential ULA leakage, and in determining priority between >> PA-derived addresses and ULA addresses when both are available and the >> default 3484 or 3484-revise rules are followed. >> >> A workaround might be to be redistribute a non-default RFC3484-revise >> policy table to all end nodes via draft-fujisaki-dhc-addr-**select-opt-0= 7, >> but its not clear that all end nodes will support this mechanism, nor ho= w >> the contents of the policy table would be managed in a distributed and >> automated manner. >> >> >> Issue 3: A reason concurrent ULA+PA seems to be required was that >> "intra-homenet communication should survive a long term ISP outage, and >> must be able to be established without any ISP connection present." >> >> The first linkage would appear to be when ISP PA-derived prefixes within >> Homenet timeout via DHCPv6 PD meaning that a long-running session based = on >> this address would drop. That has nothing directly to do with ULA, and m= ay >> have other solutions. >> >> Question: How long are ISP's setting their DHCPv6 PD timers in practice? >> Simply recommending very long timers for the DHCPv6 PD PA-derived prefix >> might be a practical solution. How often has your ISP connection been do= wn >> for say 10 days? >> >> Another solution might be for the application to reconnect using another >> PA-derived address (if the user has two providers). >> >> >> The second linkage may also have other solutions, such as only >> configuring a ULA prefix when no PA-derived prefixes are present. >> >> That would mean at any one time the Homenet could potentially be running >> either ULA or multiple PA, but not both, which completely avoids any >> address selection conflicts and having to redistribute new RFC3484 addre= ss >> selection rules to all nodes. Simply put: "Please reboot or reconnect to >> fix any problems." >> >> >> regards, >> RayH >> >> >> homenet issue tracker wrote: >> >>> #4: Use of ULAs >>> >>> CN1 in the -02 text says ULAs should be provisioned by default. Do we >>> agree? And if so, should they be preferred over globals? The new >>> 3484-bis has changed so they are not *unless* a specific /48 for the >>> site >>> is added to the 3484 policy table with higher precedence than globals. >>> We >>> should design something that works when disconnected from the Internet= . >>> Also, we currently say nothing about ULA-only devices and their >>> reachability from outside the homenet; do we want to? >>> >>> ______________________________**_________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/**listinfo/homenet >> >> > > ______________________________**_________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/**listinfo/homenet > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net --001636c599e864c3ea04bc3f3dfd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 27, 2012 at 1:01 PM, Jari Ar= kko <jari.arkk= o@piuha.net> wrote:
I fully agree with these comments from Ray. Basically, when hardware change= s on some router it is pretty much given that some address will change some= where. And I don't think fully stable addressing is a good goal to begi= n with. Make the devices survive addressing changes, and we'll be fine.=

Initial ULA generation before any connectivity with the Internet can be rea= ched is fine, however.


While I agree that having a ULA at = the getgo is a goodness, following RFC4193 to the letter is very difficult.=

1) You need time. If you do not have a battery backed up clock in t= he device (set to an appropriate value), you need to get time from the inte= rnet, which you can't do until you are on the internet.

Or you could mandate time come from a gps.

If you are getting t= ime from the internet, you need sntp, ntp, or equivalent. From gps, somethi= ng like chronyd.

Without this, generating the ULA is generally going= to come from 'time since the epoch or build date', and other sorts= of randomness would be useful.

2) The infrastructure mandated by that RFC requires a sha-1 digest. Man= y devices (at least at present) do not come with a SSL based infrastructure= from which that is a single function thereof.

3) It is my hope that= hardware based RNGs start showing up soon in many more devices. But thus f= ar, no luck, so finding an essential source of randomness would be good.
4) Lastly, without a solid means of getting the ULA and a human usable = name out to the users's dns system (be that mdns, normal dns, etc), the= re is no way to map the idea of that number to a presentation that a user c= an 'just use'. I could be humorous about this (As april 1st is comi= ng up) - flashing the blinking lights on a switch or router in baudot code = might suffice for some, but...
=A0
Jari


On 22.03.2012 14:49, Ray Hunter wrote:
As requested by Tim: My comments on ULA use in Homenet posted in consolidat= ed manner to the issue tracker.

I think Homenet still has a lot of work to do, especially due to the autoco= nfig requirements.

Everyone wants autoconfig.

Concurrent ULA + PA + both with autoconfig + invariant addresses is likely = going to be tough, if not downright impossible.

So why do we think we really need concurrent ULA+PA in Homenet as a base re= quirement? I'm not entirely convinced yet.


Issue 1: One reason ULA seems to be mentioned is "time-invariance of a= ddressing for use by sensor networks."

Using the example of an electrician setting up a sensor network in a home b= efore an ISP is present, and expecting time-invariant ULA addresses. Firstl= y, the electrician would have to generate a Global ID for ULA when the ligh= ts are installed. The electrician can generate a =A0unique Global ID (and h= ence the /48 prefix of ULA) using the procedure in RFC4193.

Problems with this are:
1) The /48 ULA prefix is tied to a time (when the electrician pressed the &= quot;generate ULA" button)
If a user regenerates the ULA prefix later, the algorithm will generate a d= ifferent /48 prefix: all addresses in the house will change

2) The /48 ULA prefix is tied to a MAC address (of the router or device use= d to seed the ULA prefix generation algorithm)
If a user changes router hardware, the /48 prefix will change. Or else the = seed stored in non-volatile memory will be lost when hardware is replaced. = Again all addresses in the house will change

3) The Global ID portion of the ULA has to be manually assigned to each of = the routers (if there's more than one) as there's no mechanism to d= istribute Global IDs today.
Homenet needs autoconfiguration.

4) Even if the /48 prefix is made invariant, the /64 LAN prefix generated f= rom it probably won't be invariant as hardware is added, replugged or r= emoved.
Again, OK for manual configuration like an enterprise network, but Homenet = wants autoconfig.

I don't see how "complete time-invariance of addressing" =A0i= s achievable together with autoconfig, even if we call for an equivalent si= te-local addressing with a fixed /48 prefix that is common to all Homenet i= mplementations everywhere. We've been down that rathole before. Site-lo= cal has been deprecated in RFC3879. And realistically speaking, any time so= meone replaces or adds or re-plugs any router hardware, the LAN's /64 p= refix will change when using autoconfig.


I think it would be useful for the Homenet WG to propose a scheme for senso= r networks to be able to maintain simple peerings despite the presence of t= ime-variant addressing [whether these are ULA, PA, PI, IPv4 or whatever]. I= n fact, it would seem to me that a peering solution should use something th= at is long-term invariant as an identifier for keying the peering e.g. EUI-= 64 a.k.a. MAC BIA or DHCP DUID, and not the IPv6 address at all. The invari= ant identifier could be automatically registered by each sensor as a name i= n the Homenet naming service. Peers could resolve that name to the current = IPv6 address and then verify the peering using their own protocol like HMAC= _MD5 with a shared secret (RFC2104). Loss of connection would trigger a new= address resolution, reconnection, and peer check. Agreeing the shared secr= et is peering specific (and has to be solved anyway even with fixed address= es). I have an asterisk hardware phone that does something similar to this,= so it can't require much code.




Issue 2: Use of multiple ULA Global ID's in Homenet may also cause prob= lems with source address selection (3484-revise). There is no way to know w= hich ULA's are connected to the local Homenet, and which are distribute= d on remote Homenets spread over the Internet. This causes problems with po= tential ULA leakage, and in determining priority between PA-derived address= es and ULA addresses when both are available and the default 3484 or 3484-r= evise rules are followed.

A workaround might be to be redistribute a non-default RFC3484-revise polic= y table to all end nodes via draft-fujisaki-dhc-addr-select-opt-07, = but its not clear that all end nodes will support this mechanism, nor how t= he contents of the policy table would be managed in a distributed and autom= ated manner.


Issue 3: A reason concurrent ULA+PA seems to be required was that "int= ra-homenet communication should survive a long term ISP outage, and must be= able to be established without any ISP connection present."

The first linkage would appear to be when ISP PA-derived prefixes within Ho= menet timeout via DHCPv6 PD meaning that a long-running session based on th= is address would drop. That has nothing directly to do with ULA, and may ha= ve other solutions.

Question: How long are ISP's setting their DHCPv6 PD timers in practice= ? Simply recommending very long timers for the DHCPv6 PD PA-derived prefix = might be a practical solution. How often has your ISP connection been down = for say 10 days?

Another solution might be for the application to reconnect using another PA= -derived address (if the user has two providers).


The second linkage may also have other solutions, such as only configuring = a ULA prefix when no PA-derived prefixes are present.

That would mean at any one time the Homenet could potentially be running ei= ther ULA or multiple PA, but not both, which completely avoids any address = selection conflicts and having to redistribute new RFC3484 address selectio= n rules to all nodes. Simply put: "Please reboot or reconnect to fix a= ny problems."


regards,
RayH


homenet issue tracker wrote:
#4: Use of ULAs

=A0CN1 in the -02 text says ULAs should be provisioned by default. =A0Do w= e
=A0agree? =A0And if so, should they be preferred over globals? =A0The new<= br> =A03484-bis has changed so they are not *unless* a specific /48 for the si= te
=A0is added to the 3484 policy table with higher precedence than globals. = We
=A0should design something that works when disconnected from the Internet.=
=A0Also, we currently say nothing about ULA-only devices and their
=A0reachability from outside the homenet; do we want to?

_______________________________________________
homenet mailing list
homenet@ietf.org<= br> https://www.ietf.org/mailman/listinfo/homenet



_______________________________________________
homenet mailing list
homenet@ietf.org<= br> https://www.ietf.org/mailman/listinfo/homenet



--
Dave T=E4ht=
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
--001636c599e864c3ea04bc3f3dfd-- From dave.taht@gmail.com Tue Mar 27 13:28:06 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57FB221E8098 for ; Tue, 27 Mar 2012 13:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zwr0jU-F7RIl for ; Tue, 27 Mar 2012 13:28:05 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7C221E8092 for ; Tue, 27 Mar 2012 13:28:05 -0700 (PDT) Received: by werb10 with SMTP id b10so225997wer.31 for ; Tue, 27 Mar 2012 13:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7wPsDCeEFEOkS/n5U1v3YQo6nvw2N2JwFYqB/6PIZ+o=; b=eqS/iqJ1u9N4rt9TxiGj0zYcybXdYg3l6d3HKzSbZPCWdjsF10j+jUjaZ8EBkufqQ9 aDHMV5fskzky1/a0GqRnxRfyBRpFSAid6OxDXkk19SDz3GGtcjTZFYkRhtSlAkaokyfe Ymcxvop3yiHd0pL/RCJxcXAZGtgRzS8NP6DrPqkDaQbzZlI3jT3tQO52cfzy8lDrsmyH m6LZvnTuvQmHE2hauHRVmvPOx51M+BTTmgUWJdpV0VQvc1sGElXOJtr/gFmpy/YiQC8Z jkOcZederoC3cRX1EE6NVQEKdrMYK5+2DTmjaJgjDAdhPSKDRSA8Y7Dh4mfAqo0szd3P /OlA== MIME-Version: 1.0 Received: by 10.180.94.33 with SMTP id cz1mr883064wib.13.1332880084459; Tue, 27 Mar 2012 13:28:04 -0700 (PDT) Received: by 10.223.127.194 with HTTP; Tue, 27 Mar 2012 13:28:04 -0700 (PDT) In-Reply-To: <4F6BAC9F.10903@gmail.com> References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6BAC9F.10903@gmail.com> Date: Tue, 27 Mar 2012 13:28:04 -0700 Message-ID: From: Dave Taht To: Brian E Carpenter Content-Type: multipart/alternative; boundary=f46d044268e6f660ec04bc3f53ff Cc: homenet issue tracker , tjc@ecs.soton.ac.uk, homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 20:28:06 -0000 --f46d044268e6f660ec04bc3f53ff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 2012-03-22 12:33, homenet issue tracker wrote: > > #4: Use of ULAs > > > > CN1 in the -02 text says ULAs should be provisioned by default. Do we > > agree? > > Yes, by the CER (MUST). > > It's much less clear for all other routers on site. I would prefer that > no other router provisions a ULA prefix if the CER has already delegated > one. > Since it is nearly impossible to learn a subnet prefix that is unused unless all devices share a routing protocol, I have generally preferred to generate unique ULAs per routing device. > > > And if so, should they be preferred over globals? > > Yes. > > This part I don't quite understand. I would prefer global prefixes to always take precedence over ULAs. I'd like ULAs to try to talk only to ULAs. ULAs should not escape into the global DNS, but should end up in local dns. Even with 'happy eyeballs', having a means to disable a ULA -> global connection by default saves 100s of ms in the bad cases. > > The new > > 3484-bis has changed so they are not *unless* a specific /48 for the > site > > is added to the 3484 policy table with higher precedence than globals. > We > > should design something that works when disconnected from the Internet= . > > We'll have to deal with whatever 3484bis ends up saying. If it does > require an explicit policy table entry table, that will require > a mechanism, associated with the prefix delegation mechanism. > OK, I will re-read, thx for the update.. > > Also, we currently say nothing about ULA-only devices and their > > reachability from outside the homenet; do we want to? > > I don't see what there is to say; they aren't reachable, and that's > a feature. > > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net --f46d044268e6f660ec04bc3f53ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 22, 2012 at 3:50 PM, Brian E= Carpenter <brian.e.carpenter@gmail.com> wrote:
On 2012-03-22 12:33, homenet issue tracker wrote:
> #4: Use of ULAs
>
> =A0CN1 in the -02 text says ULAs should be provisioned by default. =A0= Do we
> =A0agree?

Yes, by the CER (MUST).

It's much less clear for all other routers on site. I would prefer that=
no other router provisions a ULA prefix if the CER has already delegated one.

Since it is nearly impossible to learn a subn= et prefix that is unused unless all devices share a routing protocol, I hav= e generally preferred to generate unique ULAs per routing device.
=A0

> =A0And if so, should they be preferred over globals?

Yes.


This part I don't qui= te understand. I would prefer global prefixes to always take precedence ove= r ULAs.
I'd like ULAs to try to talk only to ULAs. ULAs should not e= scape into the global DNS, but should end up in local dns.

Even with 'happy eyeballs', having a means to disable a ULA -&g= t; global connection by default saves 100s of ms in the bad cases.
=A0
> =A0The new
> =A03484-bis has changed so they are not *unless* a specific /48 for th= e site
> =A0is added to the 3484 policy table with higher precedence than globa= ls. We
> =A0should design something that works when disconnected from the Inter= net.

We'll have to deal with whatever 3484bis ends up saying. If it do= es
require an explicit policy table entry table, that will require
a mechanism, associated with the prefix delegation mechanism.

OK, I will re-read, thx for the update.= .
=A0
> =A0Also, we currently say nothing about ULA-only devices and their
> =A0reachability from outside the homenet; do we want to?

I don't see what there is to say; they aren't reachable, and = that's
a feature.

=A0 Brian
_____________________= __________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet



--
Dave T=E4ht=
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
--f46d044268e6f660ec04bc3f53ff-- From therbst@silverspringnet.com Tue Mar 27 14:13:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8FA21E8013 for ; Tue, 27 Mar 2012 14:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=-1.662, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, MANGLED_PAIN=2.3] 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 E985pqqOQgdn for ; Tue, 27 Mar 2012 14:13:04 -0700 (PDT) Received: from it-ipdr-01.silverspringnet.com (it-ipdr-01.silverspringnet.com [74.121.22.27]) by ietfa.amsl.com (Postfix) with ESMTP id A1E7421E801E for ; Tue, 27 Mar 2012 14:12:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAMQsck8KOQxz/2dsb2JhbABFuWyCCQEBAQQBAQEaHTQLEgEIDQseNwslAQEEAQ0FG4d6uiMEkQ8EiFiTGo0j X-IronPort-AV: E=Sophos;i="4.75,328,1330934400"; d="scan'208";a="1313201" Received: from unknown (HELO SFO-EXCA-01.silverspringnet.com) ([10.57.12.115]) by it-ipdr-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 27 Mar 2012 14:12:56 -0700 Received: from IT-EXCA-02.silverspringnet.com (10.200.1.62) by SFO-EXCA-01.silverspringnet.com (10.57.12.100) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 27 Mar 2012 14:12:55 -0700 Received: from IT-RESTORE-01.silverspringnet.com ([::1]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Tue, 27 Mar 2012 14:12:55 -0700 From: Thomas Herbst To: Jari Arkko , Ray Hunter Date: Tue, 27 Mar 2012 14:12:22 -0700 Thread-Topic: [homenet] #4: Use of ULAs Thread-Index: Ac0MXmADSFnu284wRga21O8oqI2kng== Message-ID: In-Reply-To: <4F721CB4.6000501@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tjc@ecs.soton.ac.uk" , Thomas Herbst , "homenet@ietf.org" , "draft-ietf-homenet-arch@tools.ietf.org" Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:13:05 -0000 "Fully stable" would be static and I don't think anyone is suggesting static. While devices must be able to survive address changes, they should not have to change addresses frequently. Using ULA's and the availability of Global addressing are orthogonal issues.=20 ULA's are the new Link Local's in a routed home. tom On 3/27/12 1:01 PM, "Jari Arkko" wrote: >I fully agree with these comments from Ray. Basically, when hardware >changes on some router it is pretty much given that some address will >change somewhere. And I don't think fully stable addressing is a good >goal to begin with. Make the devices survive addressing changes, and >we'll be fine. > >Initial ULA generation before any connectivity with the Internet can be >reached is fine, however. > >Jari > >On 22.03.2012 14:49, Ray Hunter wrote: >> As requested by Tim: My comments on ULA use in Homenet posted in >>consolidated manner to the issue tracker. >> >> I think Homenet still has a lot of work to do, especially due to the >>autoconfig requirements. >> >> Everyone wants autoconfig. >> >> Concurrent ULA + PA + both with autoconfig + invariant addresses is >>likely going to be tough, if not downright impossible. >> >> So why do we think we really need concurrent ULA+PA in Homenet as a >>base requirement? I'm not entirely convinced yet. >> >> >> Issue 1: One reason ULA seems to be mentioned is "time-invariance of >>addressing for use by sensor networks." >> >> Using the example of an electrician setting up a sensor network in a >>home before an ISP is present, and expecting time-invariant ULA >>addresses. Firstly, the electrician would have to generate a Global ID >>for ULA when the lights are installed. The electrician can generate a >>unique Global ID (and hence the /48 prefix of ULA) using the procedure >>in RFC4193. >> >> Problems with this are: >> 1) The /48 ULA prefix is tied to a time (when the electrician pressed >>the "generate ULA" button) >> If a user regenerates the ULA prefix later, the algorithm will generate >>a different /48 prefix: all addresses in the house will change >> >> 2) The /48 ULA prefix is tied to a MAC address (of the router or device >>used to seed the ULA prefix generation algorithm) >> If a user changes router hardware, the /48 prefix will change. Or else >>the seed stored in non-volatile memory will be lost when hardware is >>replaced. Again all addresses in the house will change >> >> 3) The Global ID portion of the ULA has to be manually assigned to each >>of the routers (if there's more than one) as there's no mechanism to >>distribute Global IDs today. >> Homenet needs autoconfiguration. >> >> 4) Even if the /48 prefix is made invariant, the /64 LAN prefix >>generated from it probably won't be invariant as hardware is added, >>replugged or removed. >> Again, OK for manual configuration like an enterprise network, but >>Homenet wants autoconfig. >> >> I don't see how "complete time-invariance of addressing" is achievable >>together with autoconfig, even if we call for an equivalent site-local >>addressing with a fixed /48 prefix that is common to all Homenet >>implementations everywhere. We've been down that rathole before. >>Site-local has been deprecated in RFC3879. And realistically speaking, >>any time someone replaces or adds or re-plugs any router hardware, the >>LAN's /64 prefix will change when using autoconfig. >> >> >> I think it would be useful for the Homenet WG to propose a scheme for >>sensor networks to be able to maintain simple peerings despite the >>presence of time-variant addressing [whether these are ULA, PA, PI, IPv4 >>or whatever]. In fact, it would seem to me that a peering solution >>should use something that is long-term invariant as an identifier for >>keying the peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the >>IPv6 address at all. The invariant identifier could be automatically >>registered by each sensor as a name in the Homenet naming service. Peers >>could resolve that name to the current IPv6 address and then verify the >>peering using their own protocol like HMAC_MD5 with a shared secret >>(RFC2104). Loss of connection would trigger a new address resolution, >>reconnection, and peer check. Agreeing the shared secret is peering >>specific (and has to be solved anyway even with fixed addresses). I have >>an asterisk hardware phone that does something similar to this, so it >>can't=20 >> require much code. >> >> >> >> >> Issue 2: Use of multiple ULA Global ID's in Homenet may also cause >>problems with source address selection (3484-revise). There is no way to >>know which ULA's are connected to the local Homenet, and which are >>distributed on remote Homenets spread over the Internet. This causes >>problems with potential ULA leakage, and in determining priority between >>PA-derived addresses and ULA addresses when both are available and the >>default 3484 or 3484-revise rules are followed. >> >> A workaround might be to be redistribute a non-default RFC3484-revise >>policy table to all end nodes via draft-fujisaki-dhc-addr-select-opt-07, >>but its not clear that all end nodes will support this mechanism, nor >>how the contents of the policy table would be managed in a distributed >>and automated manner. >> >> >> Issue 3: A reason concurrent ULA+PA seems to be required was that >>"intra-homenet communication should survive a long term ISP outage, and >>must be able to be established without any ISP connection present." >> >> The first linkage would appear to be when ISP PA-derived prefixes >>within Homenet timeout via DHCPv6 PD meaning that a long-running session >>based on this address would drop. That has nothing directly to do with >>ULA, and may have other solutions. >> >> Question: How long are ISP's setting their DHCPv6 PD timers in >>practice? Simply recommending very long timers for the DHCPv6 PD >>PA-derived prefix might be a practical solution. How often has your ISP >>connection been down for say 10 days? >> >> Another solution might be for the application to reconnect using >>another PA-derived address (if the user has two providers). >> >> >> The second linkage may also have other solutions, such as only >>configuring a ULA prefix when no PA-derived prefixes are present. >> >> That would mean at any one time the Homenet could potentially be >>running either ULA or multiple PA, but not both, which completely avoids >>any address selection conflicts and having to redistribute new RFC3484 >>address selection rules to all nodes. Simply put: "Please reboot or >>reconnect to fix any problems." >> >> >> regards, >> RayH >> >> >> homenet issue tracker wrote: >>> #4: Use of ULAs >>> >>> CN1 in the -02 text says ULAs should be provisioned by default. Do >>>we >>> agree? And if so, should they be preferred over globals? The new >>> 3484-bis has changed so they are not *unless* a specific /48 for the >>>site >>> is added to the 3484 policy table with higher precedence than >>>globals. We >>> should design something that works when disconnected from the >>>Internet. >>> Also, we currently say nothing about ULA-only devices and their >>> reachability from outside the homenet; do we want to? >>> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From jari.arkko@piuha.net Tue Mar 27 14:13:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A53B21E80D2 for ; Tue, 27 Mar 2012 14:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 HnOeAkxTZ5bF for ; Tue, 27 Mar 2012 14:13:27 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id CE22A21E8011 for ; Tue, 27 Mar 2012 14:13:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2AE822D35A for ; Wed, 28 Mar 2012 00:13:26 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOUiAYf4bNsU for ; Wed, 28 Mar 2012 00:13:25 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 4A96C2CC56 for ; Wed, 28 Mar 2012 00:13:25 +0300 (EEST) Message-ID: <4F722D74.9010909@piuha.net> Date: Tue, 27 Mar 2012 23:13:24 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: homenet@ietf.org References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6B2DF7.30500@globis.net> <4F721CB4.6000501@piuha.net> In-Reply-To: <4F721CB4.6000501@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [homenet] home networking of a different kind X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:13:27 -0000 Not sure if this is on or off-topic for this working group but here's a recent extension to my home network setup: http://thingsonip.blogspot.fr/2012/03/smart-igloos.html Jari From Ray.Bellis@nominet.org.uk Tue Mar 27 14:20:43 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210AA21E80CE for ; Tue, 27 Mar 2012 14:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.088 X-Spam-Level: X-Spam-Status: No, score=-10.088 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] 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 QDNirxPOEHnY for ; Tue, 27 Mar 2012 14:20:42 -0700 (PDT) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id F41A021E8011 for ; Tue, 27 Mar 2012 14:20:41 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=BIeblDbmRTC+dCR/hNiPZ/vRqrxw7/gMbK+hd6WrDCmkjXukTeTp7h3c Ck5b7TssQZs4pycsPKveLqLHLVLhbH1yzh3O+aCFu18SSI1QQOHCZAEQK 6viGOQjlIn4Ougx; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1332883242; x=1364419242; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20#4:=20Use=20of=20ULAs|Date: =20Tue,=2027=20Mar=202012=2021:20:37=20+0000|Message-ID: =20 |To:=20Thomas=20Herbst=20 |CC:=20"homenet@ietf.org"=20,=0D=0A=09" draft-ietf-homenet-arch@tools.ietf.org"=0D=0A=09|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20|References:=20; bh=1J6bJ5j9ENTLXgFPiOLz1C06bYwA8Z/RoTnMSLcChVI=; b=HK+/CdpWgLch+SLvpK94E3MOpJ5nkJDiSSMRl77a4DtgK66IUcErIppD 6MNVP1UcXwAnFarIdxcWJIHELpxqSZ8iu2bXQcOVFRIahjmsOFYD3hxMM pfj5hMcwq7OEX5h; X-IronPort-AV: E=Sophos;i="4.75,328,1330905600"; d="scan'208";a="39354215" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 27 Mar 2012 22:20:41 +0100 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%19]) with mapi; Tue, 27 Mar 2012 22:20:40 +0100 From: Ray Bellis To: Thomas Herbst Thread-Topic: [homenet] #4: Use of ULAs Thread-Index: AQHNCDKwB/+AV+wZH0aYJaAsEst3xpZ+h8MAgAATrQCAAAJOgA== Date: Tue, 27 Mar 2012 21:20:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" , "draft-ietf-homenet-arch@tools.ietf.org" Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:20:43 -0000 On 27 Mar 2012, at 23:12, Thomas Herbst wrote: > "Fully stable" would be static and I don't think anyone is suggesting > static. While devices must be able to survive address changes, they > should not have to change addresses frequently. How often is "frequently"? I know of at least one ISP who gives a _dynamic_ /64 to every DSL customer = that happens to negotiate IP6CP that changes each time they connect. > Using ULA's and the availability of Global addressing are orthogonal > issues. +1 Ray >=20 From therbst@silverspringnet.com Tue Mar 27 14:50:40 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FAA21E8134 for ; Tue, 27 Mar 2012 14:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_42=0.6] 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 Zk6HksLIR9xg for ; Tue, 27 Mar 2012 14:50:40 -0700 (PDT) Received: from it-ipcorp-01.silverspringnet.com (it-ipcorp-01.silverspringnet.com [74.121.22.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5A24821E8133 for ; Tue, 27 Mar 2012 14:50:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAAA1ck8KOQxz/2dsb2JhbABFuW2CCQEBBTo/EgEIDQseQiUBAQQOBcIzkQ8EiFiTGo0j X-IronPort-AV: E=Sophos;i="4.75,328,1330934400"; d="scan'208";a="10185527" Received: from unknown (HELO SFO-EXCA-02.silverspringnet.com) ([10.57.12.115]) by it-ipcorp-01.silverspringnet.com with ESMTP/TLS/AES128-SHA; 27 Mar 2012 14:50:39 -0700 Received: from IT-EXCA-02.silverspringnet.com (10.200.1.62) by SFO-EXCA-02.silverspringnet.com (10.57.12.101) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 27 Mar 2012 14:50:39 -0700 Received: from IT-RESTORE-01.silverspringnet.com ([::1]) by IT-EXCA-02.silverspringnet.com ([::1]) with mapi; Tue, 27 Mar 2012 14:50:39 -0700 From: Thomas Herbst To: Ray Bellis Date: Tue, 27 Mar 2012 14:50:28 -0700 Thread-Topic: [homenet] #4: Use of ULAs Thread-Index: Ac0MY6Vmmpy2Z60USTW9/yCn1dTm6w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" , Thomas Herbst , "draft-ietf-homenet-arch@tools.ietf.org" Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 21:50:40 -0000 If you change routing equipment, perhaps even upgrade firmware, changing ULA's can be fair game. An instance of the same hardware in the same configuration should have no reason to randomly change ULA addressing. The discussion of GUA's still orthogonal. It doesn't matter what the ISP policy is if I don't connect, they provide a small chunk of address like a /64, the connection is flaky or broken, I stop paying the bill,or for any other reason I don't have connectivity, I should still be able to have a stable connection across the routed home. In the bridged home this now happens every day with LL's. tom On 3/27/12 2:20 PM, "Ray Bellis" wrote: > >On 27 Mar 2012, at 23:12, Thomas Herbst wrote: > >> "Fully stable" would be static and I don't think anyone is suggesting >> static. While devices must be able to survive address changes, they >> should not have to change addresses frequently. > > > >How often is "frequently"? > >I know of at least one ISP who gives a _dynamic_ /64 to every DSL >customer that happens to negotiate IP6CP that changes each time they >connect. > >> Using ULA's and the availability of Global addressing are orthogonal >> issues. > >+1 > >Ray >>=20 > From gettysjim@gmail.com Tue Mar 27 15:40:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2981721E8141 for ; Tue, 27 Mar 2012 15:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_32=0.6, MANGLED_PAIN=2.3, 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 ZujByF721sl7 for ; Tue, 27 Mar 2012 15:40:35 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3F5421E8011 for ; Tue, 27 Mar 2012 15:40:34 -0700 (PDT) Received: by qcsq13 with SMTP id q13so334199qcs.31 for ; Tue, 27 Mar 2012 15:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G35JvAyyGEsHVQWO4ntANTj6KUWZSa32tD6n5WXjRYc=; b=Nam0i5Da4+yyGervi7t3giMHcwgAWEHNFThUs4mrU5gHPbOo/UOxPK0hA5fzuWc4JU QP5PunpJXjORAUKVz8MsFHuVgDABpqnNPi+9RZr5DrOn+uALvl8NGiFUFJ6/dmdeNBo6 FIMcvNLzqICnRdx7r3gIIircEIV2oJVwDG118yNExhYtdVbAoEpMpQx6GTFB0dtIL4HE HR8VcFAkbOqYt5UbqkeLX3TZ9O5bUjzNeDeMwum5/rD7DSMEviSGIERkcQRi0MjeoNmo d+quww8Y0BKH1OUvrjnb35Iu7wNFY1l4ZPRL4qNJGQZ2dUJ7+N8ubDCWbVxZCCgAggca A9tw== Received: by 10.229.137.81 with SMTP id v17mr5447290qct.135.1332888034411; Tue, 27 Mar 2012 15:40:34 -0700 (PDT) Received: from [192.168.1.25] (c-50-138-169-248.hsd1.ma.comcast.net. [50.138.169.248]) by mx.google.com with ESMTPS id ha10sm3188651qab.14.2012.03.27.15.40.32 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 15:40:33 -0700 (PDT) Sender: Jim Gettys Message-ID: <4F7241DF.7050103@freedesktop.org> Date: Tue, 27 Mar 2012 18:40:31 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Dave Taht References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6B2DF7.30500@globis.net> <4F721CB4.6000501@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Ray Hunter , tjc@ecs.soton.ac.uk, Jari Arkko , homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #4: Use of ULAs - issues with RFC4193 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:40:36 -0000 I'd like to drag this back to Dave's points 1-4. There are real implementation issues with RFC4193. The questions are: a) do these problems matter? b) if so, what do we do about them? Note that true random bits are really hard to come by right now in current home routers. Sigh... Anyone who knows any chip architects, please beat them bloody until they provide a hardware RNG.... So long as the addresses don't leak from the home network, and each home router settles on unique addresses (maybe derived from their MAC addresses), I'm not sure it matters. But someone who has thought longer and harder about ULA's should think about the issues Dave's raising. - Jim On 03/27/2012 04:21 PM, Dave Taht wrote: > > > On Tue, Mar 27, 2012 at 1:01 PM, Jari Arkko > wrote: > > I fully agree with these comments from Ray. Basically, when > hardware changes on some router it is pretty much given that some > address will change somewhere. And I don't think fully stable > addressing is a good goal to begin with. Make the devices survive > addressing changes, and we'll be fine. > > Initial ULA generation before any connectivity with the Internet > can be reached is fine, however. > > > While I agree that having a ULA at the getgo is a goodness, following > RFC4193 to the letter is very difficult. > > 1) You need time. If you do not have a battery backed up clock in the > device (set to an appropriate value), you need to get time from the > internet, which you can't do until you are on the internet. > > Or you could mandate time come from a gps. > > If you are getting time from the internet, you need sntp, ntp, or > equivalent. From gps, something like chronyd. > > Without this, generating the ULA is generally going to come from 'time > since the epoch or build date', and other sorts of randomness would be > useful. > > 2) The infrastructure mandated by that RFC requires a sha-1 digest. > Many devices (at least at present) do not come with a SSL based > infrastructure from which that is a single function thereof. > > 3) It is my hope that hardware based RNGs start showing up soon in > many more devices. But thus far, no luck, so finding an essential > source of randomness would be good. > > 4) Lastly, without a solid means of getting the ULA and a human usable > name out to the users's dns system (be that mdns, normal dns, etc), > there is no way to map the idea of that number to a presentation that > a user can 'just use'. I could be humorous about this (As april 1st is > coming up) - flashing the blinking lights on a switch or router in > baudot code might suffice for some, but... > > > Jari > > > On 22.03.2012 14:49, Ray Hunter wrote: > > As requested by Tim: My comments on ULA use in Homenet posted > in consolidated manner to the issue tracker. > > I think Homenet still has a lot of work to do, especially due > to the autoconfig requirements. > > Everyone wants autoconfig. > > Concurrent ULA + PA + both with autoconfig + invariant > addresses is likely going to be tough, if not downright > impossible. > > So why do we think we really need concurrent ULA+PA in Homenet > as a base requirement? I'm not entirely convinced yet. > > > Issue 1: One reason ULA seems to be mentioned is > "time-invariance of addressing for use by sensor networks." > > Using the example of an electrician setting up a sensor > network in a home before an ISP is present, and expecting > time-invariant ULA addresses. Firstly, the electrician would > have to generate a Global ID for ULA when the lights are > installed. The electrician can generate a unique Global ID > (and hence the /48 prefix of ULA) using the procedure in RFC4193. > > Problems with this are: > 1) The /48 ULA prefix is tied to a time (when the electrician > pressed the "generate ULA" button) > If a user regenerates the ULA prefix later, the algorithm will > generate a different /48 prefix: all addresses in the house > will change > > 2) The /48 ULA prefix is tied to a MAC address (of the router > or device used to seed the ULA prefix generation algorithm) > If a user changes router hardware, the /48 prefix will change. > Or else the seed stored in non-volatile memory will be lost > when hardware is replaced. Again all addresses in the house > will change > > 3) The Global ID portion of the ULA has to be manually > assigned to each of the routers (if there's more than one) as > there's no mechanism to distribute Global IDs today. > Homenet needs autoconfiguration. > > 4) Even if the /48 prefix is made invariant, the /64 LAN > prefix generated from it probably won't be invariant as > hardware is added, replugged or removed. > Again, OK for manual configuration like an enterprise network, > but Homenet wants autoconfig. > > I don't see how "complete time-invariance of addressing" is > achievable together with autoconfig, even if we call for an > equivalent site-local addressing with a fixed /48 prefix that > is common to all Homenet implementations everywhere. We've > been down that rathole before. Site-local has been deprecated > in RFC3879. And realistically speaking, any time someone > replaces or adds or re-plugs any router hardware, the LAN's > /64 prefix will change when using autoconfig. > > > I think it would be useful for the Homenet WG to propose a > scheme for sensor networks to be able to maintain simple > peerings despite the presence of time-variant addressing > [whether these are ULA, PA, PI, IPv4 or whatever]. In fact, it > would seem to me that a peering solution should use something > that is long-term invariant as an identifier for keying the > peering e.g. EUI-64 a.k.a. MAC BIA or DHCP DUID, and not the > IPv6 address at all. The invariant identifier could be > automatically registered by each sensor as a name in the > Homenet naming service. Peers could resolve that name to the > current IPv6 address and then verify the peering using their > own protocol like HMAC_MD5 with a shared secret (RFC2104). > Loss of connection would trigger a new address resolution, > reconnection, and peer check. Agreeing the shared secret is > peering specific (and has to be solved anyway even with fixed > addresses). I have an asterisk hardware phone that does > something similar to this, so it can't require much code. > > > > > Issue 2: Use of multiple ULA Global ID's in Homenet may also > cause problems with source address selection (3484-revise). > There is no way to know which ULA's are connected to the local > Homenet, and which are distributed on remote Homenets spread > over the Internet. This causes problems with potential ULA > leakage, and in determining priority between PA-derived > addresses and ULA addresses when both are available and the > default 3484 or 3484-revise rules are followed. > > A workaround might be to be redistribute a non-default > RFC3484-revise policy table to all end nodes via > draft-fujisaki-dhc-addr-select-opt-07, but its not clear that > all end nodes will support this mechanism, nor how the > contents of the policy table would be managed in a distributed > and automated manner. > > > Issue 3: A reason concurrent ULA+PA seems to be required was > that "intra-homenet communication should survive a long term > ISP outage, and must be able to be established without any ISP > connection present." > > The first linkage would appear to be when ISP PA-derived > prefixes within Homenet timeout via DHCPv6 PD meaning that a > long-running session based on this address would drop. That > has nothing directly to do with ULA, and may have other solutions. > > Question: How long are ISP's setting their DHCPv6 PD timers in > practice? Simply recommending very long timers for the DHCPv6 > PD PA-derived prefix might be a practical solution. How often > has your ISP connection been down for say 10 days? > > Another solution might be for the application to reconnect > using another PA-derived address (if the user has two providers). > > > The second linkage may also have other solutions, such as only > configuring a ULA prefix when no PA-derived prefixes are present. > > That would mean at any one time the Homenet could potentially > be running either ULA or multiple PA, but not both, which > completely avoids any address selection conflicts and having > to redistribute new RFC3484 address selection rules to all > nodes. Simply put: "Please reboot or reconnect to fix any > problems." > > > regards, > RayH > > > homenet issue tracker wrote: > > #4: Use of ULAs > > CN1 in the -02 text says ULAs should be provisioned by > default. Do we > agree? And if so, should they be preferred over globals? > The new > 3484-bis has changed so they are not *unless* a specific > /48 for the site > is added to the 3484 policy table with higher precedence > than globals. We > should design something that works when disconnected from > the Internet. > Also, we currently say nothing about ULA-only devices and > their > reachability from outside the homenet; do we want to? > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > > > > > -- > Dave Täht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://www.bufferbloat.net > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From Dmitry.Anipko@microsoft.com Tue Mar 27 15:58:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1598A21E8147 for ; Tue, 27 Mar 2012 15:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 j-ywcK++qz8Q for ; Tue, 27 Mar 2012 15:58:07 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id CBE6421E80B9 for ; Tue, 27 Mar 2012 15:58:06 -0700 (PDT) Received: from mail133-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Tue, 27 Mar 2012 22:57:52 +0000 Received: from mail133-va3 (localhost [127.0.0.1]) by mail133-va3-R.bigfish.com (Postfix) with ESMTP id 4820D32024A; Tue, 27 Mar 2012 22:57:52 +0000 (UTC) X-SpamScore: -38 X-BigFish: VS-38(zz9371I936eK1432N1418M98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail133-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail133-va3 (localhost.localdomain [127.0.0.1]) by mail133-va3 (MessageSwitch) id 1332889069843515_18929; Tue, 27 Mar 2012 22:57:49 +0000 (UTC) Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.235]) by mail133-va3.bigfish.com (Postfix) with ESMTP id BB4E942005B; Tue, 27 Mar 2012 22:57:49 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 27 Mar 2012 22:57:49 +0000 Received: from tk5ex14mbxc246.redmond.corp.microsoft.com ([169.254.11.95]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0283.004; Tue, 27 Mar 2012 22:58:02 +0000 From: Dmitry Anipko To: Mark Townsley , "homenet@ietf.org Group" Thread-Topic: [homenet] Security goals Thread-Index: AQHM/yMmSvbYdJwNEEW8A+iww8NQ/pZlXK8AgAEOZYCAAmcPAIAAJRCAgAAKkwCAACVeAIAAHF2AgADzCgCACasegIAK+N5x Date: Tue, 27 Mar 2012 22:58:01 +0000 Message-ID: <03FE6A726D13284495EF1787D25F1DF91F8C84D6@tk5ex14mbxc246.redmond.corp.microsoft.com> References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F60F458.4080403@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 22:58:08 -0000 As someone who works for a host software vendor, I'd like to add couple of = points. I agree with Mark that in general the security topic is wider than = only filtering on the borders of the realms of the traffic destined to host= s, and I support the efforts to figure out the right set of knobs for the f= ormer. That said, for the latter, I'd like to see something along the below= lines in the requirements=20 (some of which may already be in the text in some form, putting it here jus= t for fluency of this piece of the story). 1. Homenet hosts MUST implement their own security policies in accordance t= o their computing capabilities. 2. Homenet routers MUST preserve the integrity of the security boundary - f= or example, not allow into the realm an=20 ingress traffic sourced from addresses of the destination realm. 3. Homenet routers MAY apply additional filtering to the traffic destined t= o hosts and crossing security boundaries. 4. If a router applies such filtering (3), it MUST provide: 4.a. a way for participating hosts to enable per-host exemption from suc= h additional filtering; 4.b. an information to hosts, based on which the router would apply such= additional filtering if there was no exemption.=20 An example of a signalling protocol for (4.a) could be PCP (extended if nee= ded).=20 An example of information 4.b is definition of the security boundaries and = a the way to provide it could be prefix information option in RA, with addi= tional marking allowing to distinguish guest routes from "core" home route= s. The motivation for these: while it is a fact of life that there may be some= devices on the network, having less built-in protections than others due t= o many reasons, it seems logical to provide for those devices, which are ca= pable to implement rich security functionality, a way to be in full control= of their behavior. -Dmitry ________________________________________ From: homenet-bounces@ietf.org [homenet-bounces@ietf.org] on behalf of Mark= Townsley [mark@townsley.net] Sent: Tuesday, March 20, 2012 4:19 PM To: homenet@ietf.org Group Subject: Re: [homenet] Security goals Let me try and up-level a bit architecturally, because this is more than j= ust about whether we turn on or off a firewall on a particular border. Consider two routers fully within a homenet Now, list all the types of traf= fic and information that might be exchanged between those routers, e.g., - Datalink establishment - IP addressing for the link - IP Prefixes reachable by the router (what a "routing protocol" would do) - Services present on the router itself - Services on connected links propagated via the router - User traffic - etc... Our job is to determine what kind of link exists between two routers and st= art crossing out items, in whole or in part, based on how promiscuous we wi= sh the routers to be on that link. In effect, we are deciding where to brea= k the network and where not to, but it is by doing this that we carve out t= he separate "home", "guest" and "Internet" realms that we are targeting to = create. I think that what is most important at this moment is to nail down = what knobs we want to try and have available, what their "out of the box" d= efaults are for the above 3 combinations of border types, and allow for sup= er-users, ISP-managed devices, etc. monkey around with them as they wish ac= cording to what vendors and providers can dream up. If we can agree on thes= e, and still remain blocked on what kind of firewall to recommend to be ena= bled by default, we will still have accomplished quite a bit. So I'd like t= o encourage us to step out of the firewall rathole for a moment, and look a= t this from a w ider angle. Further, if we *really* want to talk about goals for security of our homene= t routers, we should consider mandating the ability to download bug fixes a= nd security updates. Far and away, this has been what has made hosts more s= ecure in the past decade, why a home router would be exempt from this baffl= es me. - Mark On Mar 14, 2012, at 8:41 PM, Brian E Carpenter wrote: > On 2012-03-14 18:11, Cameron Byrne wrote: >> On Tue, Mar 13, 2012 at 8:29 PM, Ashok Narayanan wrot= e: >>> On Mar 13, 2012, at 3/13 9:16 PM, Cameron Byrne wrote: >>> >>> >>>> That's reality, and much as I love the e2e principle I think the ordin= ary >>>> citizen is better off behind default-deny. >>>> >>> I am not trying to be dense, but why? >>> >>> What is the negative scenario of not having a homenet firewall on? Usin= g >>> real examples from the last 5 years .... I would like to know how a cpe >>> firewall protects against real threats to modern software. >>> >>> It seems hard to predict a priori what a "real threat" is going to be. = And >>> it seems unlikely that "modern software" is all that will be found in >>> average homes. For example, will the Android version on the refrigerato= r >>> display be updated? >>> >> >> Agreed about a priori. BUT! what else do we have to go on? I am >> asking for a baseline to justify why a CPE firewall is required. In >> fact, i have asked for it multiple times on this thread, and all i get >> back is anecdotal hand waving, not technical reasons. >> >> Putting the E back in IETF, let's see some data about why this >> function of the system must exist. >> >> My cursory research says you are not going to be able to present a >> convincing amount of data to support the fact that a stateful >> inspection firewall should be applied in a contemporary home >> environment. I believe the spirit of Homenet is moving the internet >> forward without being beholden to the Morris worm and X.25 > > Fred and I provided factual but local evidence of background radiation > of unwanted UDP packets. Actually there is a lot more systematic evidence > of this too. For example, this week at the PAM conference in Vienna > there's a paper "One-way traffic monitoring with iatmon" by Nevil Brownle= e > that gives a detailed analysis of observed unwanted traffic, both UDP and= TCP SYN. > See http://www.caida.org/publications/papers/2012/one_way_traffic_iatmon/ > > Can you assert that all low-end homenet devices will be internally > protected against such traffic? > > Bian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet= From brian.e.carpenter@gmail.com Tue Mar 27 18:48:24 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8623A21E803D for ; Tue, 27 Mar 2012 18:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 LPu+7i7DHYaR for ; Tue, 27 Mar 2012 18:48:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 988BA21E8042 for ; Tue, 27 Mar 2012 18:48:23 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so707670obb.31 for ; Tue, 27 Mar 2012 18:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lMUIqEEk+lSm3Ypk4MRvcAYdMIYVEZyO+BJU64074m0=; b=CfMgDHEK1lpJ9ijBbC5/EoNtXuMBFXK2Sqr8RMHVt0xCg34t8tZ39bH2eJ66itQmUB viC3rwAvaun5oYK5pBd/cXVkabUALrILMdeNxBBOp66vo9VTHWxQzymJwr1EWXkzAJ0l f+BBsfUB4NO1L4c4u87oXxLXISfExOuFFpuG8sKCe3ogbMZPjHlP+MPMN4y7SPVDALx0 DbCSleJA8myPGKvNrLxRe5iAF1Z/sF5Y7bpo0EOEgcv+1qJik7Ob/AZkTiAwHawCzYKE iZnPeyO8t+2duBNGae6TXNkl0YsfGrpM8BJky3FnwEzO+mNrMiXAYYQor1lRdtoFp/5y eACg== Received: by 10.60.30.3 with SMTP id o3mr35587764oeh.9.1332899303096; Tue, 27 Mar 2012 18:48:23 -0700 (PDT) Received: from [192.168.182.50] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id h5sm1372364oea.1.2012.03.27.18.48.20 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 18:48:22 -0700 (PDT) Message-ID: <4F726DDD.9000604@gmail.com> Date: Wed, 28 Mar 2012 14:48:13 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Aamer Akhter (aakhter)" References: <20120312221619.9612.79497.idtracker@ietfa.amsl.com> <4F717066.8060703@cisco.com> <7F298ACC76CC154F832B6D02852D169F078D5B3C@XMB-RCD-101.cisco.com> In-Reply-To: <7F298ACC76CC154F832B6D02852D169F078D5B3C@XMB-RCD-101.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: [homenet] Prefix length [ I-D Action: draft-ietf-homenet-arch-02.txt] X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 01:48:24 -0000 On 2012-03-27 20:59, Aamer Akhter (aakhter) wrote: ... > Sec 3.4.11 > > "The home network may receive an arbitrary length IPv6 prefix > from its provider, e.g. /60 or /56. The offered prefix may be stable > over time or change from time to time. " > > It is unclear if only the prefix, or also the prefix-length would also > be changing. Do we need to worry about both cases? To cover all cases, you have to assume that the prefix length might change, including becoming longer. Also if there's more than one provider, you have to assume different prefix lengths. This affects 6renum as well as homenet. Brian From brian.e.carpenter@gmail.com Tue Mar 27 18:53:39 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D4921E804D for ; Tue, 27 Mar 2012 18:53:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 1WSPvrccQadN for ; Tue, 27 Mar 2012 18:53:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DE19E21E8032 for ; Tue, 27 Mar 2012 18:53:10 -0700 (PDT) Received: by iazz13 with SMTP id z13so777673iaz.31 for ; Tue, 27 Mar 2012 18:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=a2xuZRXKbQfwE1DlN5TQlHkgEeKeMM1tGa2GVcYfo6M=; b=v8AmJsTv5xzLCnNXzdnsyaTQuNaKXvMFzDWIg5prBgwfXLRjzRi+un0N3TnvvS991H Q7FEfdWIf5cvWZkm+iqNSfPP2aCcWCqAv+Cc8KdHiC10F8gnDnupz7K+mA8ewvN9AUV3 Hka2pH12WOGUtbo3Kdyfgj+QaLCca2cFJmg0Jpk7u1w39mVLfZRlvJDk6blzpoetnHSq 8Rd8seKJ3vOih8D6FqVUnuyZqfqXWOqa7zRFwnpsv5ST162Hq1Ucrnx8UWKfY4xoYCsx RBXLeshjTD9Cz+1d6Q+eg8qbbUIoYy6+NVTVoQyVWPiKLacYKvXk6I/+POP97GhPuyAl W5SQ== Received: by 10.50.88.168 with SMTP id bh8mr833195igb.29.1332899590500; Tue, 27 Mar 2012 18:53:10 -0700 (PDT) Received: from [192.168.182.50] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id t8sm13924138igw.0.2012.03.27.18.53.07 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 18:53:09 -0700 (PDT) Message-ID: <4F726EFE.5010205@gmail.com> Date: Wed, 28 Mar 2012 14:53:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dmitry Anipko References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F60F458.4080403@gmail.com>, <03FE6A726D13284495EF1787D25F1DF91F8C84D6@tk5ex14mbxc246.redmond.corp.microsoft.com> In-Reply-To: <03FE6A726D13284495EF1787D25F1DF91F8C84D6@tk5ex14mbxc246.redmond.corp.microsoft.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 01:53:39 -0000 On 2012-03-28 11:58, Dmitry Anipko wrote: > As someone who works for a host software vendor, I'd like to add couple of points. I agree with Mark that in general the security topic is wider than only filtering on the borders of the realms of the traffic destined to hosts, and I support the efforts to figure out the right set of knobs for the former. That said, for the latter, I'd like to see something along the below lines in the requirements > (some of which may already be in the text in some form, putting it here just for fluency of this piece of the story). > > 1. Homenet hosts MUST implement their own security policies in accordance to their computing capabilities. I think we know from some famous cases that SCADA systems are highly insecure, mainly due to following this principle (translated as "security is too hard and this device will always be on a private network anyway"). I'm a bit nervous that this policy will encourage low-end device designers to classify their devices as not having enough resource to deal with security. Brian From brian.e.carpenter@gmail.com Tue Mar 27 19:09:49 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48CBF21E80C1 for ; Tue, 27 Mar 2012 19:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 b4PsCIHvyai7 for ; Tue, 27 Mar 2012 19:09:48 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90BC121E8063 for ; Tue, 27 Mar 2012 19:09:48 -0700 (PDT) Received: by iazz13 with SMTP id z13so799040iaz.31 for ; Tue, 27 Mar 2012 19:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=x9rhuqH+aUqoVOzpPJq7q7TVVioi2rGtkoxXilZOfNw=; b=oQmlUIj+d0D97YyMAPCQ/3IX9C0EAHqYxEZci4CIzUjDlrXM8BOzOik7yJ08F/v9t4 wcNahmsukk2D6e//3WSl8ZEcEB/p8TO8SVbvrVC0iZREZk5TS0koxnTc313z6LzBO8y9 CTEJUDVye3SN1ft45Pj5DKtS5zlMQTBwjopUEeuDUXH28oAk+8onHdAUH4WJM2UgP/OF xgXxyjZjCJ7mT5BulZMyVQDC6bIYUnh379cB+oGBK5+DrRLoSUuvhRg6wmNqxzF6iXwg e3NSQyc8k/xQBum0kwaERKeWkSjZhkGtQwJ1foG2BXMFMdgf+F6PPjd/82j0tXUI869b F4nw== Received: by 10.50.42.164 with SMTP id p4mr773107igl.72.1332900588134; Tue, 27 Mar 2012 19:09:48 -0700 (PDT) Received: from [192.168.182.50] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id cg9sm1531598igb.17.2012.03.27.19.09.44 (version=SSLv3 cipher=OTHER); Tue, 27 Mar 2012 19:09:47 -0700 (PDT) Message-ID: <4F7272E3.60403@gmail.com> Date: Wed, 28 Mar 2012 15:09:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dave Taht References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6BAC9F.10903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet issue tracker , tjc@ecs.soton.ac.uk, homenet@ietf.org, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 02:09:49 -0000 Dave, On 2012-03-28 09:28, Dave Taht wrote: > On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 2012-03-22 12:33, homenet issue tracker wrote: >>> #4: Use of ULAs >>> >>> CN1 in the -02 text says ULAs should be provisioned by default. Do we >>> agree? >> Yes, by the CER (MUST). >> >> It's much less clear for all other routers on site. I would prefer that >> no other router provisions a ULA prefix if the CER has already delegated >> one. >> > > Since it is nearly impossible to learn a subnet prefix that is unused > unless all devices share a routing protocol, I have generally preferred to > generate unique ULAs per routing device. Our two statements are not inconsistent... obviously, if a router comes up and does not hear about a ULA prefix from another router, it may be appropriate to generate a new one. But if we have a prefix delegation mechanism in place, that may be sufficient. > > >>> And if so, should they be preferred over globals? >> Yes. >> >> > This part I don't quite understand. I would prefer global prefixes to > always take precedence over ULAs. > I'd like ULAs to try to talk only to ULAs. ULAs should not escape into the > global DNS, but should end up in local dns. ULAs should really only be used to talk to ULAs, so when I say 'prefer ULAs', I mean prefer a pair of ULAs to a pair of globals. In case it isn't clear, in my mind the problem is always address *pair* selection. So that means that a host should do something like this in the default case: Do I have a ULA? If yes, does the other guy have a ULA (in the same prefix)? If yes, use the two ULAs. Else, use two globals. I'm hoping 3484bis will result in this. > > Even with 'happy eyeballs', having a means to disable a ULA -> global > connection by default saves 100s of ms in the bad cases. Agreed. Brian > >>> The new >>> 3484-bis has changed so they are not *unless* a specific /48 for the >> site >>> is added to the 3484 policy table with higher precedence than globals. >> We >>> should design something that works when disconnected from the Internet. >> We'll have to deal with whatever 3484bis ends up saying. If it does >> require an explicit policy table entry table, that will require >> a mechanism, associated with the prefix delegation mechanism. >> > > OK, I will re-read, thx for the update.. > > >>> Also, we currently say nothing about ULA-only devices and their >>> reachability from outside the homenet; do we want to? >> I don't see what there is to say; they aren't reachable, and that's >> a feature. >> >> Brian >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >> > > > From cb.list6@gmail.com Tue Mar 27 20:29:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0786F21E8027 for ; Tue, 27 Mar 2012 20:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Yx8f04wRaqhm for ; Tue, 27 Mar 2012 20:29:40 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20D5721E801A for ; Tue, 27 Mar 2012 20:29:40 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1143037pbb.31 for ; Tue, 27 Mar 2012 20:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=v2vnqb1IS/h60iM3W9e02xl/ZsQONiarE3VQ9EStu+g=; b=pQxp10fOQ6jTR+/iVzAgWk3vV2ePZczXEATpONbtx9o7VOHUgZEWJJOp/hXQmoUKSR jBazkzguXGLc6+pDl0T6QSMYn937UtYOQ03osgp50aiqYKs5hpETCgfiGuuwTCkMgEvi Ld4kpW7YVeKo8Wp7eYJuGIOns2OsVWnVwfpJKHrbuePT46I/Y5ZptOc9MMFbigmZVIRm MV7+TWAGPgn7KqGJ7su/ghI6FNMiewvu2qnNQVq1RLo4BwQXwS1KzDmWBA60C+63JZOp ZQpAwtBp49/RxF42nd7rLesgbGfBWahzKGIVQXxfPW0+CnMV2V08XmJHLKSPFykVClRi jDxg== MIME-Version: 1.0 Received: by 10.68.136.162 with SMTP id qb2mr68495608pbb.67.1332905379830; Tue, 27 Mar 2012 20:29:39 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Tue, 27 Mar 2012 20:29:39 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Tue, 27 Mar 2012 20:29:39 -0700 (PDT) In-Reply-To: <4F726EFE.5010205@gmail.com> References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F60F458.4080403@gmail.com> <03FE6A726D13284495EF1787D25F1DF91F8C84D6@tk5ex14mbxc246.redmond.corp.microsoft.com> <4F726EFE.5010205@gmail.com> Date: Tue, 27 Mar 2012 20:29:39 -0700 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b10cfefaf1a6304bc45370f Cc: "homenet@ietf.org Group" , Mark Townsley , Dmitry Anipko Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 03:29:41 -0000 --047d7b10cfefaf1a6304bc45370f Content-Type: text/plain; charset=ISO-8859-1 On Mar 27, 2012 6:53 PM, "Brian E Carpenter" wrote: > > On 2012-03-28 11:58, Dmitry Anipko wrote: > > As someone who works for a host software vendor, I'd like to add couple of points. I agree with Mark that in general the security topic is wider than only filtering on the borders of the realms of the traffic destined to hosts, and I support the efforts to figure out the right set of knobs for the former. That said, for the latter, I'd like to see something along the below lines in the requirements > > (some of which may already be in the text in some form, putting it here just for fluency of this piece of the story). > > > > 1. Homenet hosts MUST implement their own security policies in accordance to their computing capabilities. > > I think we know from some famous cases that SCADA systems are highly > insecure, mainly due to following this principle (translated as > "security is too hard and this device will always be on a private > network anyway"). I'm a bit nervous that this policy will encourage > low-end device designers to classify their devices as not having > enough resource to deal with security. > This category should / will be eliminated by market forces, too much liability associated with being willfully insecure. There are famous cases for this too. If internet segmentation is all that is required, there are address types that facilitate local only access. Cb > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --047d7b10cfefaf1a6304bc45370f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 27, 2012 6:53 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> On 2012-03-28 11:58, Dmitry Anipko wrote:
> > As someone who works for a host software vendor, I'd like to = add couple of points. I agree with Mark that in general the security topic = is wider than only filtering on the borders of the realms of the traffic de= stined to hosts, and I support the efforts to figure out the right set of k= nobs for the former. That said, for the latter, I'd like to see somethi= ng along the below lines in the requirements
> > (some of which may already be in the text in some form, putting i= t here just for fluency of this piece of the story).
> >
> > 1. Homenet hosts MUST implement their own security policies in ac= cordance to their computing capabilities.
>
> I think we know from some famous cases that SCADA systems are highly > insecure, mainly due to following this principle (translated as
> "security is too hard and this device will always be on a private=
> network anyway"). I'm a bit nervous that this policy will enc= ourage
> low-end device designers to classify their devices as not having
> enough resource to deal with security.
>

This category should / will be eliminated by market forces, too much lia= bility associated with being willfully insecure.=A0 There are famous cases = for this too.

If internet segmentation is all that is required, there are address type= s that facilitate local only access.

Cb
> =A0 =A0Brian
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.= ietf.org/mailman/listinfo/homenet

--047d7b10cfefaf1a6304bc45370f-- From cb.list6@gmail.com Tue Mar 27 20:34:56 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763B421E8111 for ; Tue, 27 Mar 2012 20:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ci4+xvFvFCRr for ; Tue, 27 Mar 2012 20:34:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61FEB21E80CB for ; Tue, 27 Mar 2012 20:34:55 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so1149142pbb.31 for ; Tue, 27 Mar 2012 20:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4G37b8aji/nUcMnhOguojwe3pxoWFsJKPRxgWx+thBc=; b=pWEob1FI5HY6Y8/oh5BCZUHSgqAtcYrHvnW9gjcAez9N9dm7ildjj3wIh2yFCv4vNY osS7wDI4EdMl977kNQ17MpBRS78J40g1G8Rfptmn8QqwKplGZ+pSHppF6v+3gJr6WnFx Rpn1egYhu4zHLt386fJtMxySZ8FkaKXUejNpr62O7Efnv47v7R/QxS9CMF0gs1k0gcyf I2K8iFAKAnE0anAcHp2noFp4kXJf/AkYYALJLlsaNkv7wSW13PyenpYWQBDjAVZU/+2B iK3SzVS70ZQz53CqAlFNWjc/KqQg4blNGLE3D5FonHDUfY3282ZCGnnRhAu5ASkJPX36 sgew== MIME-Version: 1.0 Received: by 10.68.230.41 with SMTP id sv9mr67500817pbc.48.1332905695143; Tue, 27 Mar 2012 20:34:55 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Tue, 27 Mar 2012 20:34:55 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Tue, 27 Mar 2012 20:34:55 -0700 (PDT) In-Reply-To: <4F7272E3.60403@gmail.com> References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6BAC9F.10903@gmail.com> <4F7272E3.60403@gmail.com> Date: Tue, 27 Mar 2012 20:34:55 -0700 Message-ID: From: Cameron Byrne To: Brian E Carpenter Content-Type: multipart/alternative; boundary=047d7b339d697a689f04bc454ae2 Cc: homenet issue tracker , homenet@ietf.org, Dave Taht , tjc@ecs.soton.ac.uk, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 03:34:56 -0000 --047d7b339d697a689f04bc454ae2 Content-Type: text/plain; charset=ISO-8859-1 On Mar 27, 2012 7:09 PM, "Brian E Carpenter" wrote: > > Dave, > > On 2012-03-28 09:28, Dave Taht wrote: > > On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > >> On 2012-03-22 12:33, homenet issue tracker wrote: > >>> #4: Use of ULAs > >>> > >>> CN1 in the -02 text says ULAs should be provisioned by default. Do we > >>> agree? > >> Yes, by the CER (MUST). > >> > >> It's much less clear for all other routers on site. I would prefer that > >> no other router provisions a ULA prefix if the CER has already delegated > >> one. > >> > > > > Since it is nearly impossible to learn a subnet prefix that is unused > > unless all devices share a routing protocol, I have generally preferred to > > generate unique ULAs per routing device. > > Our two statements are not inconsistent... obviously, if a router comes > up and does not hear about a ULA prefix from another router, it may be > appropriate to generate a new one. But if we have a prefix delegation > mechanism in place, that may be sufficient. > > > > > > >>> And if so, should they be preferred over globals? > >> Yes. > >> > >> > > This part I don't quite understand. I would prefer global prefixes to > > always take precedence over ULAs. > > I'd like ULAs to try to talk only to ULAs. ULAs should not escape into the > > global DNS, but should end up in local dns. > > ULAs should really only be used to talk to ULAs, so when I say 'prefer ULAs', > I mean prefer a pair of ULAs to a pair of globals. In case it isn't clear, > in my mind the problem is always address *pair* selection. So that means > that a host should do something like this in the default case: > > Do I have a ULA? > If yes, does the other guy have a ULA (in the same prefix)? > If yes, use the two ULAs. > Else, use two globals. > > I'm hoping 3484bis will result in this. > In the general case, you don't believe ula and global should have communication at all? Or just a matter of source selection when multiple address types are available to a given host ? Cb > > > > Even with 'happy eyeballs', having a means to disable a ULA -> global > > connection by default saves 100s of ms in the bad cases. > > Agreed. > > Brian > > > > >>> The new > >>> 3484-bis has changed so they are not *unless* a specific /48 for the > >> site > >>> is added to the 3484 policy table with higher precedence than globals. > >> We > >>> should design something that works when disconnected from the Internet. > >> We'll have to deal with whatever 3484bis ends up saying. If it does > >> require an explicit policy table entry table, that will require > >> a mechanism, associated with the prefix delegation mechanism. > >> > > > > OK, I will re-read, thx for the update.. > > > > > >>> Also, we currently say nothing about ULA-only devices and their > >>> reachability from outside the homenet; do we want to? > >> I don't see what there is to say; they aren't reachable, and that's > >> a feature. > >> > >> Brian > >> _______________________________________________ > >> homenet mailing list > >> homenet@ietf.org > >> https://www.ietf.org/mailman/listinfo/homenet > >> > > > > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --047d7b339d697a689f04bc454ae2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 27, 2012 7:09 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote: >
> Dave,
>
> On 2012-03-28 09:28, Dave Taht wrote:
> > On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter <
> > brian.e.carpenter@= gmail.com> wrote:
> >
> >> On 2012-03-22 12:33, homenet issue tracker wrote:
> >>> #4: Use of ULAs
> >>>
> >>> =A0CN1 in the -02 text says ULAs should be provisioned by= default. =A0Do we
> >>> =A0agree?
> >> Yes, by the CER (MUST).
> >>
> >> It's much less clear for all other routers on site. I wou= ld prefer that
> >> no other router provisions a ULA prefix if the CER has alread= y delegated
> >> one.
> >>
> >
> > Since it is nearly impossible to learn a subnet prefix that is un= used
> > unless all devices share a routing protocol, I have generally pre= ferred to
> > generate unique ULAs per routing device.
>
> Our two statements are not inconsistent... obviously, if a router come= s
> up and does not hear about a ULA prefix from another router, it may be=
> appropriate to generate a new one. But if we have a prefix delegation<= br> > mechanism in place, that may be sufficient.
>
> >
> >
> >>> =A0And if so, should they be preferred over globals?
> >> Yes.
> >>
> >>
> > This part I don't quite understand. I would prefer global pre= fixes to
> > always take precedence over ULAs.
> > I'd like ULAs to try to talk only to ULAs. ULAs should not es= cape into the
> > global DNS, but should end up in local dns.
>
> ULAs should really only be used to talk to ULAs, so when I say 'pr= efer ULAs',
> I mean prefer a pair of ULAs to a pair of globals. In case it isn'= t clear,
> in my mind the problem is always address *pair* selection. So that mea= ns
> that a host should do something like this in the default case:
>
> =A0Do I have a ULA?
> =A0If yes, does the other guy have a ULA (in the same prefix)?
> =A0 =A0If yes, use the two ULAs.
> =A0Else, use two globals.
>
> I'm hoping 3484bis will result in this.
>

In the general case, you don't believe ula and global should have co= mmunication at all?=A0 Or just a matter of source selection when multiple a= ddress types are available to a given host ?

Cb

> >
> > Even with 'happy eyeballs', having a means to disable a U= LA -> global
> > connection by default saves 100s of ms in the bad cases.
>
> Agreed.
>
> =A0 Brian
>
> >
> >>> =A0The new
> >>> =A03484-bis has changed so they are not *unless* a specif= ic /48 for the
> >> site
> >>> =A0is added to the 3484 policy table with higher preceden= ce than globals.
> >> We
> >>> =A0should design something that works when disconnected f= rom the Internet.
> >> We'll have to deal with whatever 3484bis ends up saying. = If it does
> >> require an explicit policy table entry table, that will requi= re
> >> a mechanism, associated with the prefix delegation mechanism.=
> >>
> >
> > OK, I will re-read, thx for the update..
> >
> >
> >>> =A0Also, we currently say nothing about ULA-only devices = and their
> >>> =A0reachability from outside the homenet; do we want to?<= br> > >> I don't see what there is to say; they aren't reachab= le, and that's
> >> a feature.
> >>
> >> =A0 Brian
> >> _______________________________________________
> >> homenet mailing list
> >> homenet@ietf.org
> >> htt= ps://www.ietf.org/mailman/listinfo/homenet
> >>
> >
> >
> >
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.= ietf.org/mailman/listinfo/homenet

--047d7b339d697a689f04bc454ae2-- From Dmitry.Anipko@microsoft.com Tue Mar 27 22:47:57 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0612121E80D6 for ; Tue, 27 Mar 2012 22:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 hSpKixUbeYnL for ; Tue, 27 Mar 2012 22:47:56 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5419821E80C0 for ; Tue, 27 Mar 2012 22:47:55 -0700 (PDT) Received: from mail15-db3-R.bigfish.com (10.3.81.246) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Mar 2012 05:47:50 +0000 Received: from mail15-db3 (localhost [127.0.0.1]) by mail15-db3-R.bigfish.com (Postfix) with ESMTP id 2D15E360676; Wed, 28 Mar 2012 05:47:51 +0000 (UTC) X-SpamScore: -33 X-BigFish: VS-33(zz9371I936eKc85dh1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail15-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail15-db3 (localhost.localdomain [127.0.0.1]) by mail15-db3 (MessageSwitch) id 1332913668911687_28129; Wed, 28 Mar 2012 05:47:48 +0000 (UTC) Received: from DB3EHSMHS018.bigfish.com (unknown [10.3.81.253]) by mail15-db3.bigfish.com (Postfix) with ESMTP id D9BCA1800F1; Wed, 28 Mar 2012 05:47:48 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS018.bigfish.com (10.3.87.118) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Mar 2012 05:47:47 +0000 Received: from tk5ex14mbxc246.redmond.corp.microsoft.com ([169.254.11.95]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0283.004; Wed, 28 Mar 2012 05:47:44 +0000 From: Dmitry Anipko To: Cameron Byrne , Brian E Carpenter Thread-Topic: [homenet] Security goals Thread-Index: AQHM/yMmSvbYdJwNEEW8A+iww8NQ/pZlXK8AgAEOZYCAAmcPAIAAJRCAgAAKkwCAACVeAIAAHF2AgADzCgCACasegIAK+N5xgAAyNwCAABr+gIAAJI9Q Date: Wed, 28 Mar 2012 05:47:44 +0000 Message-ID: <03FE6A726D13284495EF1787D25F1DF91F8C8974@tk5ex14mbxc246.redmond.corp.microsoft.com> References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F60F458.4080403@gmail.com> <03FE6A726D13284495EF1787D25F1DF91F8C84D6@tk5ex14mbxc246.redmond.corp.microsoft.com> <4F726EFE.5010205@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: multipart/alternative; boundary="_000_03FE6A726D13284495EF1787D25F1DF91F8C8974tk5ex14mbxc246r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "homenet@ietf.org Group" , Mark Townsley Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 05:47:57 -0000 --_000_03FE6A726D13284495EF1787D25F1DF91F8C8974tk5ex14mbxc246r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, I personally would definitely want to see a stronger statement that hosts s= hould be implementing means sufficient to perform end 2 end communication s= ecurely on any network, without requiring additional protections from outsi= de. But I guess a few people would then argue that some hosts can't impleme= nt the same degree of security protection as the degree e.g. tablets and P= C can - and that guess led to the current lanuage. If you think it should be changed to some stronger statement, do you have s= omething specific in mind? -Dmitry ________________________________ From: Cameron Byrne [cb.list6@gmail.com] Sent: Tuesday, March 27, 2012 8:29 PM To: Brian E Carpenter Cc: Mark Townsley; Dmitry Anipko; homenet@ietf.org Group Subject: Re: [homenet] Security goals On Mar 27, 2012 6:53 PM, "Brian E Carpenter" > wrote: > > On 2012-03-28 11:58, Dmitry Anipko wrote: > > As someone who works for a host software vendor, I'd like to add couple= of points. I agree with Mark that in general the security topic is wider t= han only filtering on the borders of the realms of the traffic destined to = hosts, and I support the efforts to figure out the right set of knobs for t= he former. That said, for the latter, I'd like to see something along the b= elow lines in the requirements > > (some of which may already be in the text in some form, putting it here= just for fluency of this piece of the story). > > > > 1. Homenet hosts MUST implement their own security policies in accordan= ce to their computing capabilities. > > I think we know from some famous cases that SCADA systems are highly > insecure, mainly due to following this principle (translated as > "security is too hard and this device will always be on a private > network anyway"). I'm a bit nervous that this policy will encourage > low-end device designers to classify their devices as not having > enough resource to deal with security. > This category should / will be eliminated by market forces, too much liabil= ity associated with being willfully insecure. There are famous cases for t= his too. If internet segmentation is all that is required, there are address types t= hat facilitate local only access. Cb > Brian > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --_000_03FE6A726D13284495EF1787D25F1DF91F8C8974tk5ex14mbxc246r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Brian,

 

I personally would definitely want to see a stronger statement that host= s should be implementing means sufficient to perform end 2 end communi= cation securely on any network, without requiring additional protectio= ns from outside. But I guess a few people would then argue that some hosts can't implement the same degree of securi= ty protection as  the degree e.g. tablets and PC can - and that g= uess led to the current lanuage.

 

If you think it should be changed to some stronger statement, do you hav= e something specific in mind?

 

-Dmitry

 

 

From: Cameron Byrne [cb.list6@gmail.com] Sent: Tuesday, March 27, 2012 8:29 PM
To: Brian E Carpenter
Cc: Mark Townsley; Dmitry Anipko; homenet@ietf.org Group
Subject: Re: [homenet] Security goals


On Mar 27, 2012 6:53 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.co= m> wrote:
>
> On 2012-03-28 11:58, Dmitry Anipko wrote:
> > As someone who works for a host software vendor, I'd like to add = couple of points. I agree with Mark that in general the security topic is w= ider than only filtering on the borders of the realms of the traffic destin= ed to hosts, and I support the efforts to figure out the right set of knobs for the former. That said, for the la= tter, I'd like to see something along the below lines in the requirements > > (some of which may already be in the text in some form, putting i= t here just for fluency of this piece of the story).
> >
> > 1. Homenet hosts MUST implement their own security policies in ac= cordance to their computing capabilities.
>
> I think we know from some famous cases that SCADA systems are highly > insecure, mainly due to following this principle (translated as
> "security is too hard and this device will always be on a private=
> network anyway"). I'm a bit nervous that this policy will encoura= ge
> low-end device designers to classify their devices as not having
> enough resource to deal with security.
>

This category should / will be eliminated by market forces, too much lia= bility associated with being willfully insecure.  There are famous cas= es for this too.

If internet segmentation is all that is required, there are address type= s that facilitate local only access.

Cb
>    Brian
> _______________________________________________
> homenet mailing list
> homenet@ietf.org=
> https://www.ietf.org/mailman/listinfo/homenet

--_000_03FE6A726D13284495EF1787D25F1DF91F8C8974tk5ex14mbxc246r_-- From ek@google.com Wed Mar 28 00:41:52 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870D921F87C9 for ; Wed, 28 Mar 2012 00:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.857 X-Spam-Level: X-Spam-Status: No, score=-102.857 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 mWNvALtgUtzF for ; Wed, 28 Mar 2012 00:41:51 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B507A21F87B7 for ; Wed, 28 Mar 2012 00:41:51 -0700 (PDT) Received: by qcsq13 with SMTP id q13so552369qcs.31 for ; Wed, 28 Mar 2012 00:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=OeEkHJgcd8LEzIJGz/WF/mjS3uvsrF74nMArYwMwqVk=; b=n/OLLESmkMbkvalwzOAGSFHcbR3jALCj5VutCcooJAHo+9aAw5JuuFVv5Zot5r+lQA AxvYpqD2LVGPXcrjJth1FYTjwZbUrLVNCfoZlVBmsGdgmXhSPTqbC+n0GmYfR18WZF2e kPP1u+VjAVMe0ogiO8wLGj4kVzHbaD/O+HPt/AB+ejfq1k/eVlMDmxJ9q5u/WQBqtQb0 KGD9EpilRaPVI7OMtgH884ZzHBwJv7mQjVNwIjmUKDKM3V7ds5Jsda7TncD8fAs7zR+W xcJuLVtfHbyLbgDmDZwIz955YpGFpfZFDKYhJeUhmLy8lAzFgzNH6A/pgNHNLuYY26XO hwiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=OeEkHJgcd8LEzIJGz/WF/mjS3uvsrF74nMArYwMwqVk=; b=hk2W3/IVt0uy7KBb/MXJg+erYuZKFoMSIEnUlqs8G5qKZyUDl+rEl2Isy2Z0CR3qs4 tDtjihvKD/BQRT/M5eNdGgGq+Mmtd1vaNJNEuN5g/WePTCBZpP39Xh6fGaBi8oj+a43w 7yXQeA+znzJz0w6HzJJw3SaD7hQa3oJLduVrNYqFZBoWffQHBELxqbTd4coZ6xzYK/lp ERX5yh4KK2inpaoyZKherdd1e4yrEx7y9gaNwaSQzyb+XperhjPIs0dXFTZdcXt2N9K+ SnBS/YL1HMDNmaFJrktnKLeOBZLeXrKbhOY8G7YcYSJuI2rDtCSIAWIddk/SOWj/YH9u CeAw== Received: by 10.224.33.9 with SMTP id f9mr6989709qad.49.1332920511138; Wed, 28 Mar 2012 00:41:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.33.9 with SMTP id f9mr6989701qad.49.1332920511061; Wed, 28 Mar 2012 00:41:51 -0700 (PDT) Received: by 10.229.128.170 with HTTP; Wed, 28 Mar 2012 00:41:51 -0700 (PDT) Date: Wed, 28 Mar 2012 07:41:51 +0000 Message-ID: From: Erik Kline To: Mark Townsley Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl+FDle7f/pfpRKHs+NJEWGUHkb3ge4Da/HA5xeHlN6PxkrDuTOXWFD359efPcradWk7UHYEFsQO+5TVO35F+tPvU6g4j1BefYKQpOKqpGaf7LIZkxbVGSMzdcVFIGOZ69E5dWV Cc: homenet@ietf.org Subject: [homenet] one IAB quotation on walled gardens X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:41:52 -0000 Mark, For the record, the walled garden citation I quoted was from: http://tools.ietf.org/html/rfc3002#section-4.2 (really section 4.2.1) """ It was strongly recommended that independent of the ubiquity of the "walled garden" deployment scenario that protocols and architectural decisions should not target this model. To continue the success of Internet protocols at operating across a highly diverse and heterogeneous environment the IETF must continue to foster the adoption of an "open model". IETF protocol design must address seamless, secure, and scalable access." """ I read this as: don't design for walled gardens. If they can be made to work so be it, but they can't really serve as a valid motivation. This was the closest IAB statement I could find on walled gardens. Maybe there's another IAB comment someone can find/make. -Erik From v6ops@globis.net Wed Mar 28 00:44:10 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE9321F8810 for ; Wed, 28 Mar 2012 00:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 FYTz-cghY5gL for ; Wed, 28 Mar 2012 00:44:09 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA2921F881F for ; Wed, 28 Mar 2012 00:44:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3763C8700EF; Wed, 28 Mar 2012 09:44:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUqlRXZj2OwQ; Wed, 28 Mar 2012 09:44:02 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id F278A8700EE; Wed, 28 Mar 2012 09:44:01 +0200 (CEST) Message-ID: <4F72C141.6000202@globis.net> Date: Wed, 28 Mar 2012 09:44:01 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Dave Taht , "homenet@ietf.org" References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6BAC9F.10903@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020906010307090102040302" Cc: Anders Brandt , Tim Chown Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 07:44:10 -0000 This is a multi-part message in MIME format. --------------020906010307090102040302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit See below. Dave Taht wrote: > On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter > > wrote: > > On 2012-03-22 12:33, homenet issue tracker wrote: > > #4: Use of ULAs > > > > CN1 in the -02 text says ULAs should be provisioned by default. > Do we > > agree? > > Yes, by the CER (MUST). > Firstly are we stating *the* CER or *a* CER? What happens when there is more than one CER? Does that then need an election process? And when the "winner" disappears because you've changed providers or router hardware or the router fails, all ULA's also get renumbered? > > It's much less clear for all other routers on site. I would prefer > that > no other router provisions a ULA prefix if the CER has already > delegated > one. > > > Since it is nearly impossible to learn a subnet prefix that is unused > unless all devices share a routing protocol, I have generally > preferred to generate unique ULAs per routing device. > Generating a ULA independently per router is potentially going to bring problems with the new RFC3484-revise as they'll almost certainly have different Global ID's (and thus a different /48 prefix), so ULA will not be preferred for communication between nodes connected to different routers. Sometimes it's useful to take a complete opposite view to the way you've been thinking, and work though the consequences. What about going to the extreme and giving up on central/coordinated control of a single ULA /48 Global ID throughout the Homenet? What about tolerating static prefix assignments (for sensor networks)? We allow static individual IPv6 address assignments to end nodes as well as SLAAC, so why not tolerate statically assigned /64 prefixes? Even in Appletalk, the much vaunted champion of autoconfiguration, a network manager had to manually assign the network number range to at least one seed router in an extended network. How about: - multiple ULA /48 Global ID's within a single Homenet is not considered an "error" Every router may generate it's own ULA /48 Global ID independently, or use an existing one generated by another router. That gets rid of any time-ordering of installation, net splitting or net fusing issues. Also allows the electrician to set up his sensor network before the ISP arrives (or vice versa) - routers should configure up one /64 prefix per interface for each ULA /48 Global ID present in the Homenet. This could use the same prefix assignment mechanism as PA addresses learned via DHCPv6 PD from the ISP. Each router could perhaps act as the seed router for its own ULA /48 Global ID in the prefix assignment process. All of the ULA /48 Global ID's would be distributed throughout the complete Homenet network, so that if a router is added to the Homenet it may be an additional/new ULA /48 Global ID in the Homenet network, but the original ULA /64 prefixes derived from other routers' ULA /48 Global ID's will still be available on all interfaces. That copes with mobile nodes and routers that are bought and sold. It also copes with failure of a single "master" router. - every end node and router using RFC3484-revise should also configure up a ULA address for every ULA /64 prefix present. Dumb sensors may simply ignore 3484-revise (it's only informational) and always prefer ULA. End nodes using 3484-revise would now have a native ULA address from each ULA /48 Global ID, and therefore the proposed new rule in RFC3484-revise of source /48 ULA = destination /48 ULA would come into play and ULA would always be preferred for local communications. You may end up with two or more usable ULA pairs between any two nodes, but is that a problem when we want high availability, and provider independence? - prefix assignment autoconfiguration should avoid assigning prefixes that conflict with statically configured prefixes (e.g. hard coded sensor networks). That may require changing the tie-break mechanism in e.g. draft-baker-homenet-prefix-assignment-01 so that a router with a static /64 prefix assignment can veto all other routers who (accidentally) try to auto-assign the same /64 and thus cause a collision. So it would be the equivalent of Duplicate Address Detection, but at the /64 prefix level. OK each end node and router would have lots of prefixes and addresses (possibly two or more per router in the homenet) but isn't that less problematic than trying to centrally gather the ULA /48 Global ID's in use and then distribute an updated RFC3484-revise policy table to all end nodes, or magically electing a master node to coordinate the choice of a single ULA /48 Global ID? regards, RayH --------------020906010307090102040302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit See below.

Dave Taht wrote:
On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 2012-03-22 12:33, homenet issue tracker wrote:
> #4: Use of ULAs
>
>  CN1 in the -02 text says ULAs should be provisioned by default.  Do we
>  agree?

Yes, by the CER (MUST).

Firstly are we stating *the* CER or *a* CER? What happens when there is more than one CER? Does that then need an election process? And when the "winner" disappears because you've changed providers or router hardware or the router fails, all ULA's also get renumbered?
It's much less clear for all other routers on site. I would prefer that
no other router provisions a ULA prefix if the CER has already delegated
one.

Since it is nearly impossible to learn a subnet prefix that is unused unless all devices share a routing protocol, I have generally preferred to generate unique ULAs per routing device.
 
Generating a ULA independently per router is potentially going to bring problems with the new RFC3484-revise as they'll almost certainly have different Global ID's (and thus a different /48 prefix), so ULA will not be preferred for communication between nodes connected to different routers.



Sometimes it's useful to take a complete opposite view to the way you've been thinking, and work though the consequences.

What about going to the extreme and giving up on central/coordinated control of a single ULA /48 Global ID throughout the Homenet?

What about tolerating static prefix assignments (for sensor networks)? We allow static individual IPv6 address assignments to end nodes as well as SLAAC, so why not tolerate statically assigned /64 prefixes? Even in Appletalk, the much vaunted champion of autoconfiguration, a network manager had to manually assign the network number range to at least one seed router in an extended network.


How about:

- multiple ULA /48 Global ID's within a single Homenet is not considered an "error"

   Every router may generate it's own ULA /48 Global ID independently, or use an existing one generated by another router.
   That gets rid of any time-ordering of installation, net splitting or net fusing issues.
   Also allows the electrician to set up his sensor network before the ISP arrives (or vice versa)

- routers should configure up one /64 prefix per interface for each ULA /48 Global ID present in the Homenet.

  This could use the same prefix assignment mechanism as PA addresses learned via DHCPv6 PD from the ISP.
  Each router could perhaps act as the seed router for its own ULA /48 Global ID in the prefix assignment process.
  All of the ULA /48 Global ID's would be distributed throughout the complete Homenet network, so that if a router
  is added to the Homenet it may be an additional/new ULA /48 Global ID in the Homenet network,
  but the original ULA /64 prefixes derived from other routers' ULA /48 Global ID's will still be available on all interfaces.
  That copes with mobile nodes and routers that are bought and sold. It also copes with failure of a single "master" router.

- every end node and router using RFC3484-revise should also configure up a ULA address for every ULA /64 prefix present.

  Dumb sensors may simply ignore 3484-revise (it's only informational) and always prefer ULA.
  End nodes using 3484-revise would now have a native ULA address from each ULA /48 Global ID,
  and therefore the proposed new rule in RFC3484-revise of source /48 ULA = destination /48 ULA would
  come into play and ULA would always be preferred for local communications.

  You may end up with two or more usable ULA pairs between any two nodes,
  but is that a problem when we want high availability, and provider independence?

- prefix assignment autoconfiguration should avoid assigning prefixes that conflict with statically configured prefixes
  (e.g. hard coded sensor networks).

  That may require changing the tie-break mechanism in e.g. draft-baker-homenet-prefix-assignment-01
  so that a router with a static /64 prefix assignment can veto all other routers who (accidentally)
  try to auto-assign the same /64 and thus cause a collision.

  So it would be the equivalent of Duplicate Address Detection, but at the /64 prefix level.


OK each end node and router would have lots of prefixes and addresses (possibly two or more per router in the homenet) but isn't that less problematic than trying to centrally gather the ULA /48 Global ID's in use and then distribute an updated RFC3484-revise policy table to all end nodes, or magically electing a master node to coordinate the choice of a single ULA /48 Global ID?


regards,
RayH
--------------020906010307090102040302-- From dave.taht@gmail.com Wed Mar 28 01:25:32 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02A221F886A for ; Wed, 28 Mar 2012 01:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 dHiMgGcQFPHR for ; Wed, 28 Mar 2012 01:25:30 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD8621F8879 for ; Wed, 28 Mar 2012 01:25:28 -0700 (PDT) Received: by werb10 with SMTP id b10so555077wer.31 for ; Wed, 28 Mar 2012 01:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aXm2+pYwuP/seLSRuVwsBKItLEMAr5TlgCghOjitLUM=; b=HeUH6nVRUTBPaSeANucx8Y/8vy4onM5d+FMtq2gbI5FJhL+kFA1ns3W7Bk14i+B6k4 BIJ61aK+Ep7fBbGE+jOLlR6B9f2AA5l1rqMsZeqA/ry7jIhSg2mjzjHeKgx8IZSorUG9 eaHbAouuIJ5r0ZVmiSKf2lo/Hc2S80dYizjp5QqmpSTo+3Hmozia0JRlz6AXGXwCcUZw 5aAHfIjhFXOr034lmQBpNGbWV0kBRn3I4L7M2d9Z+MnKrhus69adiDwovxKGCNiO0HMo alEKWkxTjO1wUtgs8XTSe5oGa5R09Itm/rl/M2GzRCfOVIRclcZSUUZ1ZpV2h0T0H9mW hQSg== MIME-Version: 1.0 Received: by 10.216.85.81 with SMTP id t59mr17207891wee.28.1332923127869; Wed, 28 Mar 2012 01:25:27 -0700 (PDT) Received: by 10.223.127.194 with HTTP; Wed, 28 Mar 2012 01:25:27 -0700 (PDT) In-Reply-To: <4F72C141.6000202@globis.net> References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6BAC9F.10903@gmail.com> <4F72C141.6000202@globis.net> Date: Wed, 28 Mar 2012 01:25:27 -0700 Message-ID: From: Dave Taht To: Ray Hunter Content-Type: multipart/alternative; boundary=0016e6d7dffa8cb11804bc4959e5 Cc: "homenet@ietf.org" , Tim Chown , Anders Brandt Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 08:25:32 -0000 --0016e6d7dffa8cb11804bc4959e5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2012 at 12:44 AM, Ray Hunter wrote: > ** > See below. > > > Dave Taht wrote: > > On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 2012-03-22 12:33, homenet issue tracker wrote: >> > #4: Use of ULAs >> > >> > CN1 in the -02 text says ULAs should be provisioned by default. Do w= e >> > agree? >> >> Yes, by the CER (MUST). >> >> Firstly are we stating *the* CER or *a* CER? What happens when there > is more than one CER? Does that then need an election process? And when t= he > "winner" disappears because you've changed providers or router hardware o= r > the router fails, all ULA's also get renumbered? > > It's much less clear for all other routers on site. I would prefer that >> no other router provisions a ULA prefix if the CER has already delegated >> one. > > > Since it is nearly impossible to learn a subnet prefix that is unused > unless all devices share a routing protocol, I have generally preferred t= o > generate unique ULAs per routing device. > > > Generating a ULA independently per router is potentially going to bring > problems with the new RFC3484-revise as they'll almost certainly have > different Global ID's (and thus a different /48 prefix), so ULA will not = be > preferred for communication between nodes connected to different routers. > > As I'm arguing with a draft that I haven't read, I'm a little at a loss. Will certainly have different global ids. ULA should be preferred for communication between nodes connected to different routers if they are both in the ULA space. Consider linking two offices via vpn, for example.... Other arguments are other autonomous devices (like devices that have arbitrary numbers of subnets, like routers... your car...) or sensor networks... (01:09:33 AM) dtaht: There simply aren't enough routes in a homenet to fill a routing table inside the home (01:09:43 AM) dtaht: even if every router chooses a unique ULA > > Sometimes it's useful to take a complete opposite view to the way you've > been thinking, and work though the consequences. > > What about going to the extreme and giving up on central/coordinated > control of a single ULA /48 Global ID throughout the Homenet? > > Love it. > What about tolerating static prefix assignments (for sensor networks)? We > allow static individual IPv6 address assignments to end nodes as well as > SLAAC, so why not tolerate statically assigned /64 prefixes? Even in > Appletalk, the much vaunted champion of autoconfiguration, a network > manager had to manually assign the network number range to at least one > seed router in an extended network. > > > How about: > > - multiple ULA /48 Global ID's within a single Homenet is not considered > an "error" > > OK. > Every router may generate it's own ULA /48 Global ID independently, or > use an existing one generated by another router. > Works for me. > That gets rid of any time-ordering of installation, net splitting or > net fusing issues. > Also allows the electrician to set up his sensor network before the IS= P > arrives (or vice versa) > > - routers should configure up one /64 prefix per interface for each ULA > /48 Global ID present in the Homenet. > > > This could use the same prefix assignment mechanism as PA addresses > learned via DHCPv6 PD from the ISP. > SLAAC generally works fine. > Each router could perhaps act as the seed router for its own ULA /48 > Global ID in the prefix assignment process. > All of the ULA /48 Global ID's would be distributed throughout the > complete Homenet network, so that if a router > is added to the Homenet it may be an additional/new ULA /48 Global ID i= n > the Homenet network, > but the original ULA /64 prefixes derived from other routers' ULA /48 > Global ID's will still be available on all interfaces. > That copes with mobile nodes and routers that are bought and sold. It > also copes with failure of a single "master" router. > > yes. > - every end node and router using RFC3484-revise should also configure up > a ULA address for every ULA /64 prefix present. > > is this the exact draft to which you are referring? http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484-revise/ Dumb sensors may simply ignore 3484-revise (it's only informational) and > always prefer ULA. > End nodes using 3484-revise would now have a native ULA address from > each ULA /48 Global ID, > and therefore the proposed new rule in RFC3484-revise of source /48 ULA > =3D destination /48 ULA would > come into play and ULA would always be preferred for local > communications. > > I think we are in disagreement here. But I'm going to stop now, resume the conference, and play catchup on this draft later. You may end up with two or more usable ULA pairs between any two nodes, > but is that a problem when we want high availability, and provider > independence? > > - prefix assignment autoconfiguration should avoid assigning prefixes tha= t > conflict with statically configured prefixes > (e.g. hard coded sensor networks). > > That may require changing the tie-break mechanism in e.g. > draft-baker-homenet-prefix-assignment-01 > so that a router with a static /64 prefix assignment can veto all other > routers who (accidentally) > try to auto-assign the same /64 and thus cause a collision. > > So it would be the equivalent of Duplicate Address Detection, but at th= e > /64 prefix level. > > > OK each end node and router would have lots of prefixes and addresses > (possibly two or more per router in the homenet) but isn't that less > problematic than trying to centrally gather the ULA /48 Global ID's in us= e > and then distribute an updated RFC3484-revise policy table to all end > nodes, or magically electing a master node to coordinate the choice of a > single ULA /48 Global ID? > > > regards, > RayH > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net --0016e6d7dffa8cb11804bc4959e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=A0=A0 That gets rid of any time-ordering of installation, net splitting or net fusing issues.
=A0=A0 Also allows the electrician to set up his sensor network before the ISP arrives (or vice versa)

- routers should configure up one /64 prefix per interface for each ULA /48 Global ID present in the Homenet.


=A0 This could use the same prefix assignment mechanism as PA addresses learned via DHCPv6 PD from the ISP.

SLAAC ge= nerally works fine.
=A0
=A0 Each router could perhaps act as the seed router for its own ULA /48 Global ID in the prefix assignment process.
=A0 All of the ULA /48 Global ID's would be distributed throughout the complete Homenet network, so that if a router
=A0 is added to the Homenet it may be an additional/new ULA /48 Global ID in the Homenet network,
=A0 but the original ULA /64 prefixes derived from other routers' ULA /= 48 Global ID's will still be available on all interfaces.
=A0 That copes with mobile nodes and routers that are bought and sold. It also copes with failure of a single "master" router.


yes.
=A0
- every end node and router using RFC3484-revise should also configure up a ULA address for every ULA /64 prefix present.


=A0is this the exact draft to which you are= referring?

http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484= -revise/

=A0 Dumb sensors may simply ignore 3484-revise (it's only informational= ) and always prefer ULA.
=A0 End nodes using 3484-revise would now have a native ULA address from each ULA /48 Global ID,
=A0 and therefore the proposed new rule in RFC3484-revise of source /48 ULA =3D destination /48 ULA would
=A0 come into play and ULA would always be preferred for local communications.


I think we are in disagreement here.
But I'm going to stop now, resume the conference, and play catchup on = this draft later.

=A0 You may end up with two or more usable ULA pairs between any two nodes,
=A0 but is that a problem when we want high availability, and provider independence?

- prefix assignment autoconfiguration should avoid assigning prefixes that conflict with statically configured prefixes
=A0 (e.g. hard coded sensor networks).

=A0 That may require changing the tie-break mechanism in e.g. draft-baker-homenet-prefix-assignment-01
=A0 so that a router with a static /64 prefix assignment can veto all other routers who (accidentally)
=A0 try to auto-assign the same /64 and thus cause a collision.

=A0 So it would be the equivalent of Duplicate Address Detection, but at the /64 prefix level.


OK each end node and router would have lots of prefixes and addresses (possibly two or more per router in the homenet) but isn't that less problematic than trying to centrally gather the ULA /48 Global ID's in use and then distribute an updated RFC3484-revise policy table to all end nodes, or magically electing a master node to coordinate the choice of a single ULA /48 Global ID?


regards,
RayH



--
Dave T=E4ht
SKYPE: d= avetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
--0016e6d7dffa8cb11804bc4959e5-- From v6ops@globis.net Wed Mar 28 02:07:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E55121F8549 for ; Wed, 28 Mar 2012 02:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 KveGGIjp9itb for ; Wed, 28 Mar 2012 02:07:36 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 780E021F8547 for ; Wed, 28 Mar 2012 02:07:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5D70387008A; Wed, 28 Mar 2012 11:07:35 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JRGf7oyD6NB; Wed, 28 Mar 2012 11:07:29 +0200 (CEST) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C4F04870082; Wed, 28 Mar 2012 11:07:29 +0200 (CEST) Message-ID: <4F72D4D1.7080007@globis.net> Date: Wed, 28 Mar 2012 11:07:29 +0200 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Dave Taht References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6BAC9F.10903@gmail.com> <4F72C141.6000202@globis.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090103040304000008060603" Cc: "homenet@ietf.org" Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:07:38 -0000 This is a multi-part message in MIME format. --------------090103040304000008060603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit AFAIK http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-05 was the discussion to provide a delta update to 3484, so you'll find most of the background discussion there. But the delta got so big that http://tools.ietf.org/html/draft-ietf-6man-rfc3484bis-01 attempts to merge these changes back into 3484 to create one complete doc that replaces the original 3484. Dave Taht wrote: > is this the exact draft to which you are referring? > > http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484-revise/ > > > > --------------090103040304000008060603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit AFAIK  http://tools.ietf.org/html/draft-ietf-6man-rfc3484-revise-05 was the discussion to provide a delta update to 3484, so you'll find most of the background discussion there.

But the delta got so big that http://tools.ietf.org/html/draft-ietf-6man-rfc3484bis-01 attempts to merge these changes back into 3484 to create one complete doc that replaces the original 3484.

Dave Taht wrote:
 is this the exact draft to which you are referring?

http://datatracker.ietf.org/doc/draft-ietf-6man-rfc3484-revise/




--------------090103040304000008060603-- From john_brzozowski@cable.comcast.com Wed Mar 28 02:53:47 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C9421F89C3 for ; Wed, 28 Mar 2012 02:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.831 X-Spam-Level: X-Spam-Status: No, score=-100.831 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 wSa2IvAoh7dk for ; Wed, 28 Mar 2012 02:53:46 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 95A8B21F89AF for ; Wed, 28 Mar 2012 02:53:46 -0700 (PDT) Received: from ([24.40.56.114]) by pacdcavaout01.cable.comcast.com with ESMTP id 97wm3m1.7403350; Wed, 28 Mar 2012 05:46:56 -0400 Received: from PACDCEXMB01.cable.comcast.com ([fe80::3cf0:9cac:6c2a:7359]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%13]) with mapi id 14.01.0355.002; Wed, 28 Mar 2012 05:53:02 -0400 From: "Brzozowski, John" To: homenet issue tracker , "draft-ietf-homenet-arch@tools.ietf.org" , Tim Chown Thread-Topic: [homenet] #8: Proxy or extend? Thread-Index: AQHNDMiP3JBRdRfzgE6PlpYLNdvFKw== Date: Wed, 28 Mar 2012 09:53:01 +0000 Message-ID: In-Reply-To: <061.0f56e01bdeae967db6e91124c7a45ce1@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="Windows-1252" Content-ID: <66C3CD08A95A234F88FA5ED2C9ACC4A3@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "homenet@ietf.org" Subject: Re: [homenet] #8: Proxy or extend? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:53:47 -0000 We have been discussing the applicability of this in the context of advanced, dual stack premise networking. From our perspective there is a need for this particularly with regards to premises that have multiple, routed subnets. It seems to me that we need not reinvent the mechanisms for service discovery/advertisement. To comment on the question below, I believe we should be providing guidance on this topic. This will help to ensure that some minimum functionality is specified. This will still leave room for differentiation, etc. If the mechanism is provided then any service could conceivably be discovered using the same. Based on my thinking so far proxies could present resource challenges for some types of devices, conversely extension may be slightly more complicated. More to come on proxy versus extension. John=20 -----Original Message----- From: homenet issue tracker Date: Wed, 21 Mar 2012 23:42:35 +0000 To: , Tim Chown Cc: Subject: [homenet] #8: Proxy or extend? Resent-From: Resent-Date: Wed, 21 Mar 2012 16:42:42 -0700 >#8: Proxy or extend? > > Do we wish to state a preference for how protocols that currently work > within a single subnet can be made to work within a multi-subnet homenet > site? Proxies could be defined at subnet boundaries (e.g. as per DHCPv6 > relays) or protocols could be extended to site scope (e.g. the recent > xmDNS proposal). Or is this a per-protocol decision? > >--=20 >-------------------+--------------------------------------- > Reporter: tjc@=8A | Owner: draft-ietf-homenet-arch@=8A > Type: task | Status: new > Priority: major | Milestone: >Component: arch | Version: > Severity: - | Keywords: >-------------------+--------------------------------------- > >Ticket URL: >homenet > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From robert.cragie@gridmerge.com Wed Mar 28 04:19:10 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DB421E801A for ; Wed, 28 Mar 2012 04:19:10 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 UHLDRJmHVg7j for ; Wed, 28 Mar 2012 04:19:09 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 305FD21E8019 for ; Wed, 28 Mar 2012 04:19:09 -0700 (PDT) Received: from client-82-26-130-230.pete-bam-1.adsl.virginmedia.com ([82.26.130.230] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SCquA-000229-MP for homenet@ietf.org; Wed, 28 Mar 2012 12:19:07 +0100 Message-ID: <4F72F413.2040507@gridmerge.com> Date: Wed, 28 Mar 2012 12:20:51 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: homenet@ietf.org References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F60F458.4080403@gmail.com> <03FE6A726D13284495EF1787D25F1DF91F8C84D6@tk5ex14mbxc246.redmond.corp.microsoft.com> <4F726EFE.5010205@gmail.com>, <03FE6A726D13284495EF1787D25F1DF91F8C8974@tk5ex14mbxc246.redmond.corp.microsoft.com> In-Reply-To: <03FE6A726D13284495EF1787D25F1DF91F8C8974@tk5ex14mbxc246.redmond.corp.microsoft.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090709060904040705010105" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 11:19:11 -0000 This is a cryptographically signed message in MIME format. --------------ms090709060904040705010105 Content-Type: multipart/alternative; boundary="------------000705030306010003050502" This is a multi-part message in MIME format. --------------000705030306010003050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I think there are two orthogonal aspects here. There is one regarding=20 the ability for host to perform end to end communication securely (i.e=20 with integrity and/or confidentiality). This goes without saying and I=20 agree there needs to be a strong statement regarding this. However this=20 is orthogonal to a host's ability to handle all manner of traffic which=20 could be directed to it, especially malicious traffic. Ideally hosts=20 would be able to handle this and the recommendation would still be to=20 require hosts to firewall their own data. When a host is implemented on=20 a platform with plenty of storage and processing power, this is not=20 really an issue. However, in the LLN case, hosts may be running on=20 platforms which have very little storage and processing power by=20 comparison with limited ability to firewall. I do not think we should be = precluding these type of devices. Robert On 28/03/2012 6:47 AM, Dmitry Anipko wrote: > > Brian, > > I personally would definitely want to see a stronger statement that=20 > hosts should be implementing means sufficient to perform end 2 end=20 > communication securely on any network, without requiring additional=20 > protections from outside. But I guess a few people would then argue=20 > that some hosts can't implement the same degree of security protection = > as the degree e.g. tablets and PC can - and that guess led to the=20 > current lanuage. > > If you think it should be changed to some stronger statement, do you=20 > have something specific in mind? > > -Dmitry > > -----------------------------------------------------------------------= - > *From:* Cameron Byrne [cb.list6@gmail.com] > *Sent:* Tuesday, March 27, 2012 8:29 PM > *To:* Brian E Carpenter > *Cc:* Mark Townsley; Dmitry Anipko; homenet@ietf.org Group > *Subject:* Re: [homenet] Security goals > > > On Mar 27, 2012 6:53 PM, "Brian E Carpenter"=20 > > wrot= e: > > > > On 2012-03-28 11:58, Dmitry Anipko wrote: > > > As someone who works for a host software vendor, I'd like to add=20 > couple of points. I agree with Mark that in general the security topic = > is wider than only filtering on the borders of the realms of the=20 > traffic destined to hosts, and I support the efforts to figure out the = > right set of knobs for the former. That said, for the latter, I'd like = > to see something along the below lines in the requirements > > > (some of which may already be in the text in some form, putting it = > here just for fluency of this piece of the story). > > > > > > 1. Homenet hosts MUST implement their own security policies in=20 > accordance to their computing capabilities. > > > > I think we know from some famous cases that SCADA systems are highly > > insecure, mainly due to following this principle (translated as > > "security is too hard and this device will always be on a private > > network anyway"). I'm a bit nervous that this policy will encourage > > low-end device designers to classify their devices as not having > > enough resource to deal with security. > > > > This category should / will be eliminated by market forces, too much=20 > liability associated with being willfully insecure. There are famous=20 > cases for this too. > > If internet segmentation is all that is required, there are address=20 > types that facilitate local only access. > > Cb > > Brian > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --------------000705030306010003050502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think there are two orthogonal aspects here. There is one regarding the ability for host to perform end to end communication securely (i.e with integrity and/or confidentiality). This goes without saying and I agree there needs to be a strong statement regarding this. However this is orthogonal to a host's ability to handle all manner of traffic which could be directed to it, especially malicious traffic. Ideally hosts would be able to handle this and the recommendation would still be to require hosts to firewall their own data. When a host is implemented on a platform with plenty of storage and processing power, this is not really an issue. However, in the LLN case, hosts may be running on platforms which have very little storage and processing power by comparison with limited ability to firewall. I do not think we should be precluding these type of devices.

Robert

On 28/03/2012 6:47 AM, Dmitry Anipko wrote:

Brian,

 

I personally would definitely want to see a stronger statement that hosts should be implementing means sufficient to perform end 2 end communication securely on any ne= twork, without requiring additional protections from outside. But I guess a few people would then argue that some hosts can't implement the same degree of security protection as  the degree e.g. tablets and PC can - and that guess led&n= bsp;to the current lanuage.

 

If you think it should be changed to some stronger statement, do you have something specific in mind?

 

-Dmitry

 

 

From: Cameron Byrne [cb.list6@gmail.com]
Sent: Tuesday, March 27, 2012 8:29 PM
To: Brian E Carpenter
Cc: Mark Townsley; Dmitry Anipko; homenet@ietf.org= Group
Subject: Re: [homenet] Security goals


On Mar 27, 2012 6:53 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com> wrote:
>
> On 2012-03-28 11:58, Dmitry Anipko wrote:
> > As someone who works for a host software vendor, I'd like to add couple of points. I agree with Mark that in general the security topic is wider than only filtering on the borders of the realms of the traffic destined to hosts, and I support the efforts to figure out the right set of knobs for the former. That said, for the latter, I'd like to see something along the below lines in the requirements
> > (some of which may already be in the text in some form, putting it here just for fluency of this piece of the story).
> >
> > 1. Homenet hosts MUST implement their own security policies in accordance to their computing capabilities.
>
> I think we know from some famous cases that SCADA systems are highly
> insecure, mainly due to following this principle (translated as
> "security is too hard and this device will always be on a private
> network anyway"). I'm a bit nervous that this policy will encourage
> low-end device designers to classify their devices as not having
> enough resource to deal with security.
>

This category should / will be eliminated by market forces, too much liability associated with being willfully insecure.  There are famous cases for this too.

If internet segmentation is all that is required, there are address types that facilitate local only access.

Cb
>    Brian
> _______________________________________________
> homenet mailing list
> homene= t@ietf.org
> https://www.ietf.org/mailman/listinfo/h= omenet



_______________________________________________
homenet mailing list
ho=
menet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
--------------000705030306010003050502-- --------------ms090709060904040705010105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMyODExMjA1MVowIwYJKoZI hvcNAQkEMRYEFGaI6aEfZYiWtq1XrOM2u9yr39V0MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQB0gcvI4SoDUYTFfVRfpBjE qpzpC0UzQlpnnhCf/nVgsubnvEBGgE2OxomNS/LqI09nOiV4HbdEMZvYWIB1vnkquSzk/y+W OBsjYYa1ETyl0eGEFtrnHQmnwfapPy2O9HulF2QX6PVcJYBPpMJnr54laOJkJFleyi2CeoDL +/5Q4kdsLaCFlDcTFfoiMToGew/nANhTHKVb/83xeW9Xsy0MW0O+D6fJlFJE7xuFK50tyziq FdkMZqoi2vj0rsDP0phM9eEzPEjLSK3wu16vtk6CX/gA8h1P8/7lL0YbKQ39wKgbvEdHrLxS 9US4nqzRQ+jKR14zGVNsCqQCF/zW69/dAAAAAAAA --------------ms090709060904040705010105-- From mcr@sandelman.ca Wed Mar 28 05:01:18 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACBE21E8109 for ; Wed, 28 Mar 2012 05:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6] 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 u92pvEQKnbyZ for ; Wed, 28 Mar 2012 05:01:18 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2676421E815D for ; Wed, 28 Mar 2012 05:01:18 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 2EAF4344CD for ; Wed, 28 Mar 2012 07:58:34 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 7211C98AAE; Wed, 28 Mar 2012 14:01:16 +0200 (CEST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 642CB98281 for ; Wed, 28 Mar 2012 14:01:16 +0200 (CEST) From: Michael Richardson To: homenet@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 28 Mar 2012 14:01:16 +0200 Message-ID: <28142.1332936076@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] one IAB quotation on walled gardens X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 12:01:19 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Erik" =3D=3D Erik Kline writes: Erik> Mark, Erik> For the record, the walled garden citation I quoted was from: Erik> http://tools.ietf.org/html/rfc3002#section-4.2 yes, I found it during the meeting. I think you are taking it out of context of: - the time before 2000=20 - when "wireless carriers" were not running IP at all, but providing access to email/etc. via application layer gateways!!!! and it was a summary of an IAB workshop, not an IAB recommendation. I much prefer to engineer for walled gardens using globally unique addresses GUA (not globally reachable) ("GUAnGR"?), than for NAT66. I also want to point out that the experience with IPv4 "walled gardens" usually involves either operators squatting on "unallocated" address spaces, or enterprises running non-unique RFC1918 networks with VPNs/Remote-Access. None of these things are going away. The example of "Joe's web cam", and whether we should use: - ULA/GUA in DNS with views (what about caches and DNSSEC?) or - ULA+GUA in DNS (multiple AAAA) plus Happy Eyeballs is pertinent. Because the ULA is a walled garden. And if it's really "Joes' office webcam via VPN", then the Enterprise is a walled garden. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3L9jIqHRg3pndX9AQJ3+AQAsvOSbc1z4gtoTPOfR8rI5YskM9sNoHhq nGFOGqfmayF2+/wIpl7VJbIXJ0Efwp0XukvOmoMvEAw3y7uJn5fXbqpsx6gnhl8a ix0hRHhWnF8sR5rjPU4md2aVlhFlt4axW7PMoCTZG1sujXTOiAwR8r2Glmf823ro JkLC6J392Xg= =ltfh -----END PGP SIGNATURE----- --=-=-=-- From brian.e.carpenter@gmail.com Wed Mar 28 12:38:51 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F5521E817E for ; Wed, 28 Mar 2012 12:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 pd-UhSI9eqvZ for ; Wed, 28 Mar 2012 12:38:51 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 536C021E816D for ; Wed, 28 Mar 2012 12:38:51 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1135222ggm.31 for ; Wed, 28 Mar 2012 12:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uuaaU+aR6LAhwkrxCf1npQ2ICkf/2x/dOui0+CA960o=; b=KEnMLRiyB6pzXjqYqKPDpR7WRW/42TRJ+o1X/+1NkaOJSSnLT3qcyWdi0OENaqDJtP 0izfg24b2FLTJtPxB90uswVpzwgDWkT3bq1fFwVKeAkpG4sogJAJ1Nr4jZ3goXSR1fNq T1oZc5F96+dAbkZ1HBYHrIsazbY7X5eo2U0OeQ2/skePkmuQjEJEgJSvE9KQAYYzTmNy VOqOP9UpONetOvZ0mCgArWfLY1beYvapJ/9q4la7yIJiCTgk6xvMe7fLVB/gW2wpHEnm DZ7yS1BdIjytO73F8Xy+tT+CgAgxHtzYoJL5/73227auwi0AyDOKkX/4ZtJaSxjySE6N hyQg== Received: by 10.68.229.169 with SMTP id sr9mr74075882pbc.164.1332963530562; Wed, 28 Mar 2012 12:38:50 -0700 (PDT) Received: from [192.168.182.22] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id p9sm3299920pbb.9.2012.03.28.12.38.48 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 12:38:50 -0700 (PDT) Message-ID: <4F7368C2.1020004@gmail.com> Date: Thu, 29 Mar 2012 08:38:42 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <28142.1332936076@marajade.sandelman.ca> In-Reply-To: <28142.1332936076@marajade.sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] one IAB quotation on walled gardens X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:38:52 -0000 On 2012-03-29 01:01, Michael Richardson wrote: >>>>>> "Erik" == Erik Kline writes: > Erik> Mark, > > Erik> For the record, the walled garden citation I quoted was from: > > Erik> http://tools.ietf.org/html/rfc3002#section-4.2 > > yes, I found it during the meeting. > I think you are taking it out of context of: > - the time before 2000 > - when "wireless carriers" were not running IP at all, but providing > access to email/etc. via application layer gateways!!!! Certainly we were worried about WAP at the time, but the language was careflly written to be more generic than that (I had something to do with drafting it). > > and it was a summary of an IAB workshop, not an IAB recommendation. At that time we were less strict about the formality or otherwise of IAB documents, but iirc there was pretty strong consensus behind the "musts" in the text Erik quoted. > > I much prefer to engineer for walled gardens using globally unique > addresses GUA (not globally reachable) ("GUAnGR"?), than for NAT66. > > I also want to point out that the experience with IPv4 "walled gardens" > usually involves either operators squatting on "unallocated" address > spaces, or enterprises running non-unique RFC1918 networks with > VPNs/Remote-Access. None of these things are going away. > > The example of "Joe's web cam", and whether we should use: > - ULA/GUA in DNS with views (what about caches and DNSSEC?) > or - ULA+GUA in DNS (multiple AAAA) plus Happy Eyeballs > > is pertinent. Because the ULA is a walled garden. And if it's really > "Joes' office webcam via VPN", then the Enterprise is a walled garden. But neither of those are "captive customers" in the sense that WAP threatened or that some carriers still seem to be hoping for. Brian From brian.e.carpenter@gmail.com Wed Mar 28 12:42:34 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C7521E812A for ; Wed, 28 Mar 2012 12:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 dQHDbkyqNodv for ; Wed, 28 Mar 2012 12:42:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1F3621E810B for ; Wed, 28 Mar 2012 12:42:32 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2279437pbb.31 for ; Wed, 28 Mar 2012 12:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kZVGGWm5naYiaQw2dDoPMm+2SOq3cVPL2H3CCugJh2A=; b=JYkKIwQgaqDKsIlpTRtile0C9fS3F63Ogqso4tsJ618/SiJyJvVZLGmcgLZ1owTR7F SlHFOt0vbn8gVQCUjLeI2Es2XLwPyFr80oAvyWHOXoFvUhlQagbvoE0D3tD6a49Jg3S0 rnNhIjAgTZ1x972RhpK7eTLyp85rqGtalmey2MVfB0x7aflFC3SwXNzFhB2tF753aDF1 lOyZALFSMqr+5Ltbo9vRhgsZ+VLzHgnrrtmJu4L5A/WGkZOk9A24nChlzIeh3P9RgRQz mXwdaBHAF8QLwjvbo0IWz65ttkRSHvyrQ5smSSo6/+aZy9Yjd9lBOCnGIOQhkrGYNF+q T9gA== Received: by 10.68.219.66 with SMTP id pm2mr9162595pbc.162.1332963752612; Wed, 28 Mar 2012 12:42:32 -0700 (PDT) Received: from [192.168.182.22] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id v6sm3289935pbu.41.2012.03.28.12.42.30 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 12:42:31 -0700 (PDT) Message-ID: <4F7369A1.60301@gmail.com> Date: Thu, 29 Mar 2012 08:42:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F60F458.4080403@gmail.com> <03FE6A726D13284495EF1787D25F1DF91F8C84D6@tk5ex14mbxc246.redmond.corp.microsoft.com> <4F726EFE.5010205@gmail.com>, <03FE6A726D13284495EF1787D25F1DF91F8C8974@tk5ex14mbxc246.redmond.corp.microsoft.com> <4F72F413.2040507@gridmerge.com> In-Reply-To: <4F72F413.2040507@gridmerge.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:42:34 -0000 Maybe we should add a statement that device designers must assume that DDoS and other forms of malicious traffic are present on the homenet, as well as a statement that all traffic may be visible to unknown third parties. A sort of generic threat model for homenets. Regards Brian On 2012-03-29 00:20, Robert Cragie wrote: > I think there are two orthogonal aspects here. There is one regarding > the ability for host to perform end to end communication securely (i.e > with integrity and/or confidentiality). This goes without saying and I > agree there needs to be a strong statement regarding this. However this > is orthogonal to a host's ability to handle all manner of traffic which > could be directed to it, especially malicious traffic. Ideally hosts > would be able to handle this and the recommendation would still be to > require hosts to firewall their own data. When a host is implemented on > a platform with plenty of storage and processing power, this is not > really an issue. However, in the LLN case, hosts may be running on > platforms which have very little storage and processing power by > comparison with limited ability to firewall. I do not think we should be > precluding these type of devices. > > Robert > > On 28/03/2012 6:47 AM, Dmitry Anipko wrote: >> >> Brian, >> >> I personally would definitely want to see a stronger statement that >> hosts should be implementing means sufficient to perform end 2 end >> communication securely on any network, without requiring additional >> protections from outside. But I guess a few people would then argue >> that some hosts can't implement the same degree of security protection >> as the degree e.g. tablets and PC can - and that guess led to the >> current lanuage. >> >> If you think it should be changed to some stronger statement, do you >> have something specific in mind? >> >> -Dmitry >> >> ------------------------------------------------------------------------ >> *From:* Cameron Byrne [cb.list6@gmail.com] >> *Sent:* Tuesday, March 27, 2012 8:29 PM >> *To:* Brian E Carpenter >> *Cc:* Mark Townsley; Dmitry Anipko; homenet@ietf.org Group >> *Subject:* Re: [homenet] Security goals >> >> >> On Mar 27, 2012 6:53 PM, "Brian E Carpenter" >> > wrote: >> > >> > On 2012-03-28 11:58, Dmitry Anipko wrote: >> > > As someone who works for a host software vendor, I'd like to add >> couple of points. I agree with Mark that in general the security topic >> is wider than only filtering on the borders of the realms of the >> traffic destined to hosts, and I support the efforts to figure out the >> right set of knobs for the former. That said, for the latter, I'd like >> to see something along the below lines in the requirements >> > > (some of which may already be in the text in some form, putting it >> here just for fluency of this piece of the story). >> > > >> > > 1. Homenet hosts MUST implement their own security policies in >> accordance to their computing capabilities. >> > >> > I think we know from some famous cases that SCADA systems are highly >> > insecure, mainly due to following this principle (translated as >> > "security is too hard and this device will always be on a private >> > network anyway"). I'm a bit nervous that this policy will encourage >> > low-end device designers to classify their devices as not having >> > enough resource to deal with security. >> > >> >> This category should / will be eliminated by market forces, too much >> liability associated with being willfully insecure. There are famous >> cases for this too. >> >> If internet segmentation is all that is required, there are address >> types that facilitate local only access. >> >> Cb >> > Brian >> > _______________________________________________ >> > homenet mailing list >> > homenet@ietf.org >> > https://www.ietf.org/mailman/listinfo/homenet >> >> >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > > ------------------------------------------------------------------------ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From brian.e.carpenter@gmail.com Wed Mar 28 12:44:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D0821E823B for ; Wed, 28 Mar 2012 12:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.072 X-Spam-Level: X-Spam-Status: No, score=-103.072 tagged_above=-999 required=5 tests=[AWL=-0.473, BAYES_00=-2.599, J_BACKHAIR_36=1, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 K2ywJ5kKt-4p for ; Wed, 28 Mar 2012 12:44:35 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B81E521E8089 for ; Wed, 28 Mar 2012 12:44:35 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2281766pbb.31 for ; Wed, 28 Mar 2012 12:44:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EgQxsSyUmqq+bNbmrEaBP2bOxfu6/6nvBqipOa7ms5c=; b=a9OR5JHO6Zb8kBPqz5pKG74FR3AtyJ+Rj567C1HFHWZ+q1c/l2voB6NX5hZO8EkJlJ u/BBtWEzwQ22HVnNSGyV3mmUgPxi880mZn6WMPPT5JSmzB4TkAyXkgZwc9ds5dlmhvbS 5V0w+vYvNAY6AYoZuX3B79ZjFSFy297ZnKVq1WSggmYQWibxSftgs/EHaBHbzMwWGEjV cXOZtzj3FeGfjJuRMM47klkZXA5XVYz03rnwl+SRk3kntv1xh5UjuoDEsITwNOOaicLo FmCw+dpkSdDriTEjxqtqEc8FZQ4Rbux3RgOAP/swfcIqcfq5Qk6+TPOxvmv9ET4p8GSi qFFA== Received: by 10.68.226.225 with SMTP id rv1mr52139879pbc.149.1332963875517; Wed, 28 Mar 2012 12:44:35 -0700 (PDT) Received: from [192.168.182.22] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id z7sm3282778pbk.63.2012.03.28.12.44.30 (version=SSLv3 cipher=OTHER); Wed, 28 Mar 2012 12:44:34 -0700 (PDT) Message-ID: <4F736A19.7010009@gmail.com> Date: Thu, 29 Mar 2012 08:44:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Cameron Byrne References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6BAC9F.10903@gmail.com> <4F7272E3.60403@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet issue tracker , homenet@ietf.org, Dave Taht , tjc@ecs.soton.ac.uk, draft-ietf-homenet-arch@tools.ietf.org Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 19:44:36 -0000 On 2012-03-28 16:34, Cameron Byrne wrote: > On Mar 27, 2012 7:09 PM, "Brian E Carpenter" > wrote: >> Dave, >> >> On 2012-03-28 09:28, Dave Taht wrote: >>> On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter < >>> brian.e.carpenter@gmail.com> wrote: >>> >>>> On 2012-03-22 12:33, homenet issue tracker wrote: >>>>> #4: Use of ULAs >>>>> >>>>> CN1 in the -02 text says ULAs should be provisioned by default. Do > we >>>>> agree? >>>> Yes, by the CER (MUST). >>>> >>>> It's much less clear for all other routers on site. I would prefer that >>>> no other router provisions a ULA prefix if the CER has already > delegated >>>> one. >>>> >>> Since it is nearly impossible to learn a subnet prefix that is unused >>> unless all devices share a routing protocol, I have generally preferred > to >>> generate unique ULAs per routing device. >> Our two statements are not inconsistent... obviously, if a router comes >> up and does not hear about a ULA prefix from another router, it may be >> appropriate to generate a new one. But if we have a prefix delegation >> mechanism in place, that may be sufficient. >> >>> >>>>> And if so, should they be preferred over globals? >>>> Yes. >>>> >>>> >>> This part I don't quite understand. I would prefer global prefixes to >>> always take precedence over ULAs. >>> I'd like ULAs to try to talk only to ULAs. ULAs should not escape into > the >>> global DNS, but should end up in local dns. >> ULAs should really only be used to talk to ULAs, so when I say 'prefer > ULAs', >> I mean prefer a pair of ULAs to a pair of globals. In case it isn't clear, >> in my mind the problem is always address *pair* selection. So that means >> that a host should do something like this in the default case: >> >> Do I have a ULA? >> If yes, does the other guy have a ULA (in the same prefix)? >> If yes, use the two ULAs. >> Else, use two globals. >> >> I'm hoping 3484bis will result in this. >> > > In the general case, you don't believe ula and global should have > communication at all? Or just a matter of source selection when multiple > address types are available to a given host ? The second. If the only choice is ULA<->global, of course you try it, but then happy-eyeballs may kick in. Brian > > Cb > >>> Even with 'happy eyeballs', having a means to disable a ULA -> global >>> connection by default saves 100s of ms in the bad cases. >> Agreed. >> >> Brian >> >>>>> The new >>>>> 3484-bis has changed so they are not *unless* a specific /48 for the >>>> site >>>>> is added to the 3484 policy table with higher precedence than > globals. >>>> We >>>>> should design something that works when disconnected from the > Internet. >>>> We'll have to deal with whatever 3484bis ends up saying. If it does >>>> require an explicit policy table entry table, that will require >>>> a mechanism, associated with the prefix delegation mechanism. >>>> >>> OK, I will re-read, thx for the update.. >>> >>> >>>>> Also, we currently say nothing about ULA-only devices and their >>>>> reachability from outside the homenet; do we want to? >>>> I don't see what there is to say; they aren't reachable, and that's >>>> a feature. >>>> >>>> Brian >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>>> >>> >>> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > From mcr@sandelman.ca Thu Mar 29 01:19:38 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6A521F89F2 for ; Thu, 29 Mar 2012 01:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 6A84pb09zZ-l for ; Thu, 29 Mar 2012 01:19:37 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0791221F89EF for ; Thu, 29 Mar 2012 01:19:37 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [38.102.80.246]) by relay.sandelman.ca (Postfix) with ESMTPS id E39C534508 for ; Thu, 29 Mar 2012 04:16:48 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id AB9F898AAE; Thu, 29 Mar 2012 10:19:10 +0200 (CEST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id A5A2798AA9 for ; Thu, 29 Mar 2012 10:19:10 +0200 (CEST) From: Michael Richardson To: "homenet@ietf.org" In-Reply-To: <4F72C141.6000202@globis.net> References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6BAC9F.10903@gmail.com> <4F72C141.6000202@globis.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 29 Mar 2012 10:19:10 +0200 Message-ID: <28522.1333009150@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] #4: Use of ULAs X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:19:39 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ray" =3D=3D Ray Hunter writes: Ray> Generating a ULA independently per router is potentially going Ray> to bring problems with the new RFC3484-revise as they'll almost Ray> certainly have different Global ID's (and thus a different /48 Ray> prefix), so ULA will not be preferred for communication between Ray> nodes connected to different routers. Ray> Sometimes it's useful to take a complete opposite view to the Ray> way you've been thinking, and work though the consequences. Perhaps rfc3484bis needs to say that any ULA is good to speak to any other ULA, regardless of longest prefix match.=20=20 This puts a constraint on homenet topology that all ULAs have to be reachable from all other ULAs. Perhaps that is in the end, acceptable. Ray> What about going to the extreme and giving up on Ray> central/coordinated control of a single ULA /48 Global ID Ray> throughout the Homenet? Ray> What about tolerating static prefix assignments (for sensor Ray> networks)? We allow static individual IPv6 address assignments Ray> to end nodes as well as SLAAC, so why not tolerate statically Ray> assigned /64 prefixes? Even in Appletalk, the much vaunted Ray> champion of autoconfiguration, a network manager had to Ray> manually assign the network number range to at least one seed Ray> router in an extended network. Ray> - multiple ULA /48 Global ID's within a single Homenet is not Ray> considered an "error" Yes. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3Qa/oqHRg3pndX9AQI6lgP/WuhHrQVSvAY+ag5ewp/KboEiz9okI33E rLnarXl9AsetnkUg9gLfC5Hd13x7FhY4PrKVATX0AD1UxcSNi4cAyBlg9irBhQP+ tvXzyYQj3oD5ojDK1kSuJoremAPbNOpJO7SUUw2n4np87jMML9AVBYQ+k/krpvbG K5vtn7AotrY= =2Tfk -----END PGP SIGNATURE----- --=-=-=-- From daveoran@orandom.net Thu Mar 29 03:17:12 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828E421F8491 for ; Thu, 29 Mar 2012 03:17:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6jNM2e4dM+w for ; Thu, 29 Mar 2012 03:17:11 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2001:470:d:21b:3c00::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7F421F848E for ; Thu, 29 Mar 2012 03:17:11 -0700 (PDT) Received: from sjc-vpnasa-652.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by spark.crystalorb.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id q2TAHCrB022331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2012 03:17:14 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David R Oran In-Reply-To: <4F722D74.9010909@piuha.net> Date: Thu, 29 Mar 2012 12:17:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <061.66eb0dbed3a33f6365b2a21998665ed1@trac.tools.ietf.org> <4F6B2DF7.30500@globis.net> <4F721CB4.6000501@piuha.net> <4F722D74.9010909@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1257) Cc: homenet@ietf.org Subject: Re: [homenet] home networking of a different kind X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:17:12 -0000 On Mar 27, 2012, at 11:13 PM, Jari Arkko wrote: > Not sure if this is on or off-topic for this working group but here's = a recent extension to my home network setup: >=20 > http://thingsonip.blogspot.fr/2012/03/smart-igloos.html >=20 I assume you need special protocols to get through - does that mean we = need to add ICE to the homenet suite? :-) > Jari >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mcr@sandelman.ca Thu Mar 29 04:48:34 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35B821F878A for ; Thu, 29 Mar 2012 04:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6] 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 XbdwhQ3PTxfL for ; Thu, 29 Mar 2012 04:48:33 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B9D7A21F87AB for ; Thu, 29 Mar 2012 04:48:33 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 0908634359 for ; Thu, 29 Mar 2012 07:45:44 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id DFE6D98AAE; Thu, 29 Mar 2012 13:48:05 +0200 (CEST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id D579C9817F for ; Thu, 29 Mar 2012 13:48:05 +0200 (CEST) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <4F7368C2.1020004@gmail.com> References: <28142.1332936076@marajade.sandelman.ca> <4F7368C2.1020004@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 29 Mar 2012 13:48:05 +0200 Message-ID: <13637.1333021685@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] one IAB quotation on walled gardens X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:48:35 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian E Carpenter writes: >> I much prefer to engineer for walled gardens using globally >> unique addresses GUA (not globally reachable) ("GUAnGR"?), than >> for NAT66. >>=20 >> I also want to point out that the experience with IPv4 "walled >> gardens" usually involves either operators squatting on >> "unallocated" address spaces, or enterprises running non-unique >> RFC1918 networks with VPNs/Remote-Access. None of these things >> are going away. >>=20 >> The example of "Joe's web cam", and whether we should use: - >> ULA/GUA in DNS with views (what about caches and DNSSEC?) or - >> ULA+GUA in DNS (multiple AAAA) plus Happy Eyeballs >>=20 >> is pertinent. Because the ULA is a walled garden. And if it's >> really "Joes' office webcam via VPN", then the Enterprise is a >> walled garden. Brian> But neither of those are "captive customers" in the sense Brian> that WAP threatened or that some carriers still seem to be Brian> hoping for. So, is the term "walled garden" inappropriate then, and we are arguing about nothing? We aren't talking about captive customers. The specific *technical* requirement is actually: You can't *there* if you start with that source IP. or: If you want to go *there*, you must start from *here* or: Ingress filtering rules (with allusions to: http://c2.com/cgi/wiki?WouldntStartFromHere ) =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 =20=20=20=20=20=20=20=20=20=20=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3RL9YqHRg3pndX9AQIGlQP8D834tm+/ufiC3kgBnNu0gfapmkyXlioL sWKxsS2nsrDR0s+LgjU98jClJLBMpx0LoGe7U92ztpP6QKLfijWoSv43Bl09q8s9 ebXlZ18aTqafyuUurHSaq+Q9AY1Xor9iuGGHuMAahsvUeiTsHcI0iNSDfxIyfTcJ YTWa0O9iTmg= =b+Vs -----END PGP SIGNATURE----- --=-=-=-- From jhaas@slice.pfrc.org Thu Mar 29 07:31:55 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E3021E803C for ; Thu, 29 Mar 2012 07:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 27-Q4E1xsnWR for ; Thu, 29 Mar 2012 07:31:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 757B721E81BE for ; Thu, 29 Mar 2012 07:31:54 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3EC9F170428; Thu, 29 Mar 2012 10:31:54 -0400 (EDT) Date: Thu, 29 Mar 2012 10:31:54 -0400 From: Jeffrey Haas To: homenet@ietf.org Message-ID: <20120329143154.GF18393@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [homenet] Host service provider considerations in a multihomed network X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:31:55 -0000 [I'm subscribed to the list but far behind. This was prompted by a question to Acee at the mic at rtgwg.] Let's say my Mother has two internet providers, A and B. The reason may be because she needs provider A for home work, but it's a somewhat filtered network (she can't get to her facebook!) and has B as her personal provider. What sort of interface are we expecting to give her to route her main desktop to work resources vs. personal stuff? Acee had suggested that source routing may be preferred. In the above example, that won't help her. She would effectively be required to have two machines. Instead of source routing, I can also see standard routing being done. Presume 192.0.2/24 is where the work-related resources are. A static route configured on the gateway for A and advertised into the routing protocol would be sufficient to sink work traffic to the right router. Alternatively, DNS sniffing with a configured filter on gateway A may be enough. She has example.com configured on A as a network that should be preferred (maybe exclusively) on A. When the AAAA record is returned for something in example.com, it may be installed in routing to prefer A. Note that I don't have any specific solution in mind. Routing may work, simple source routing probably won't. Full policy routing on the tuple may work. Routing solutions under consderation may not be fast enough for dynamic host routes, etc. -- Jeff From mcr@sandelman.ca Thu Mar 29 10:41:41 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2D721F8755 for ; Thu, 29 Mar 2012 10:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 PXSKHzlJi9R4 for ; Thu, 29 Mar 2012 10:41:41 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 342B521F8753 for ; Thu, 29 Mar 2012 10:41:41 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-10ed.meeting.ietf.org [130.129.16.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 6BA35344E1; Thu, 29 Mar 2012 13:38:55 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 8CFE398AAE; Thu, 29 Mar 2012 19:41:17 +0200 (CEST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 85C7E9817F; Thu, 29 Mar 2012 19:41:17 +0200 (CEST) From: Michael Richardson To: Jeffrey Haas In-Reply-To: <20120329143154.GF18393@slice> References: <20120329143154.GF18393@slice> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 29 Mar 2012 19:41:17 +0200 Message-ID: <4264.1333042877@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: homenet@ietf.org Subject: Re: [homenet] Host service provider considerations in a multihomed network X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:41:42 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Jeffrey" =3D=3D Jeffrey Haas writes: Jeffrey> [I'm subscribed to the list but far behind. This was Jeffrey> prompted by a question to Acee at the mic at rtgwg.] Jeffrey> Let's say my Mother has two internet providers, A and B. Jeffrey> The reason may be because she needs provider A for home Jeffrey> work, but it's a somewhat filtered network (she can't get Jeffrey> to her facebook!) and has B as her personal provider. A good example, particularly if "A" is really a virtual wire. But, my question is: on provider A, will she have full access, or only access to work? Jeffrey> Instead of source routing, I can also see standard routing Jeffrey> being done. Presume 192.0.2/24 is where the work-related Jeffrey> resources are. A static route configured on the gateway Jeffrey> for A and advertised into the routing protocol would be Jeffrey> sufficient to sink work traffic to the right router. so, this is what we have been calling a walled-garden, but perhaps that term is too confusing due to WAP-type usage a decade ago, and we need another term. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3SevYqHRg3pndX9AQLHXQQAq31Xddb/RENY+4T53p7GR0SHMZPH9SvE 9X8TDzlERWor3HHGNRqY5e+FExmbRhvQ091EmjgjL3n65YgCfayWMS7t4VL1tzq7 rvu5U99iZJmue95wJpAl5gcYGzG9PJzbNbjf0pNRM+iv/0AB9+3PSTTCiTAaPJLS TAyTh2sltrY= =47MA -----END PGP SIGNATURE----- --=-=-=-- From brian.e.carpenter@gmail.com Thu Mar 29 12:19:05 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7009321F87A8 for ; Thu, 29 Mar 2012 12:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.232 X-Spam-Level: X-Spam-Status: No, score=-103.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 i4GGaM9nLPGB for ; Thu, 29 Mar 2012 12:19:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5168521F87AA for ; Thu, 29 Mar 2012 12:19:04 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1933889yhk.31 for ; Thu, 29 Mar 2012 12:19:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wF3tphw9j3RxTQDvRcb/lPR6aIEjC1THjgwOZB5PTPE=; b=Vc0oziRQbdZsuzpkeJF8kXAOisJiKG7Xc8ctpp9k57JDkzShm77UycIhaVRT9D+ACL IPiZYaZAB+m+/+wTGH2zqtZCG5pJsgkDFTC27SYbVpusL6kKKswDkf/HbgsXUk3qa6EU Cg4NcGNXysY0k/bJUjXhfG2iHaxLYT4ehC8O4Okz0XhtpDzyYGV7Mq1pHyRVIsEWzCqe quSB5HdSD/OMXUtYbh0bnmucuvEHh46upui2GHYDapeRi8SZjUnDU/C2Ao3GQhbrWfTg Vm+X0xMdgTgjpD7Akx7Yht4sdTrWgi+U2zmIsblt3PPw/KGpFOJBqHMltSZ2Z2kn8bvU Fxdw== Received: by 10.68.136.41 with SMTP id px9mr2591989pbb.147.1333048743233; Thu, 29 Mar 2012 12:19:03 -0700 (PDT) Received: from [192.168.182.25] (122-57-150-118.jetstream.xtra.co.nz. [122.57.150.118]) by mx.google.com with ESMTPS id w6sm5579050pbf.66.2012.03.29.12.19.00 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 12:19:02 -0700 (PDT) Message-ID: <4F74B5A2.9050301@gmail.com> Date: Fri, 30 Mar 2012 08:18:58 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <28142.1332936076@marajade.sandelman.ca> <4F7368C2.1020004@gmail.com> <13637.1333021685@marajade.sandelman.ca> In-Reply-To: <13637.1333021685@marajade.sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] one IAB quotation on walled gardens X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 19:19:05 -0000 Front posting: I think we are using "walled garden" to mean several things and that is confusing. In my mind it refers to a captive customer scenario where a service provider is intentionally limiting a customer's access to the global Internet or (by playing DNS and/or HTTP proxy tricks) presenting a distorted view of the the global Internet. This becomes especially obnoxious if the customer has multiple providers that attempt to enforce different walled gardens. But that's a MIF issue, I think. That is quite different from stating that a customer network should be separated from the Internet by a security fence of some kind and may also need a local namespace. I thought that was normally called an intranet. Regards Brian Carpenter On 2012-03-30 00:48, Michael Richardson wrote: >>>>>> "Brian" == Brian E Carpenter writes: > >> I much prefer to engineer for walled gardens using globally > >> unique addresses GUA (not globally reachable) ("GUAnGR"?), than > >> for NAT66. > >> > >> I also want to point out that the experience with IPv4 "walled > >> gardens" usually involves either operators squatting on > >> "unallocated" address spaces, or enterprises running non-unique > >> RFC1918 networks with VPNs/Remote-Access. None of these things > >> are going away. > >> > >> The example of "Joe's web cam", and whether we should use: - > >> ULA/GUA in DNS with views (what about caches and DNSSEC?) or - > >> ULA+GUA in DNS (multiple AAAA) plus Happy Eyeballs > >> > >> is pertinent. Because the ULA is a walled garden. And if it's > >> really "Joes' office webcam via VPN", then the Enterprise is a > >> walled garden. > > Brian> But neither of those are "captive customers" in the sense > Brian> that WAP threatened or that some carriers still seem to be > Brian> hoping for. > > So, is the term "walled garden" inappropriate then, and we are arguing > about nothing? > > We aren't talking about captive customers. The specific *technical* > requirement is actually: > You can't *there* if you start with that source IP. > or: If you want to go *there*, you must start from *here* > or: Ingress filtering rules > > (with allusions to: http://c2.com/cgi/wiki?WouldntStartFromHere ) > > > > ------------------------------------------------------------------------ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From joelja@bogus.com Fri Mar 30 00:27:27 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2AC21F860B for ; Fri, 30 Mar 2012 00:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.262 X-Spam-Level: X-Spam-Status: No, score=-102.262 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] 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 Zj4VuEVYp8Tk for ; Fri, 30 Mar 2012 00:27:26 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id BC41221F8606 for ; Fri, 30 Mar 2012 00:27:26 -0700 (PDT) Received: from dhcp-5710.meeting.ietf.org (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2U7RMQ1025190 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 30 Mar 2012 07:27:24 GMT (envelope-from joelja@bogus.com) Message-ID: <4F756059.6040504@bogus.com> Date: Fri, 30 Mar 2012 09:27:21 +0200 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Brian E Carpenter References: <28142.1332936076@marajade.sandelman.ca> <4F7368C2.1020004@gmail.com> <13637.1333021685@marajade.sandelman.ca> <4F74B5A2.9050301@gmail.com> In-Reply-To: <4F74B5A2.9050301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 30 Mar 2012 07:27:25 +0000 (UTC) Cc: Michael Richardson , homenet@ietf.org Subject: Re: [homenet] one IAB quotation on walled gardens X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:27:27 -0000 On 3/29/12 21:18 , Brian E Carpenter wrote: > Front posting: I think we are using "walled garden" to mean several > things and that is confusing. > > In my mind it refers to a captive customer scenario where a service > provider is intentionally limiting a customer's access to the global > Internet or (by playing DNS and/or HTTP proxy tricks) presenting a > distorted view of the the global Internet. > > This becomes especially obnoxious if the customer has multiple > providers that attempt to enforce different walled gardens. But > that's a MIF issue, I think. > > That is quite different from stating that a customer network should > be separated from the Internet by a security fence of some kind and > may also need a local namespace. I thought that was normally called > an intranet. when you have two default routes, but the graph exposed by each has an overlapping but incomplete set of vertices you don't have enough information to to determine which one to select for a given destination. flipping a coin works fine (in general) for the overlapping set. > Regards > Brian Carpenter > > > > > On 2012-03-30 00:48, Michael Richardson wrote: >>>>>>> "Brian" == Brian E Carpenter writes: >> >> I much prefer to engineer for walled gardens using globally >> >> unique addresses GUA (not globally reachable) ("GUAnGR"?), than >> >> for NAT66. >> >> >> >> I also want to point out that the experience with IPv4 "walled >> >> gardens" usually involves either operators squatting on >> >> "unallocated" address spaces, or enterprises running non-unique >> >> RFC1918 networks with VPNs/Remote-Access. None of these things >> >> are going away. >> >> >> >> The example of "Joe's web cam", and whether we should use: - >> >> ULA/GUA in DNS with views (what about caches and DNSSEC?) or - >> >> ULA+GUA in DNS (multiple AAAA) plus Happy Eyeballs >> >> >> >> is pertinent. Because the ULA is a walled garden. And if it's >> >> really "Joes' office webcam via VPN", then the Enterprise is a >> >> walled garden. >> >> Brian> But neither of those are "captive customers" in the sense >> Brian> that WAP threatened or that some carriers still seem to be >> Brian> hoping for. >> >> So, is the term "walled garden" inappropriate then, and we are arguing >> about nothing? >> >> We aren't talking about captive customers. The specific *technical* >> requirement is actually: >> You can't *there* if you start with that source IP. >> or: If you want to go *there*, you must start from *here* >> or: Ingress filtering rules >> >> (with allusions to: http://c2.com/cgi/wiki?WouldntStartFromHere ) >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From mcr@sandelman.ca Fri Mar 30 00:35:32 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9983021F8789 for ; Fri, 30 Mar 2012 00:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 gW3F5lyTu0Cv for ; Fri, 30 Mar 2012 00:35:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 532B621F875C for ; Fri, 30 Mar 2012 00:35:31 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-50ed.meeting.ietf.org [130.129.80.237]) by relay.sandelman.ca (Postfix) with ESMTPS id 43334344CD for ; Fri, 30 Mar 2012 03:32:44 -0400 (EDT) Received: by marajade.sandelman.ca (Postfix, from userid 179) id A623298AAE; Fri, 30 Mar 2012 09:35:27 +0200 (CEST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id A1D1998281 for ; Fri, 30 Mar 2012 09:35:27 +0200 (CEST) From: Michael Richardson To: homenet@ietf.org In-Reply-To: <4F74B5A2.9050301@gmail.com> References: <28142.1332936076@marajade.sandelman.ca> <4F7368C2.1020004@gmail.com> <13637.1333021685@marajade.sandelman.ca> <4F74B5A2.9050301@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 30 Mar 2012 09:35:27 +0200 Message-ID: <16264.1333092927@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [homenet] one IAB quotation on walled gardens X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 07:35:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian E Carpenter writes: Brian> Front posting: I think we are using "walled garden" to mean Brian> several things and that is confusing. Brian> In my mind it refers to a captive customer scenario where a Brian> service provider is intentionally limiting a customer's Brian> access to the global Internet or (by playing DNS and/or HTTP Brian> proxy tricks) presenting a distorted view of the the global Brian> Internet. Brian> This becomes especially obnoxious if the customer has Brian> multiple providers that attempt to enforce different walled Brian> gardens. But that's a MIF issue, I think. Brian> That is quite different from stating that a customer network Brian> should be separated from the Internet by a security fence of Brian> some kind and may also need a local namespace. I thought that Brian> was normally called an intranet. I actually can't see a technical difference. Most intranets work by: 1) intentionally limiting a customer's access to the global Internet 2) playing DNS tricks 3) HTTP proxy tricks 4) having a local name space. I think that walled-gardens are the political NAT44 of IPv6. We can, if we want, stick our head in the sand like we did for NAT44, letting the marketplace produce create an arms race between network operators and application creators. Or, we can do like we finally did with BEHAVE and specify something. I'm here in homenet because I care about e2e, I want to avoid NAT66, and I see great utility in having globably unique addresses everywhere, even if they are not globally routable/accessible. (ps: I shipped NAT44 products in 1994. I hate myself for helping kill e2e. I shipped it with split-horizon DNS standard. It was all stupid. ) =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT3ViP4qHRg3pndX9AQL1SQP9HdP6JCO9Q7iCc8HJRMSe1/P3iZYMlAe2 KwL/c4GMlKcvJGwEUDQ7IRGZcn8B1aP8K4syPkBhRz7Lo5Y14B93xj43p35OaZJw hRnGT7uchBwsHyAwv3A7cSUYR/JS7iG8DmDvook685+QZb+WuH52G3CNXCrF5Q7P Mm9MN29fDgo= =wpgb -----END PGP SIGNATURE----- --=-=-=-- From robert.cragie@gridmerge.com Fri Mar 30 15:00:33 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8525C21F8627 for ; Fri, 30 Mar 2012 15:00:33 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] 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 7j4A-symEAtO for ; Fri, 30 Mar 2012 15:00:32 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3675721F8607 for ; Fri, 30 Mar 2012 15:00:32 -0700 (PDT) Received: from client-82-26-130-230.pete-bam-1.adsl.virginmedia.com ([82.26.130.230] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1SDjrx-00084i-4U for homenet@ietf.org; Fri, 30 Mar 2012 23:00:29 +0100 Message-ID: <4F762D63.5050007@gridmerge.com> Date: Fri, 30 Mar 2012 23:02:11 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <13119.1331487384@marajade.sandelman.ca> <4F5FE875.9040904@gmail.com> <4F60F458.4080403@gmail.com> <03FE6A726D13284495EF1787D25F1DF91F8C84D6@tk5ex14mbxc246.redmond.corp.microsoft.com> <4F726EFE.5010205@gmail.com>, <03FE6A726D13284495EF1787D25F1DF91F8C8974@tk5ex14mbxc246.redmond.corp.microsoft.com> <4F72F413.2040507@gridmerge.com> <4F7369A1.60301@gmail.com> In-Reply-To: <4F7369A1.60301@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070105050305080301070405" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 22:00:33 -0000 This is a cryptographically signed message in MIME format. --------------ms070105050305080301070405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I like the idea of developing a generic threat model for homenets. This=20 should frame what we are up against and make it clearer what the=20 appropriate countermeasures should be and where they are best placed. Robert On 28/03/2012 8:42 PM, Brian E Carpenter wrote: > Maybe we should add a statement that device designers must assume > that DDoS and other forms of malicious traffic are present on > the homenet, as well as a statement that all traffic may be visible > to unknown third parties. A sort of generic threat model for homenets. > > Regards > Brian > > On 2012-03-29 00:20, Robert Cragie wrote: >> I think there are two orthogonal aspects here. There is one regarding >> the ability for host to perform end to end communication securely (i.e= >> with integrity and/or confidentiality). This goes without saying and I= >> agree there needs to be a strong statement regarding this. However thi= s >> is orthogonal to a host's ability to handle all manner of traffic whic= h >> could be directed to it, especially malicious traffic. Ideally hosts >> would be able to handle this and the recommendation would still be to >> require hosts to firewall their own data. When a host is implemented o= n >> a platform with plenty of storage and processing power, this is not >> really an issue. However, in the LLN case, hosts may be running on >> platforms which have very little storage and processing power by >> comparison with limited ability to firewall. I do not think we should = be >> precluding these type of devices. >> >> Robert >> >> On 28/03/2012 6:47 AM, Dmitry Anipko wrote: >>> Brian, >>> >>> I personally would definitely want to see a stronger statement that >>> hosts should be implementing means sufficient to perform end 2 end >>> communication securely on any network, without requiring additional >>> protections from outside. But I guess a few people would then argue >>> that some hosts can't implement the same degree of security protectio= n >>> as the degree e.g. tablets and PC can - and that guess led to the >>> current lanuage. >>> >>> If you think it should be changed to some stronger statement, do you >>> have something specific in mind? >>> >>> -Dmitry >>> >>> ---------------------------------------------------------------------= --- >>> *From:* Cameron Byrne [cb.list6@gmail.com] >>> *Sent:* Tuesday, March 27, 2012 8:29 PM >>> *To:* Brian E Carpenter >>> *Cc:* Mark Townsley; Dmitry Anipko; homenet@ietf.org Group >>> *Subject:* Re: [homenet] Security goals >>> >>> >>> On Mar 27, 2012 6:53 PM, "Brian E Carpenter" >>> > wr= ote: >>>> On 2012-03-28 11:58, Dmitry Anipko wrote: >>>>> As someone who works for a host software vendor, I'd like to add >>> couple of points. I agree with Mark that in general the security topi= c >>> is wider than only filtering on the borders of the realms of the >>> traffic destined to hosts, and I support the efforts to figure out th= e >>> right set of knobs for the former. That said, for the latter, I'd lik= e >>> to see something along the below lines in the requirements >>>>> (some of which may already be in the text in some form, putting it >>> here just for fluency of this piece of the story). >>>>> 1. Homenet hosts MUST implement their own security policies in >>> accordance to their computing capabilities. >>>> I think we know from some famous cases that SCADA systems are highly= >>>> insecure, mainly due to following this principle (translated as >>>> "security is too hard and this device will always be on a private >>>> network anyway"). I'm a bit nervous that this policy will encourage >>>> low-end device designers to classify their devices as not having >>>> enough resource to deal with security. >>>> >>> This category should / will be eliminated by market forces, too much >>> liability associated with being willfully insecure. There are famous= >>> cases for this too. >>> >>> If internet segmentation is all that is required, there are address >>> types that facilitate local only access. >>> >>> Cb >>>> Brian >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>> >>> >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --------------ms070105050305080301070405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP3jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggYuMIIFFqAD AgECAhBcMVDbxC2oy5hyHl/adO9mMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwMjAwMDAwMFoXDTE0MDkwMTIzNTk1 OVowggE3MQswCQYDVQQGEwJHQjEQMA4GA1UEERMHV0Y0IDRXQTEXMBUGA1UECBMOV2VzdCBZ b3Jrc2hpcmUxEjAQBgNVBAcTCVdha2VmaWVsZDEUMBIGA1UECRMLR3JhbmdlIE1vb3IxHzAd BgNVBAkTFjg5IEdyZWVuZmllbGQgQ3Jlc2NlbnQxFzAVBgNVBAoTDkdyaWRtZXJnZSBMdGQu MTQwMgYDVQQLEytJc3N1ZWQgdGhyb3VnaCBHcmlkbWVyZ2UgTHRkLiBFLVBLSSBNYW5hZ2Vy MR8wHQYDVQQLExZDb3Jwb3JhdGUgU2VjdXJlIEVtYWlsMRYwFAYDVQQDEw1Sb2JlcnQgQ3Jh Z2llMSowKAYJKoZIhvcNAQkBFhtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCtxOGq8t5ZTVDVkmadv7ZRBLA5ApaiTcDUzCTn zYB2/BoBDIEWWI/InSRcmq3A0Ghm+T7dYmvRADllGv4nTHexdWlzFp2iM/Yc3PLWCyAO0gYb yW2hTi+ZfUDwFOU4hRP4+Dyn9tKu7FXS/PQJHyGjaGxHRmLm9T6tAo2ZuC59uRaGVCcwRiOS d6axwtB/DVhnP3S1rrt2g0O6MXLr5fojToemO52AxjHxt2w1LnFUUXC4EDV6o1Ctr7EvOEI5 5f088H/Mrryp02GueLdY9gb0SFK3gPOT7EjP2GPvCtRkhVcNM+xjyptRIFWnCbMjmUIc+DO6 sfU4rtbCCkNKyXmnAgMBAAGjggHVMIIB0TAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBb vHnFezAdBgNVHQ4EFgQUEI5c0f6UObxT2DLdvdtG+vG8qCswDgYDVR0PAQH/BAQDAgWgMAwG A1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQMFMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEB BHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50 QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMCYGA1UdEQQfMB2BG3JvYmVydC5jcmFnaWVAZ3JpZG1lcmdl LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAPpv87QuQ9q+RHhmeirGDQB3szd24Obi7N+uVfh5y CrnoJx3B37dNrLPsTB6PfTChUyZMqQD80pFoJ3TBUz3yx4X+hmNco7ujVIfbuKBGcZJaMKhZ ex3AkZ9ltie9wgiGGzEmgI81t5JHsLQ8AUMqw/fGsnIwcyWMgmyhFtm79+dg3IVaH05d/t9g k4aYoMoCFJptQZ+Fju6a9T139hOqjTZDpjMLt3jM80bVrvkC4dIRyF/oZ0qrJwbfwjnL2OUN ph9eymhLc+VM0Ih5k41s5IxmB+2c0RUqr5JbK0WrIb/z53Cmb9rXYox7HknyIfBpQqP77Y7a sAU2MMOpel4RijGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3Jl YXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0Eg TGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2Vj dXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMAkGBSsOAwIaBQCgggI4MBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDMzMDIyMDIxMVowIwYJKoZI hvcNAQkEMRYEFO71WV+gNnftlaUMQTkAUL6DkbYTMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9mMIG7BgsqhkiG 9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3 BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBD QQIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0BAQEFAASCAQAdWVPx8xRDbeKCQ+3Gv7X1 ve1GCi6r8u8MPt1y6Xr41eTKqT2egRoGZ32WI8DmQ1OHMKWST4Oz6r97xAy0vVcbhkTkXIjR b+CSEeF7EgV+aomUqgEy1F9+hRUCjs2aOXI+0562KZ1aP+poFJ5myZLx6fgG9NAFdmwzo9+j IiWTJ52OoScZaQ3J0AqgvTjGp1zwMVvCHWHKheNbzqAQr6ZKkO/HwU/TC07bGlCo88rm0fui +8S7Dx88oeCH3xiLZZ6MAbLUPqNn7x77fDNPjB+RnZrFfOHDU4f1OXIXZyNmNYkTbvMmcfMp /04LyAtv+46ibbiG7w9g8NlAEtF7Mz55AAAAAAAA --------------ms070105050305080301070405-- From rturner@amalfisystems.com Fri Mar 30 19:08:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBB921F85EF for ; Fri, 30 Mar 2012 19:08:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSnZ1SXzACF0 for ; Fri, 30 Mar 2012 19:08:03 -0700 (PDT) Received: from omr5.networksolutionsemail.com (omr5.networksolutionsemail.com [205.178.146.55]) by ietfa.amsl.com (Postfix) with ESMTP id E4F3F21F8603 for ; Fri, 30 Mar 2012 19:07:50 -0700 (PDT) Received: from cm-omr5 ([205.178.146.50]) by omr5.networksolutionsemail.com (8.13.6/8.13.6) with ESMTP id q2V27n3E008297 for ; Fri, 30 Mar 2012 22:07:49 -0400 Authentication-Results: cm-omr5 smtp.user=rturner@amalfisystems.com; auth=pass (LOGIN) X-Authenticated-UID: rturner@amalfisystems.com Received: from [166.250.66.86] ([166.250.66.86:11960] helo=[10.187.48.178]) by cm-omr5 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 1D/74-02022-4F6667F4; Fri, 30 Mar 2012 22:07:49 -0400 Date: Fri, 30 Mar 2012 19:07:46 -0700 Message-ID: From: Randy Turner To: homenet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: Re: [homenet] Security goals X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 02:08:05 -0000 KzEKCgpSb2JlcnQgQ3JhZ2llIDxyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20+IHdyb3RlOgoK PkkgbGlrZSB0aGUgaWRlYSBvZiBkZXZlbG9waW5nIGEgZ2VuZXJpYyB0aHJlYXQgbW9kZWwgZm9y IGhvbWVuZXRzLiBUaGlzIAo+c2hvdWxkIGZyYW1lIHdoYXQgd2UgYXJlIHVwIGFnYWluc3QgYW5k IG1ha2UgaXQgY2xlYXJlciB3aGF0IHRoZSAKPmFwcHJvcHJpYXRlIGNvdW50ZXJtZWFzdXJlcyBz aG91bGQgYmUgYW5kIHdoZXJlIHRoZXkgYXJlIGJlc3QgcGxhY2VkLgo+Cj5Sb2JlcnQKPgo+T24g MjgvMDMvMjAxMiA4OjQyIFBNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToKPj4gTWF5YmUgd2Ug c2hvdWxkIGFkZCBhIHN0YXRlbWVudCB0aGF0IGRldmljZSBkZXNpZ25lcnMgbXVzdCBhc3N1bWUK Pj4gdGhhdCBERG9TIGFuZCBvdGhlciBmb3JtcyBvZiBtYWxpY2lvdXMgdHJhZmZpYyBhcmUgcHJl c2VudCBvbgo+PiB0aGUgaG9tZW5ldCwgYXMgd2VsbCBhcyBhIHN0YXRlbWVudCB0aGF0IGFsbCB0 cmFmZmljIG1heSBiZSB2aXNpYmxlCj4+IHRvIHVua25vd24gdGhpcmQgcGFydGllcy4gQSBzb3J0 IG9mIGdlbmVyaWMgdGhyZWF0IG1vZGVsIGZvciBob21lbmV0cy4KPj4KPj4gUmVnYXJkcwo+PiAg ICAgQnJpYW4KPj4KPj4gT24gMjAxMi0wMy0yOSAwMDoyMCwgUm9iZXJ0IENyYWdpZSB3cm90ZToK Pj4+IEkgdGhpbmsgdGhlcmUgYXJlIHR3byBvcnRob2dvbmFsIGFzcGVjdHMgaGVyZS4gVGhlcmUg aXMgb25lIHJlZ2FyZGluZwo+Pj4gdGhlIGFiaWxpdHkgZm9yIGhvc3QgdG8gcGVyZm9ybSBlbmQg dG8gZW5kIGNvbW11bmljYXRpb24gc2VjdXJlbHkgKGkuZQo+Pj4gd2l0aCBpbnRlZ3JpdHkgYW5k L29yIGNvbmZpZGVudGlhbGl0eSkuIFRoaXMgZ29lcyB3aXRob3V0IHNheWluZyBhbmQgSQo+Pj4g YWdyZWUgdGhlcmUgbmVlZHMgdG8gYmUgYSBzdHJvbmcgc3RhdGVtZW50IHJlZ2FyZGluZyB0aGlz LiBIb3dldmVyIHRoaXMKPj4+IGlzIG9ydGhvZ29uYWwgdG8gYSBob3N0J3MgYWJpbGl0eSB0byBo YW5kbGUgYWxsIG1hbm5lciBvZiB0cmFmZmljIHdoaWNoCj4+PiBjb3VsZCBiZSBkaXJlY3RlZCB0 byBpdCwgZXNwZWNpYWxseSBtYWxpY2lvdXMgdHJhZmZpYy4gSWRlYWxseSBob3N0cwo+Pj4gd291 bGQgYmUgYWJsZSB0byBoYW5kbGUgdGhpcyBhbmQgdGhlIHJlY29tbWVuZGF0aW9uIHdvdWxkIHN0 aWxsIGJlIHRvCj4+PiByZXF1aXJlIGhvc3RzIHRvIGZpcmV3YWxsIHRoZWlyIG93biBkYXRhLiBX aGVuIGEgaG9zdCBpcyBpbXBsZW1lbnRlZCBvbgo+Pj4gYSBwbGF0Zm9ybSB3aXRoIHBsZW50eSBv ZiBzdG9yYWdlIGFuZCBwcm9jZXNzaW5nIHBvd2VyLCB0aGlzIGlzIG5vdAo+Pj4gcmVhbGx5IGFu IGlzc3VlLiBIb3dldmVyLCBpbiB0aGUgTExOIGNhc2UsIGhvc3RzIG1heSBiZSBydW5uaW5nIG9u Cj4+PiBwbGF0Zm9ybXMgd2hpY2ggaGF2ZSB2ZXJ5IGxpdHRsZSBzdG9yYWdlIGFuZCBwcm9jZXNz aW5nIHBvd2VyIGJ5Cj4+PiBjb21wYXJpc29uIHdpdGggbGltaXRlZCBhYmlsaXR5IHRvIGZpcmV3 YWxsLiBJIGRvIG5vdCB0aGluayB3ZSBzaG91bGQgYmUKPj4+IHByZWNsdWRpbmcgdGhlc2UgdHlw ZSBvZiBkZXZpY2VzLgo+Pj4KPj4+IFJvYmVydAo+Pj4KPj4+IE9uIDI4LzAzLzIwMTIgNjo0NyBB TSwgRG1pdHJ5IEFuaXBrbyB3cm90ZToKPj4+PiBCcmlhbiwKPj4+Pgo+Pj4+IEkgcGVyc29uYWxs eSB3b3VsZCBkZWZpbml0ZWx5IHdhbnQgdG8gc2VlIGEgc3Ryb25nZXIgc3RhdGVtZW50IHRoYXQK Pj4+PiBob3N0cyBzaG91bGQgYmUgaW1wbGVtZW50aW5nIG1lYW5zIHN1ZmZpY2llbnQgdG8gcGVy Zm9ybSBlbmQgMiBlbmQKPj4+PiBjb21tdW5pY2F0aW9uIHNlY3VyZWx5IG9uIGFueSBuZXR3b3Jr LCB3aXRob3V0IHJlcXVpcmluZyBhZGRpdGlvbmFsCj4+Pj4gcHJvdGVjdGlvbnMgZnJvbSBvdXRz aWRlLiBCdXQgSSBndWVzcyBhIGZldyBwZW9wbGUgd291bGQgdGhlbiBhcmd1ZQo+Pj4+IHRoYXQg c29tZSBob3N0cyBjYW4ndCBpbXBsZW1lbnQgdGhlIHNhbWUgZGVncmVlIG9mIHNlY3VyaXR5IHBy b3RlY3Rpb24KPj4+PiBhcyAgdGhlIGRlZ3JlZSBlLmcuIHRhYmxldHMgYW5kIFBDIGNhbiAtIGFu ZCB0aGF0IGd1ZXNzIGxlZCB0byB0aGUKPj4+PiBjdXJyZW50IGxhbnVhZ2UuCj4+Pj4KPj4+PiBJ ZiB5b3UgdGhpbmsgaXQgc2hvdWxkIGJlIGNoYW5nZWQgdG8gc29tZSBzdHJvbmdlciBzdGF0ZW1l bnQsIGRvIHlvdQo+Pj4+IGhhdmUgc29tZXRoaW5nIHNwZWNpZmljIGluIG1pbmQ/Cj4+Pj4KPj4+ PiAtRG1pdHJ5Cj4+Pj4KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+PiAqRnJvbToqIENhbWVyb24g QnlybmUgW2NiLmxpc3Q2QGdtYWlsLmNvbV0KPj4+PiAqU2VudDoqIFR1ZXNkYXksIE1hcmNoIDI3 LCAyMDEyIDg6MjkgUE0KPj4+PiAqVG86KiBCcmlhbiBFIENhcnBlbnRlcgo+Pj4+ICpDYzoqIE1h cmsgVG93bnNsZXk7IERtaXRyeSBBbmlwa287IGhvbWVuZXRAaWV0Zi5vcmcgR3JvdXAKPj4+PiAq U3ViamVjdDoqIFJlOiBbaG9tZW5ldF0gU2VjdXJpdHkgZ29hbHMKPj4+Pgo+Pj4+Cj4+Pj4gT24g TWFyIDI3LCAyMDEyIDY6NTMgUE0sICJCcmlhbiBFIENhcnBlbnRlciIKPj4+PiA8YnJpYW4uZS5j YXJwZW50ZXJAZ21haWwuY29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+PiAg d3JvdGU6Cj4+Pj4+IE9uIDIwMTItMDMtMjggMTE6NTgsIERtaXRyeSBBbmlwa28gd3JvdGU6Cj4+ Pj4+PiBBcyBzb21lb25lIHdobyB3b3JrcyBmb3IgYSBob3N0IHNvZnR3YXJlIHZlbmRvciwgSSdk IGxpa2UgdG8gYWRkCj4+Pj4gY291cGxlIG9mIHBvaW50cy4gSSBhZ3JlZSB3aXRoIE1hcmsgdGhh dCBpbiBnZW5lcmFsIHRoZSBzZWN1cml0eSB0b3BpYwo+Pj4+IGlzIHdpZGVyIHRoYW4gb25seSBm aWx0ZXJpbmcgb24gdGhlIGJvcmRlcnMgb2YgdGhlIHJlYWxtcyBvZiB0aGUKPj4+PiB0cmFmZmlj IGRlc3RpbmVkIHRvIGhvc3RzLCBhbmQgSSBzdXBwb3J0IHRoZSBlZmZvcnRzIHRvIGZpZ3VyZSBv dXQgdGhlCj4+Pj4gcmlnaHQgc2V0IG9mIGtub2JzIGZvciB0aGUgZm9ybWVyLiBUaGF0IHNhaWQs IGZvciB0aGUgbGF0dGVyLCBJJ2QgbGlrZQo+Pj4+IHRvIHNlZSBzb21ldGhpbmcgYWxvbmcgdGhl IGJlbG93IGxpbmVzIGluIHRoZSByZXF1aXJlbWVudHMKPj4+Pj4+IChzb21lIG9mIHdoaWNoIG1h eSBhbHJlYWR5IGJlIGluIHRoZSB0ZXh0IGluIHNvbWUgZm9ybSwgcHV0dGluZyBpdAo+Pj4+IGhl cmUganVzdCBmb3IgZmx1ZW5jeSBvZiB0aGlzIHBpZWNlIG9mIHRoZSBzdG9yeSkuCj4+Pj4+PiAx LiBIb21lbmV0IGhvc3RzIE1VU1QgaW1wbGVtZW50IHRoZWlyIG93biBzZWN1cml0eSBwb2xpY2ll cyBpbgo+Pj4+IGFjY29yZGFuY2UgdG8gdGhlaXIgY29tcHV0aW5nIGNhcGFiaWxpdGllcy4KPj4+ Pj4gSSB0aGluayB3ZSBrbm93IGZyb20gc29tZSBmYW1vdXMgY2FzZXMgdGhhdCBTQ0FEQSBzeXN0 ZW1zIGFyZSBoaWdobHkKPj4+Pj4gaW5zZWN1cmUsIG1haW5seSBkdWUgdG8gZm9sbG93aW5nIHRo aXMgcHJpbmNpcGxlICh0cmFuc2xhdGVkIGFzCj4+Pj4+ICJzZWN1cml0eSBpcyB0b28gaGFyZCBh bmQgdGhpcyBkZXZpY2Ugd2lsbCBhbHdheXMgYmUgb24gYSBwcml2YXRlCj4+Pj4+IG5ldHdvcmsg YW55d2F5IikuIEknbSBhIGJpdCBuZXJ2b3VzIHRoYXQgdGhpcyBwb2xpY3kgd2lsbCBlbmNvdXJh Z2UKPj4+Pj4gbG93LWVuZCBkZXZpY2UgZGVzaWduZXJzIHRvIGNsYXNzaWZ5IHRoZWlyIGRldmlj ZXMgYXMgbm90IGhhdmluZwo+Pj4+PiBlbm91Z2ggcmVzb3VyY2UgdG8gZGVhbCB3aXRoIHNlY3Vy aXR5Lgo+Pj4+Pgo+Pj4+IFRoaXMgY2F0ZWdvcnkgc2hvdWxkIC8gd2lsbCBiZSBlbGltaW5hdGVk IGJ5IG1hcmtldCBmb3JjZXMsIHRvbyBtdWNoCj4+Pj4gbGlhYmlsaXR5IGFzc29jaWF0ZWQgd2l0 aCBiZWluZyB3aWxsZnVsbHkgaW5zZWN1cmUuICBUaGVyZSBhcmUgZmFtb3VzCj4+Pj4gY2FzZXMg Zm9yIHRoaXMgdG9vLgo+Pj4+Cj4+Pj4gSWYgaW50ZXJuZXQgc2VnbWVudGF0aW9uIGlzIGFsbCB0 aGF0IGlzIHJlcXVpcmVkLCB0aGVyZSBhcmUgYWRkcmVzcwo+Pj4+IHR5cGVzIHRoYXQgZmFjaWxp dGF0ZSBsb2NhbCBvbmx5IGFjY2Vzcy4KPj4+Pgo+Pj4+IENiCj4+Pj4+ICAgICBCcmlhbgo+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+Pj4+PiBo b21lbmV0IG1haWxpbmcgbGlzdAo+Pj4+PiBob21lbmV0QGlldGYub3JnPG1haWx0bzpob21lbmV0 QGlldGYub3JnPgo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hv bWVuZXQKPj4+Pgo+Pj4+Cj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KPj4+PiBob21lbmV0IG1haWxpbmcgbGlzdAo+Pj4+IGhvbWVuZXRAaWV0Zi5v cmcKPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2hvbWVuZXQKPj4+ Cj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+Pj4gaG9tZW5ldCBtYWlsaW5nIGxpc3QKPj4+IGhvbWVuZXRA aWV0Zi5vcmcKPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5l dAo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBo b21lbmV0IG1haWxpbmcgbGlzdAo+PiBob21lbmV0QGlldGYub3JnCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaG9tZW5ldAo+Pgo+Cj4KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj5ob21lbmV0IG1haWxpbmcgbGlzdAo+aG9t ZW5ldEBpZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ob21l bmV0Cg== From mcr@sandelman.ca Sat Mar 31 14:30:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621F121F8622 for ; Sat, 31 Mar 2012 14:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 TrTDs0g6Hq7E for ; Sat, 31 Mar 2012 14:30:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id C3AAD21F861B for ; Sat, 31 Mar 2012 14:30:03 -0700 (PDT) Received: from sandelman.ca (unknown [207.164.135.98]) by relay.sandelman.ca (Postfix) with ESMTPS id 3D68B3450E for ; Sat, 31 Mar 2012 17:27:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 30D2198AAE; Sat, 31 Mar 2012 23:29:59 +0200 (CEST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EEBCC98AA9 for ; Sat, 31 Mar 2012 23:29:59 +0200 (CEST) From: Michael Richardson To: homenet X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Sat, 31 Mar 2012 23:29:59 +0200 Message-ID: <2655.1333229399@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [homenet] case for reverse DNS on homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 21:30:04 -0000 There was some minor discussion in the WG about whether reverse DNS was needed at all for home networks. I want to make the case that humans should not have to deal with IPv6 addresses. Furthermore, while one certainly can't make authorization decisions based upon reverse DNS, for non-malicious nodes, the audit record of having a node tell you *something* is valuable. Use case: ISP complains about some activity (maybe a compromised host) Saturday afternoon weeks ago. The reported IPv6 is not known to you. You look at the *(m)DNS* logs (which aren't really that big), and you an entry for: "Mary-Perkins-Laptop". You know that your daughter has a friend named Mary. Was she visiting you ask. Aha... now you know what the problem is. Double use case: since the ISP delegated the reverse to you, when they reported a problem to you, it actually said, "Mary.perkins.name" in the report, and thus you knew everything without even consulting your logs. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From cb.list6@gmail.com Sat Mar 31 14:41:08 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AF221F8754 for ; Sat, 31 Mar 2012 14:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.446 X-Spam-Level: X-Spam-Status: No, score=-3.446 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 G1aIMPhmZcng for ; Sat, 31 Mar 2012 14:41:07 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA8C921F8753 for ; Sat, 31 Mar 2012 14:41:07 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3077724pbb.31 for ; Sat, 31 Mar 2012 14:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NMvszSv2YHSyRAxd0+aYwhYrxWE1JAf8+1//Ia6626w=; b=U1h5itO2XHJzp0c6dYiGWS9yIjqAj8xhM5WAqSmJXT5vksC+WE0sCccWi/q1RoqZbC dAayDR5k7QZCqDXh5Wb8pcr1sUIJdcQAab/ALJpfJWNq6v7U0g1AVpfuf3GhOWAvHiIN 6bsUz6kNTTDvk6BS7rVoSyha2dPEuCnI3NkMR8UxTp1y+oGETBiB4Nm9W9+3vxfnP69v K+PloCpTfrAUuqM7o94MBTCulkCCbFMq2N+ow+JW/XzWkhZFTtazfWEnu1pyE86AGGPQ sUubXt2V6M5ehGoLyFRsrhwMLP0aKqfX+1/DCe8dFOuMIxbt1oBH26rvX6pAqiU+1Gld lUfA== MIME-Version: 1.0 Received: by 10.68.132.36 with SMTP id or4mr7963582pbb.115.1333230067406; Sat, 31 Mar 2012 14:41:07 -0700 (PDT) Received: by 10.142.214.15 with HTTP; Sat, 31 Mar 2012 14:41:07 -0700 (PDT) Received: by 10.142.214.15 with HTTP; Sat, 31 Mar 2012 14:41:07 -0700 (PDT) In-Reply-To: <2655.1333229399@marajade.sandelman.ca> References: <2655.1333229399@marajade.sandelman.ca> Date: Sat, 31 Mar 2012 14:41:07 -0700 Message-ID: From: Cameron Byrne To: Michael Richardson Content-Type: multipart/alternative; boundary=047d7b15a4c992590804bc90d0d7 Cc: homenet Subject: Re: [homenet] case for reverse DNS on homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 21:41:08 -0000 --047d7b15a4c992590804bc90d0d7 Content-Type: text/plain; charset=ISO-8859-1 On Mar 31, 2012 2:30 PM, "Michael Richardson" wrote: > > > There was some minor discussion in the WG about whether reverse DNS was > needed at all for home networks. > > I want to make the case that humans should not have to deal with IPv6 > addresses. Furthermore, while one certainly can't make authorization > decisions based upon reverse DNS, for non-malicious nodes, the audit > record of having a node tell you *something* is valuable. > But then the nodes in homenet are no longer anonymous, and that may be a security / privacy concern, no? Cb > Use case: ISP complains about some activity (maybe a compromised host) > Saturday afternoon weeks ago. The reported IPv6 is not known to you. > You look at the *(m)DNS* logs (which aren't really that big), and you an > entry for: "Mary-Perkins-Laptop". You know that your daughter has a > friend named Mary. Was she visiting you ask. Aha... now you know what > the problem is. > > Double use case: since the ISP delegated the reverse to you, when they > reported a problem to you, it actually said, "Mary.perkins.name" in the > report, and thus you knew everything without even consulting your logs. > > -- > ] He who is tired of Weird Al is tired of life! | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ > ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ > Kyoto Plus: watch the video > then sign the petition. > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --047d7b15a4c992590804bc90d0d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 31, 2012 2:30 PM, "Michael Richardson" <mcr+ietf@sandelman.ca> wrote:
>
>
> There was some minor discussion in the WG about whether reverse DNS wa= s
> needed at all for home networks.
>
> I want to make the case that humans should not have to deal with IPv6<= br> > addresses. =A0Furthermore, while one certainly can't make authoriz= ation
> decisions based upon reverse DNS, for non-malicious nodes, the audit > record of having a node tell you *something* is valuable.
>

But then the nodes in homenet are no longer anonymous, and that may be a= security / privacy concern, no?

Cb
> Use case: ISP complains about some activity (maybe a compromised host)=
> Saturday afternoon weeks ago. =A0The reported IPv6 is not known to you= .
> You look at the *(m)DNS* logs (which aren't really that big), and = you an
> entry for: "Mary-Perkins-Laptop". =A0You know that your daug= hter has a
> friend named Mary. =A0Was she visiting you ask. Aha... now you know wh= at
> the problem is.
>
> Double use case: since the ISP delegated the reverse to you, when they=
> reported a problem to you, it actually said, "Mary.perkins.name" in the
> report, and thus you knew everything without even consulting your logs= .
>
> --
> ] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 = =A0 =A0 =A0 | =A0firewalls =A0[
> ] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0= |net architect[
> ] mcr@sandelman.ottawa.o= n.ca http://www.sandelma= n.ottawa.on.ca/ |device driver[
> =A0 Kyoto Plus: watch the video <http://www.youtube.com/watch?v=3Dkzx1ycLXQSE>=
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition. >
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.= ietf.org/mailman/listinfo/homenet

--047d7b15a4c992590804bc90d0d7-- From touch@isi.edu Sat Mar 31 16:24:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B54A21F86AF for ; Sat, 31 Mar 2012 16:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.319 X-Spam-Level: X-Spam-Status: No, score=-104.319 tagged_above=-999 required=5 tests=[AWL=0.884, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 fkehFXR8ZMQz for ; Sat, 31 Mar 2012 16:24:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7480521F867F for ; Sat, 31 Mar 2012 16:24:35 -0700 (PDT) Received: from [192.168.1.90] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q2VNNxsP012654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 31 Mar 2012 16:24:08 -0700 (PDT) References: <2655.1333229399@marajade.sandelman.ca> In-Reply-To: <2655.1333229399@marajade.sandelman.ca> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9B176) From: Joe Touch Date: Sat, 31 Mar 2012 16:23:58 -0700 To: Michael Richardson X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: homenet Subject: Re: [homenet] case for reverse DNS on homenet X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 23:24:36 -0000 On Mar 31, 2012, at 2:29 PM, Michael Richardson wrot= e: >=20 > There was some minor discussion in the WG about whether reverse DNS was > needed at all for home networks. =20 Why? Do we all like stalls on reverse lookups ( telnet, some logging, x509 v= alidation, acls)? I put this into an automated net system ("tethernet") years ago because it w= as needed. Things haven't changed.=20 Joe From brian.e.carpenter@gmail.com Sat Mar 31 19:14:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5B421F85C4 for ; Sat, 31 Mar 2012 19:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 AgUu8Rjbt4wU for ; Sat, 31 Mar 2012 19:14:04 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 11CBB21F85C2 for ; Sat, 31 Mar 2012 19:14:04 -0700 (PDT) Received: by dady13 with SMTP id y13so1207762dad.27 for ; Sat, 31 Mar 2012 19:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mMdrAHUEe6ZG4J30t2yJ5fMhAMA6i/qd8ioDLod2RBs=; b=0hGcOqRTdxc3hvwxJEBp1Cf5rwI9864ZVOooowylflukgNZnvvYTc8U2V9QgDEGD4X rOWpnD/ouz+YYNW5PIsYwg9qmAqF3Ypt9UkEC7gZzI2jeJ57Blo7irZPJ9+hkrVq6jEc kAaRSbW3CvjuIey7q3hslSrLNNz7NTx72yHNg2I2nDOQHMSq/NM5m37NiJo10uXt8dle Vyc4IJ/mdwc+maPxjAvfWftG4vE0fMmTVci1SUeFlYjmUVMw9Kkm9A/uwC47095p8CzO dThg59CNoLdtJNHD5QTYKjPuh3n0HUe8ZcLoCuwUwucy3rwziNSUxiGRmyT89N31aX94 PecA== Received: by 10.68.223.67 with SMTP id qs3mr9825143pbc.142.1333246443895; Sat, 31 Mar 2012 19:14:03 -0700 (PDT) Received: from [172.18.92.250] ([116.84.159.214]) by mx.google.com with ESMTPS id q8sm10847943pbi.1.2012.03.31.19.14.02 (version=SSLv3 cipher=OTHER); Sat, 31 Mar 2012 19:14:03 -0700 (PDT) Message-ID: <4F77B9E7.1070300@gmail.com> Date: Sun, 01 Apr 2012 14:13:59 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Michael Richardson References: <28142.1332936076@marajade.sandelman.ca> <4F7368C2.1020004@gmail.com> <13637.1333021685@marajade.sandelman.ca> <4F74B5A2.9050301@gmail.com> <16264.1333092927@marajade.sandelman.ca> In-Reply-To: <16264.1333092927@marajade.sandelman.ca> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] one IAB quotation on walled gardens X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 02:14:04 -0000 On 2012-03-30 20:35, Michael Richardson wrote: >>>>>> "Brian" == Brian E Carpenter writes: > Brian> Front posting: I think we are using "walled garden" to mean > Brian> several things and that is confusing. > > Brian> In my mind it refers to a captive customer scenario where a > Brian> service provider is intentionally limiting a customer's > Brian> access to the global Internet or (by playing DNS and/or HTTP > Brian> proxy tricks) presenting a distorted view of the the global > Brian> Internet. > > Brian> This becomes especially obnoxious if the customer has > Brian> multiple providers that attempt to enforce different walled > Brian> gardens. But that's a MIF issue, I think. > > Brian> That is quite different from stating that a customer network > Brian> should be separated from the Internet by a security fence of > Brian> some kind and may also need a local namespace. I thought that > Brian> was normally called an intranet. > > I actually can't see a technical difference. In an enterprise intranet, it's (supposedly) a fact that all routing, firewalling, etc. is administered by the same IT management. Also, multihoming takes place outside the intranet - the "walled garden" boundary is also the multihoming boundary. In a customer/provider scenario, there is split management, and furthermore the multihoming boundary is inside more than one walled garden at the same time. That's why it's messy, IMHO. > Most intranets work by: > 1) intentionally limiting a customer's access to the global Internet > 2) playing DNS tricks > 3) HTTP proxy tricks > 4) having a local name space. > > I think that walled-gardens are the political NAT44 of IPv6. IPv6 makes more walled garden tricks possible, but both intranets and walled gardens abound in IPv4. > > We can, if we want, stick our head in the sand like we did for NAT44, > letting the marketplace produce create an arms race between network > operators and application creators. Or, we can do like we finally did > with BEHAVE and specify something. Good luck balancing on that third rail ;-) Brian > > I'm here in homenet because I care about e2e, I want to avoid NAT66, and > I see great utility in having globably unique addresses everywhere, even > if they are not globally routable/accessible. > > (ps: I shipped NAT44 products in 1994. I hate myself for helping kill > e2e. I shipped it with split-horizon DNS standard. It was all stupid. ) > > > > ------------------------------------------------------------------------ > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet
On Wed, Mar 28, 2012 at 12:44 AM, Ray Hu= nter <v6ops@globis= .net> wrote:
=20
See below.


Dave Taht wrote:
On Thu, Mar 22, 2012 at 3:50 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 2012-03-22 12:33, homenet issue tracker wrote:
> #4: Use of ULAs
>
> =A0CN1 in the -02 text says ULAs should be provisioned by default. =A0Do we
> =A0agree?

Yes, by the CER (MUST).

Firstly are we stating *the* CER or *a* CER? What happens when there is more than one CER? Does that then need an election process? And when the "winner&quo= t; disappears because you've changed providers or router hardware or the router fails, all ULA's also get renumbered?

It's much less clear for all other routers on site. I would prefer that
no other router provisions a ULA prefix if the CER has already delegated one.

Since it is nearly impossible to learn a subnet prefix that is unused unless all devices share a routing protocol, I have generally preferred to generate unique ULAs per routing device.
=A0
Generating a ULA independently per router is potentially going to bring problems with the new RFC3484-revise as they'll almost certainly have different Global ID's (and thus a different /48 prefix), so ULA will not be preferred for communication between nodes connected to different routers.


As I'm arguing with a draft that I have= n't read, I'm a little at a loss.

Will certainly have diffe= rent global ids.

ULA should be preferred for communication between n= odes connected to different routers if they are both in the ULA space. Cons= ider linking two offices via vpn, for example....

Other arguments are other autonomous devices (like devices that have ar= bitrary numbers of subnets, like routers... your car...) or sensor networks= ...

(01:09:33 AM) dtaht: There simply aren't enough routes in a homenet to= fill a routing table inside the home
(01:09:43 AM) dtaht: even if every router chooses a unique ULA


<= br>


Sometimes it's useful to take a complete opposite view to the way you've been thinking, and work though the consequences.

What about going to the extreme and giving up on central/coordinated control of a single ULA /48 Global ID throughout the Homenet?


Love it.
=A0
What about tolerating static prefix assignments (for sensor networks)? We allow static individual IPv6 address assignments to end nodes as well as SLAAC, so why not tolerate statically assigned /64 prefixes? Even in Appletalk, the much vaunted champion of autoconfiguration, a network manager had to manually assign the network number range to at least one seed router in an extended network.


How about:

- multiple ULA /48 Global ID's within a single Homenet is not considered an "error"


OK.
=A0
=A0=A0 Every router may generate it's own ULA /48 Global ID independent= ly, or use an existing one generated by another router.
<= div>
Works for me.
=A0