From shwethab@cisco.com Fri Oct 4 18:36:18 2013 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 B7F0521F9DB4; Fri, 4 Oct 2013 18:36:15 -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 IAXZN7dwT8AH; Fri, 4 Oct 2013 18:36:10 -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 3839221F9DBD; Fri, 4 Oct 2013 18:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2722; q=dns/txt; s=iport; t=1380936967; x=1382146567; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=B7nS6RudhWWzlr3FyQ2N+G3K+0RRxWioiDsm+/3khIk=; b=ehI9TiJol6KKzx7hUDa5fQYauRy7KrisUGXddN2g9oT7TvTWFUwT4iCE kOBbggPp5PzBvlu3r8aKbeBV+U1IJTFwU5loCGCBxmFH1cMG30IBd2S7S tWIn5lHNeWtX/bAY2RgEDQBfJiOFVukLKo2pArk94zExGc/g4wVxt7UHJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAFZsT1KtJV2Z/2dsb2JhbABZgwc4UsBXSoEWFnSCJQEBAQMBAQEBNzQQDQEIIhQ3CyUCBAESCId4Bgy8OQSPIDiDH4EEA6oAgySCKg X-IronPort-AV: E=Sophos;i="4.90,1037,1371081600"; d="scan'208";a="268338955" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 05 Oct 2013 01:36:06 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r951a6al008098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 5 Oct 2013 01:36:06 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.47]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 4 Oct 2013 20:36:06 -0500 From: "Shwetha Bhandari (shwethab)" To: Michael Richardson , "ipv6@ietf.org" , homenet Thread-Topic: [homenet] draft-lepape-6man-prefix-metadata-00 Thread-Index: AQHOue78VAvHfq2MDkilZ8/+bcdu3pnmEq+A Date: Sat, 5 Oct 2013 01:36:06 +0000 Message-ID: In-Reply-To: <6253.1380113890@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.0.0.100825 x-originating-ip: [10.65.79.169] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B26338F332B92479712A020AA398C71@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] draft-lepape-6man-prefix-metadata-00 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, 05 Oct 2013 01:36:18 -0000 Hi Michael, Thanks for the review, please find comments inline @SB On 9/25/13 6:28 PM, "Michael Richardson" wrote: > >I think that this draft is useful land should be adopted. > >I think that application writers will be much happier asking for prefix >colours than properties, if there is a clear set of default colours. >I am concerned that there is an attempt to be too indirect, the way that >DiffServ tried with DSCP, and yet nearly only code point is really >supported >for EF on real networks, so the point where application writers tend to >embed it, at least at the documentation layer. > >section 3.3 talks about: > > Once an application has determined the appropriate property **and** >color > for its use it has to communicate with the network stack to select > >and I thought up to this point that one could select by colour, or by >property. [SB] you are right about colour OR property for selection. Will fix the wording in the draft. > While it's true that the host interface is host specific, for this >to work, someone needs to publish a reference implementation for >Android/Java >and Linux/C/Python... [SB] There is an implementation for Android Section A.1.5 draft-lepape-6man-prefix-metadata-00#appendix-A.1.5 has the details. > >Suggesting three different userspace/kernel methods isn't going to help >get >applications written. APIs matter here. Being able to set a default >colour >for a process (and it's children!!) is probably the initial killer >interface, >because I can now do something like: > low-latency-colour skype & >where the command "low-latency-colour" sets the default colour and then >invokes another command. > >3.5 I believe that local scoping of prefix color is going to be useless. >The prefix colour is a proxy for which ISP/servie, so making it ISP scoped >makes it useless for the application. > >Instead, I suggest that the prefix colour either be a global IANA registry >(DS PHB may already be the right thing...),or make it a uuid. Then >T-mobile >can embed their network prefix colour for video in the video player app >that >they want to shove into my phone... [SB] Yes, UUID to attach e.g. ISP's enterprise ID or using access network identifier information along with the locally scoped colour for selection would provide flexibility while a global registry may be suitable for the properties. Thanks, Shwetha > >-- >Michael Richardson , Sandelman Software Works > > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From Ray.Bellis@nominet.org.uk Wed Oct 9 02:16:22 2013 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 89EC121E8123 for ; Wed, 9 Oct 2013 02:16:22 -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=[AWL=0.000, 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 kXSmQyTCz3Zo for ; Wed, 9 Oct 2013 02:16:17 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3635321E811A for ; Wed, 9 Oct 2013 02:16:14 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=l6whiW2dZhb+knfrZ14YqpxMOXBUkC2qZRUW4aqs5OLrqMeldbVbI6gf TN16Hz6AcLWN6+ZqrgLibwxs7FUnyXL9txpF/gkz5sXef92WYUKu9yL0G plj+VWbng7dURa1h9kmmnq256JQqa/Wmg7CZz1x5DqexQlDgVWOfzRwrJ /g15MYn2KrJFZi+psnfppdlSGk5UGqghDea0Wj0tIbRLggspzyinwZTK2 tCH0oyCk0gpLNwaY9V9FLhy966Vc1; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1381310174; x=1412846174; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=dh52z2bniX6ttD3YyJxGR1XQ/WdpjRT00xmyu9cJu7U=; b=o7oeI3w/YIxkSjl4qtToz3zrQwIuLV0VT+4lzsC8dq0oyK8XGLvUva3K Fa4FFStfG/xPP6pdyvnCMGeKGM9NA7MhsS18UlFKLTyXU9UTiYNq7Lhs/ OxvJnWMvWUiwofX6aZQf7kw2rUT9zMPwab7MCRg2XvX1Iquobxaz4d9p+ 62o0amgUXdrMNu/89H6/QtetCCoK8e0ssPy//MfxKF/QsYD/HkBU1fYvx hr91/KRGRxBZPPdbkGs3Ncwvu8PGK; X-IronPort-AV: E=Sophos;i="4.90,1062,1371078000"; d="scan'208";a="3557050" X-IPAS-Result: AgMFALwdVVLV+MWR/2dsb2JhbABagmYhgQrBKAmBIBZ0gicFHR0ZOAEqFEInBBuHfwOXEqFLjxSDV4EEA6oEgySCKg Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 09 Oct 2013 10:16:13 +0100 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%17]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 10:16:12 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Call for agenda items for IETF 88 Thread-Index: AQHOxNAyom25tBQXT0mMTLj0lycMzQ== Date: Wed, 9 Oct 2013 09:16:12 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEC5AAB@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Call for agenda items for IETF 88 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, 09 Oct 2013 09:16:22 -0000 IETF 88 in Vancouver is coming up on us fast! If you have items to wish to present, please let the chairs know ASAP. In the event of their being too many items for the agenda, priority will be= given to items that have generated substantive discussion on the WG list. Please remember that as in Berlin there is no separate -00 submission deadl= ine - the deadline for draft submissions is UTC 24:00 on Monday October 21s= t. thanks, Ray and Mark From marka@isc.org Wed Oct 16 02:13:39 2013 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 4870D11E82A6; Wed, 16 Oct 2013 02:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 rL2xEO2ChS89; Wed, 16 Oct 2013 02:13:35 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 6A35811E829D; Wed, 16 Oct 2013 02:13:26 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 42AE9C94EE; Wed, 16 Oct 2013 09:13:13 +0000 (UTC) (envelope-from marka@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1381914806; bh=VgtJTkd/jzMQY5dPmK9hV9U249lQf+xLJPs1sLNrA30=; h=To:cc:Reply-To:From:Subject:Date; b=S0tFxusvZNw3zpJIBDqeQUfsbLqq89wDYLK1ZiP/19CyDUV6uAhK9+ywl458r0ZKf 51JQUI71ICbOu/6hUFcp5gwe7drTECRqEsEPGE23PXGZQ1cOaxEfPMi+F73oDIZ0ak e+pYM49Mb563raheq3V6384lOtJ7/QY+XZ3DxWGk= Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Wed, 16 Oct 2013 09:13:13 +0000 (UTC) (envelope-from marka@isc.org) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A5902160470; Wed, 16 Oct 2013 09:17:27 +0000 (UTC) Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 3ED6A160449; Wed, 16 Oct 2013 09:17:27 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 8B00383F46D; Wed, 16 Oct 2013 20:13:08 +1100 (EST) To: dnsop@ietf.org From: Mark Andrews Date: Wed, 16 Oct 2013 20:13:08 +1100 Message-Id: <20131016091308.8B00383F46D@rock.dv.isc.org> X-DCC--Metrics: post.isc.org; whitelist Cc: dhc@ietf.org, homenet@ietf.org Subject: [homenet] Automatic Delegation of IP6.ARPA reverse zones with Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dnsop@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 09:13:39 -0000 Filename: draft-andrews-dnsop-pd-reverse Revision: 00 Title: Automatic Delegation of IP6.ARPA reverse zones with PD Creation date: 2013-10-16 Group: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-andrews-dnsop-pd-reverse-00.txt Status: http://datatracker.ietf.org/doc/draft-andrews-dnsop-pd-reverse Htmlized: http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00 Abstract: This document describes a method to automate the delegation of IPv6.ARPA reverse zones when performing Prefix Delegations. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From mglt.ietf@gmail.com Sun Oct 20 12:47:38 2013 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 ACE1C11E81D0 for ; Sun, 20 Oct 2013 12:47:38 -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, HTML_MESSAGE=0.001, 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 m6M6clg8WbAc for ; Sun, 20 Oct 2013 12:47:37 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D870011E825F for ; Sun, 20 Oct 2013 12:47:34 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so5710085wgh.10 for ; Sun, 20 Oct 2013 12:47:33 -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; bh=nP0UPx2xgQ6d5rXckw1NVnA1yqu/t3McBK/6QpZNajU=; b=c6gELtK6otQGQzXH77meGtHL1K2TWOq8/0B9vavUZgCWJf2r9HmdY26dDjtx4KAJIU d4dohsMieAne8N5PvaKSccMjwWPWPJhHzRFGUcSDorCFCh6nxsY7pPhVLF4tAn9odgqM Otpr1PeXCJVBuVE8PtyPP+l1UFHiueFhyc5lJpmYrGmNLyOvxlPdOH444Q1SuGe7cT5m 1kWOmbXdxKv5h9R0hO7rtv4XKuOD7EfhcklJFeLwj3t3MX6DUA37U5n1zmenwhcrmy84 xzIQJOlKkVNHRiHOdqL0g7Mp4a/JZotp27ClPhvW4nthbTk3px2+q3Rrmgb5IhGbtGDi 7dPg== MIME-Version: 1.0 X-Received: by 10.180.9.134 with SMTP id z6mr6996439wia.9.1382298453902; Sun, 20 Oct 2013 12:47:33 -0700 (PDT) Received: by 10.194.41.138 with HTTP; Sun, 20 Oct 2013 12:47:33 -0700 (PDT) In-Reply-To: <20131020194108.22740.11430.idtracker@ietfa.amsl.com> References: <20131020194108.22740.11430.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 21:47:33 +0200 Message-ID: From: Daniel Migault To: homenet@ietf.org Content-Type: multipart/alternative; boundary=001a11c2b1be518e6b04e93170b1 Subject: [homenet] Fwd: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-03.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: Sun, 20 Oct 2013 19:47:38 -0000 --001a11c2b1be518e6b04e93170b1 Content-Type: text/plain; charset=ISO-8859-1 Hi, Please find our draft presenting the "IPv6 Home Network Naming Delegation". URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-03 Feel free to make comments! Best Regards, Daniel ---------- Forwarded message ---------- From: Date: Sun, Oct 20, 2013 at 9:41 PM Subject: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-03.txt To: Wouter Cloetens , Chris Griffiths < cgriffiths@dyn.com>, Daniel Migault , Ralf Weber < ralf.weber@nominum.com> A new version of I-D, draft-mglt-homenet-front-end-naming-delegation-03.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-homenet-front-end-naming-delegation Revision: 03 Title: IPv6 Home Network Naming Delegation Creation date: 2013-10-20 Group: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt Status: http://datatracker.ietf.org/doc/draft-mglt-homenet-front-end-naming-delegation Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-homenet-front-end-naming-delegation-03 Abstract: CPEs are designed to provide IP connectivity to home networks. Most CPEs assigns IP addresses to the nodes of the home network which makes it a good candidate for hosting the naming service. With IPv6, the naming service makes nodes reachable from the home network as well as from the Internet. However, CPEs have not been designed to host such a naming service exposed on the Internet. This MAY expose the CPEs to resource exhaustion which would make the home network unreachable, and most probably would also affect the home network inner communications. In addition, DNSSEC management and configuration may not be well understood or mastered by regular end users. Misconfiguration MAY also results in naming service disruption, thus these end users MAY prefer to rely on third party naming providers. This document describes a homenet naming architecture where the CPEs manage the DNS zone associates to its home network, and outsource both DNSSEC management and naming service on the Internet to a third party designated as the Public Authoritative Servers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --001a11c2b1be518e6b04e93170b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0

Please find our draft presenting= the "IPv6 Home Network Naming Delegation".=A0

Best Regards,=A0
=

Daniel

---------- For= warded message ----------
From: <internet-draft= s@ietf.org>
Date: Sun, Oct 20, 2013 at 9:41 PM
Subject: New Version Notification for= draft-mglt-homenet-front-end-naming-delegation-03.txt
To: Wouter Cloete= ns <wouter.cloetens@so= ftathome.com>, Chris Griffiths <cgriffiths@dyn.com>, Daniel Migault <mglt.ietf@gmail.com>, Ralf Weber <ralf.weber@nominum.com>



A new version of I-D, draft-mglt-homenet-front-end-naming-delegation-03.txt=
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-homenet-front-end-naming-delegation
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 IPv6 Home Network Naming Delegation
Creation date: =A0 2013-10-20
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 19
URL: =A0 =A0 =A0 =A0 =A0 =A0 h= ttp://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-dele= gation-03.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatra= cker.ietf.org/doc/draft-mglt-homenet-front-end-naming-delegation
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.= org/html/draft-mglt-homenet-front-end-naming-delegation-03
Diff: =A0 =A0 =A0 =A0 =A0 =A0http:/= /www.ietf.org/rfcdiff?url2=3Ddraft-mglt-homenet-front-end-naming-delegation= -03

Abstract:
=A0 =A0CPEs are designed to provide IP connectivity to home networks. =A0Mo= st
=A0 =A0CPEs assigns IP addresses to the nodes of the home network which
=A0 =A0makes it a good candidate for hosting the naming service. =A0With IP= v6,
=A0 =A0the naming service makes nodes reachable from the home network as =A0 =A0well as from the Internet.

=A0 =A0However, CPEs have not been designed to host such a naming service =A0 =A0exposed on the Internet. =A0This MAY expose the CPEs to resource
=A0 =A0exhaustion which would make the home network unreachable, and most =A0 =A0probably would also affect the home network inner communications.
=A0 =A0In addition, DNSSEC management and configuration may not be well
=A0 =A0understood or mastered by regular end users. =A0Misconfiguration MAY=
=A0 =A0also results in naming service disruption, thus these end users MAY<= br> =A0 =A0prefer to rely on third party naming providers.

=A0 =A0This document describes a homenet naming architecture where the CPEs=
=A0 =A0manage the DNS zone associates to its home network, and outsource =A0 =A0both DNSSEC management and naming service on the Internet to a third=
=A0 =A0party designated as the Public Authoritative Servers.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Daniel Migault
Orange = Labs -- Security
+33 6 70 72 69 58
--001a11c2b1be518e6b04e93170b1-- From mglt.ietf@gmail.com Sun Oct 20 12:51:48 2013 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 7B5FF11E825F; Sun, 20 Oct 2013 12:51:48 -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, HTML_MESSAGE=0.001, 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 CTEuutPXfr7B; Sun, 20 Oct 2013 12:51:47 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6111E822C; Sun, 20 Oct 2013 12:51:46 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id l12so3033587wiv.9 for ; Sun, 20 Oct 2013 12:51:46 -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=jMvdc1bz8EZkUq8stk7zUeXuqrPwk0IknSK8cMpVX7g=; b=HCr8BCueDI2mbog0kckcec5EFF1PeOtrREafl477hz8eHKVmclsPcrZ46sNa+fRHwO lqXFrtHrgf+damzIlakl53jVVH8ypHcWzdoXTfdWYRjk2pCr02AeGYMLh9aE3jEOzlG+ BA8uQP+bL3e0K67r2f5DQkPXZctvI6q0WMxhNGaTLLWFLgTlVJOV8i9VJM6CQD84dsdH eG10oLtTGFe7dFwg4Cv+Dn9WDL+k5CoQ0eZ8hi5Gv6M2nsHFiURXDiym7mD5PNojZdac zKsxCZvj/Pay326apP1EAbbBktzrOCNHv2lm4AULddjyzF+9n+V1iatqIZ1WOUd41PoW ZyVw== MIME-Version: 1.0 X-Received: by 10.194.110.138 with SMTP id ia10mr10884755wjb.3.1382298706134; Sun, 20 Oct 2013 12:51:46 -0700 (PDT) Received: by 10.194.41.138 with HTTP; Sun, 20 Oct 2013 12:51:46 -0700 (PDT) In-Reply-To: <20131020194121.22779.70469.idtracker@ietfa.amsl.com> References: <20131020194121.22779.70469.idtracker@ietfa.amsl.com> Date: Sun, 20 Oct 2013 21:51:46 +0200 Message-ID: From: Daniel Migault To: homenet@ietf.org Content-Type: multipart/alternative; boundary=047d7bf10aa85a4ef604e9317f54 Cc: dhcwg@ietf.org Subject: [homenet] Fwd: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-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: Sun, 20 Oct 2013 19:51:48 -0000 --047d7bf10aa85a4ef604e9317f54 Content-Type: text/plain; charset=ISO-8859-1 Hi, Please find a description of DHCP options intended to configure the "IPv6 Home Network Naming Delegation". [1] Feel free to make comments! Best Regards, Daniel URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00 [1] http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt ---------- Forwarded message ---------- From: Date: Sun, Oct 20, 2013 at 9:41 PM Subject: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-00.txt To: Wouter Cloetens , Chris Griffiths < cgriffiths@dyn.com>, Daniel Migault , Ralf Weber < ralf.weber@nominum.com> A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-00.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-homenet-naming-architecture-dhc-options Revision: 00 Title: DHCP DNS Public Authoritative Server Options Creation date: 2013-10-20 Group: Individual Submission Number of pages: 35 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt Status: http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00 Abstract: The home network naming architecture as described in [I-D.mglt- homenet-front-end-naming-delegation] requires a complex naming configuration on the CPE. This configuration MAY not be handled easily by the average end user. Furthermore, such misconfiguration MAY result in making home network unreachable. This document proposes a DHCP options that provide the CPE all necessary parameters to set up the home network naming architecture. First, this DHCP options provide automatic configuration and avoid most end users' misconfiguration. Most average end users may not require specific configuration, and their ISP default configuration MAY fully address their needs. In that case, the naming homenet architecture configuration will be completely transparent to the end users. Then, saving naming configuration outside the CPE, makes it resilient to change of CPE or CPE upgrades. Such configuration may also be configured by the end user, via the customer area of their ISP. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bf10aa85a4ef604e9317f54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,=A0

Please find a description of DHC= P options intended to configure the=A0"IPv6 Home Network Naming Delegation".=A0[1]

Feel free to make comments!

Best Regards,=A0
Daniel
---------- F= orwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, Oct 20, 2013 at 9:41 PM
Subject: New Version Notification for= draft-mglt-homenet-naming-architecture-dhc-options-00.txt
To: Wouter Cl= oetens <wouter.cloetens@softathome.com>, Chris Griffiths <cgriffiths@dyn.com>, Da= niel Migault <m= glt.ietf@gmail.com>, Ralf Weber <ralf.weber@nominum.com>



A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-00= .txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-homenet-naming-architecture-dhc-options=
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 DHCP DNS Public Authoritative Server Options
Creation date: =A0 2013-10-20
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 35
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architectu= re-dhc-options-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://dat= atracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options
Htmlized: =A0 =A0 =A0 =A0http://tools.i= etf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00


Abstract:
=A0 =A0The home network naming architecture as described in [I-D.mglt-
=A0 =A0homenet-front-end-naming-delegation] requires a complex naming
=A0 =A0configuration on the CPE. =A0This configuration MAY not be handled =A0 =A0easily by the average end user. =A0Furthermore, such misconfiguratio= n
=A0 =A0MAY result in making home network unreachable.

=A0 =A0This document proposes a DHCP options that provide the CPE all
=A0 =A0necessary parameters to set up the home network naming architecture.=

=A0 =A0First, this DHCP options provide automatic configuration and avoid =A0 =A0most end users' misconfiguration. =A0Most average end users may = not
=A0 =A0require specific configuration, and their ISP default configuration<= br> =A0 =A0MAY fully address their needs. =A0In that case, the naming homenet =A0 =A0architecture configuration will be completely transparent to the end=
=A0 =A0users. =A0Then, saving naming configuration outside the CPE, makes i= t
=A0 =A0resilient to change of CPE or CPE upgrades. =A0Such configuration ma= y
=A0 =A0also be configured by the end user, via the customer area of their =A0 =A0ISP.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Daniel Migault
Orange = Labs -- Security
+33 6 70 72 69 58
--047d7bf10aa85a4ef604e9317f54-- From mglt.ietf@gmail.com Mon Oct 21 00:19:21 2013 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 A9C4F11E84D2; Mon, 21 Oct 2013 00:19:21 -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, HTML_MESSAGE=0.001, 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 ovarJtCm0gRi; Mon, 21 Oct 2013 00:19:20 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3F12B11E84DD; Mon, 21 Oct 2013 00:19:12 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id f12so6091139wgh.31 for ; Mon, 21 Oct 2013 00:19: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; bh=I7SzYz9xXKq114VJ3kt5oiD+1Qr/V9pBQ5wkIAiHOto=; b=jy5xT8L4EreOFsEPVDlUyyDaVAg6gvcP3AFx2eaJk3+KD5KkjoLoAwmMRhYge8PO4R e7A4f2tbh/b8FyEkqBbMvWvTdJCtLq1BpSAbJgTLwLnQjROPmTcfVs7N9EWO1dPleHgI hwXphnzKdRv8ke6izcn1DF9KDZfp3xPvzrC/Rf6DDeY2p/q0sWD+i6mCD3HofxpOlWan I0ZE0m9RgUQJx5uzXBl4FgmNB4dfg2IJgesrKwQrS26owXZ1ocRkw3HjwT2Xcr0dJOo2 HkyYiHMnL6OTuK9HixHqOt99ayWK+wN4Ly7wqNDPNg+NjrSJCuYKJIWaZ9RbsBht52zU dL/A== MIME-Version: 1.0 X-Received: by 10.194.119.132 with SMTP id ku4mr379428wjb.51.1382339951145; Mon, 21 Oct 2013 00:19:11 -0700 (PDT) Received: by 10.194.41.138 with HTTP; Mon, 21 Oct 2013 00:19:11 -0700 (PDT) In-Reply-To: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 09:19:11 +0200 Message-ID: From: Daniel Migault To: homenet@ietf.org Content-Type: multipart/alternative; boundary=089e01228d72bf8afc04e93b19a6 Cc: dnsop@ietf.org Subject: [homenet] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 21 Oct 2013 07:19:21 -0000 --089e01228d72bf8afc04e93b19a6 Content-Type: text/plain; charset=ISO-8859-1 Hi, Please find a draft that defines DHCP options to provision DNSSEC validators so DNSSEC validation can always be performed. Feel free to make any comments. I would be happy to have f2f discussion during IETF88 to solve this issue with a more complete document. Best Regards, Daniel URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-dnssec-validator-dhc-options-02.txt Abstract: DNSSEC provides data integrity and authentication for DNSSEC validators. However, without valid trust anchor(s) and an acceptable value for the current time, DNSSEC validation cannot be performed. As a result, there are multiple cases where DNSSEC validation MUST NOT be performed. In addition, this list of exceptions is expected to become larger over time. Considering an increasing number of cases where DNSSEC is disabled adds complexity to the DNSSEC validator implementations and increases the vectors that disable security. This document assumes that DNSSEC adoption by end devices requires that end devices MUST be able to support a DNSSEC validation always set. This MUST be valid today as well as in the future. This document describes DHCP Options to provision the DHCP Client with valid trust anchors and time so DNSSEC validation can be performed. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. ---------- Forwarded message ---------- From: Date: Mon, Oct 21, 2013 at 9:12 AM Subject: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-02.txt To: Daniel Migault A new version of I-D, draft-mglt-homenet-dnssec-validator-dhc-options-02.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-homenet-dnssec-validator-dhc-options Revision: 02 Title: DNSSEC Validators DHCP Options Creation date: 2013-10-21 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-dnssec-validator-dhc-options-02.txt Status: http://datatracker.ietf.org/doc/draft-mglt-homenet-dnssec-validator-dhc-options Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-dnssec-validator-dhc-options-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-homenet-dnssec-validator-dhc-options-02 Abstract: DNSSEC provides data integrity and authentication for DNSSEC validators. However, without valid trust anchor(s) and an acceptable value for the current time, DNSSEC validation cannot be performed. As a result, there are multiple cases where DNSSEC validation MUST NOT be performed. In addition, this list of exceptions is expected to become larger over time. Considering an increasing number of cases where DNSSEC is disabled adds complexity to the DNSSEC validator implementations and increases the vectors that disable security. This document assumes that DNSSEC adoption by end devices requires that end devices MUST be able to support a DNSSEC validation always set. This MUST be valid today as well as in the future. This document describes DHCP Options to provision the DHCP Client with valid trust anchors and time so DNSSEC validation can be performed. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --089e01228d72bf8afc04e93b19a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Please find a draft = that defines DHCP options to provision DNSSEC validators so DNSSEC validati= on can always be performed.

Feel free to make any comments. I= would be happy to have f2f discussion during IETF88 to solve this issue wi= th a more complete document.

Best Regards,
Daniel

UR= L: http://www.ietf.org/intern= et-drafts/draft-mglt-homenet-dnssec-validator-dhc-options-02.txt

Abstract:
=A0 =A0DNSSEC provides data integrity and authentication for DNSSEC
=A0 =A0validators. =A0However, without valid trust anchor(s) and an accepta= ble
=A0 =A0value for the current time, DNSSEC validation cannot be performed. =A0 =A0As a result, there are multiple cases where DNSSEC validation MUST =A0 =A0NOT be performed. =A0In addition, this list of exceptions is expecte= d
=A0 =A0to become larger over time.

=A0 =A0Considering an increasing number of cases where DNSSEC is disabled =A0 =A0adds complexity to the DNSSEC validator implementations and increase= s
=A0 =A0the vectors that disable security.

=A0 =A0This document assumes that DNSSEC adoption by end devices requires =A0 =A0that end devices MUST be able to support a DNSSEC validation always<= br> =A0 =A0set. =A0This MUST be valid today as well as in the future.

=A0 =A0This document describes DHCP Options to provision the DHCP Client =A0 =A0with valid trust anchors and time so DNSSEC validation can be
=A0 =A0performed.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.



---------- Forwarded message ----------<= br>From: <internet-drafts@ietf.org>
Date: Mon, Oct 21, 2013 at 9:12 AM
Subject: New Version Notification for= draft-mglt-homenet-dnssec-validator-dhc-options-02.txt
To: Daniel Migau= lt <mglt.ietf@gmail.com>


A new version of I-D, draft-mglt-homenet-dnssec-validator-dhc-options-02.tx= t
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-homenet-dnssec-validator-dhc-options Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 DNSSEC Validators DHCP Options
Creation date: =A0 2013-10-21
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12
URL: =A0 =A0 =A0 =A0 =A0 =A0 = http://www.ietf.org/internet-drafts/draft-mglt-homenet-dnssec-validator-dhc= -options-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatr= acker.ietf.org/doc/draft-mglt-homenet-dnssec-validator-dhc-options
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf= .org/html/draft-mglt-homenet-dnssec-validator-dhc-options-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http:= //www.ietf.org/rfcdiff?url2=3Ddraft-mglt-homenet-dnssec-validator-dhc-optio= ns-02

Abstract:
=A0 =A0DNSSEC provides data integrity and authentication for DNSSEC
=A0 =A0validators. =A0However, without valid trust anchor(s) and an accepta= ble
=A0 =A0value for the current time, DNSSEC validation cannot be performed. =A0 =A0As a result, there are multiple cases where DNSSEC validation MUST =A0 =A0NOT be performed. =A0In addition, this list of exceptions is expecte= d
=A0 =A0to become larger over time.

=A0 =A0Considering an increasing number of cases where DNSSEC is disabled =A0 =A0adds complexity to the DNSSEC validator implementations and increase= s
=A0 =A0the vectors that disable security.

=A0 =A0This document assumes that DNSSEC adoption by end devices requires =A0 =A0that end devices MUST be able to support a DNSSEC validation always<= br> =A0 =A0set. =A0This MUST be valid today as well as in the future.

=A0 =A0This document describes DHCP Options to provision the DHCP Client =A0 =A0with valid trust anchors and time so DNSSEC validation can be
=A0 =A0performed.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Daniel Migault
Orange Labs -- Sec= urity
+33 6 70 72 69 58
--089e01228d72bf8afc04e93b19a6-- From mglt.ietf@gmail.com Mon Oct 21 04:54:25 2013 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 0E91011E84AF; Mon, 21 Oct 2013 04:54:25 -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, HTML_MESSAGE=0.001, 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 xBNzg1jPFggZ; Mon, 21 Oct 2013 04:54:23 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AAAD711E83B0; Mon, 21 Oct 2013 04:54:10 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id cb5so3784091wib.7 for ; Mon, 21 Oct 2013 04:53:59 -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=Gex2xXdzhRt6b5RbT6RbmTFr0i4t0g/HeffxS/99mdE=; b=MM9H4qt83XnXd/hwdLXPoEAgVeksOp8KbgMRPxV3E4eu/eHjrdQ63CPvY3iYm7LLjD fCs8tHO2faS9ubHDVcADFkWoFdt8X+cuwWaUTZwwD6fvlgv78qTswbMtJrSk5d9fhyJV mOtEiGJ0VEdUSXql601YmYi0UtqOW9BZanrFXa6DH0D9axV+1Kl+13FPwhGehykMTuT4 ryXMwcLyYJrx2KLM5SPPvTNO8w5/VLVz988+30NZsy2vTwVSUX3k/FSHe+nFOk1LQc72 h+yd9ZD7lc1vJxS25KZn2kims9VJiBB3c7XnEXG3I6N/yCrcBosC626n78Puzf8TFIoM y5FA== MIME-Version: 1.0 X-Received: by 10.180.206.178 with SMTP id lp18mr9495063wic.40.1382356439027; Mon, 21 Oct 2013 04:53:59 -0700 (PDT) Received: by 10.194.41.138 with HTTP; Mon, 21 Oct 2013 04:53:58 -0700 (PDT) In-Reply-To: References: <20131020194121.22779.70469.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 13:53:58 +0200 Message-ID: From: Daniel Migault To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=001a11c3844a80586404e93ef0df Cc: "dhcwg@ietf.org" , "homenet@ietf.org" Subject: Re: [homenet] [dhcwg] Fwd: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-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, 21 Oct 2013 11:54:25 -0000 --001a11c3844a80586404e93ef0df Content-Type: text/plain; charset=ISO-8859-1 Hi Bernie, Thanks for your feed back. See my comments in the text. On Mon, Oct 21, 2013 at 3:09 AM, Bernie Volz (volz) wrote: > These are comments with WG co-chair hat off. > > I don't recall providing input to this document: > > 11 . Acknowledgment > > We would like to thank Tomasz Mrugalski and Bernie Volz for their > comments on the design of the DHCP Options. > > > We received comments and recommendations from the previous version on Jul 05 -- Basically splitting the complex option we proposed, and following (and reading) the guide lines. We expected to present our new design at IETF87, but ran out schedule. And at first glance this looks like encapsulation gone crazy!! > This is also my opinion. My understanding of the option guidelines was to use encapsulation of options instead of specific format. We might have mis-understood something or gone too far. Either ways I am very glad to have your feed backs. We can easily remove some encapsulations. > I haven't yet read it carefully enough to determine whether this makes > sense to do. > > There is no complex or hidden reasons for encapsulation. We might have done it the wrong way. This version is expected to be a document for discussion. We hope next versions converge quickly. > I don't like things like requiring a server to return "empty" options if > it "understands" them but they were not configured (or "badly" configured). > And I can't see any benefit to the client for doing this documented > (there's no special action the client is specified to take) -- so why do it? > > The only benefit for the client is that it can decide between sending a message with "Options not supported" or "Badly configured Homenet Naming Architectures". We can remove this requirement. > - Bernie (from iPad) > > On Oct 20, 2013, at 3:52 PM, "Daniel Migault" wrote: > > Hi, > > Please find a description of DHCP options intended to configure the "IPv6 > Home Network Naming Delegation". [1] > > Feel free to make comments! > > Best Regards, > Daniel > > URL: > http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt > Htmlized: > http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00 > > [1] > http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt > > > > ---------- Forwarded message ---------- > From: > Date: Sun, Oct 20, 2013 at 9:41 PM > Subject: New Version Notification for > draft-mglt-homenet-naming-architecture-dhc-options-00.txt > To: Wouter Cloetens , Chris Griffiths < > cgriffiths@dyn.com>, Daniel Migault , Ralf Weber < > ralf.weber@nominum.com> > > > > A new version of I-D, > draft-mglt-homenet-naming-architecture-dhc-options-00.txt > has been successfully submitted by Daniel Migault and posted to the > IETF repository. > > Filename: draft-mglt-homenet-naming-architecture-dhc-options > Revision: 00 > Title: DHCP DNS Public Authoritative Server Options > Creation date: 2013-10-20 > Group: Individual Submission > Number of pages: 35 > URL: > http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt > Status: > http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options > Htmlized: > http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00 > > > Abstract: > The home network naming architecture as described in [I-D.mglt- > homenet-front-end-naming-delegation] requires a complex naming > configuration on the CPE. This configuration MAY not be handled > easily by the average end user. Furthermore, such misconfiguration > MAY result in making home network unreachable. > > This document proposes a DHCP options that provide the CPE all > necessary parameters to set up the home network naming architecture. > > First, this DHCP options provide automatic configuration and avoid > most end users' misconfiguration. Most average end users may not > require specific configuration, and their ISP default configuration > MAY fully address their needs. In that case, the naming homenet > architecture configuration will be completely transparent to the end > users. Then, saving naming configuration outside the CPE, makes it > resilient to change of CPE or CPE upgrades. Such configuration may > also be configured by the end user, via the customer area of their > ISP. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > > _______________________________________________ > > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --001a11c3844a80586404e93ef0df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Bernie,

<= div class=3D"gmail_extra">Thanks for your feed back. See my comments in the= text.

O= n Mon, Oct 21, 2013 at 3:09 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
These are comments with WG co-chair hat off.

I don't recall providing input to this document:



11.  Acknowled=
gment


We would like to thank Tomasz Mrugalski and Bernie Volz for th=
eir
   comments on the design of the DHCP Options.

We received comments and recommendations from= the previous version on Jul 05 -- Basically splitting the complex option w= e proposed, and following (and reading) the guide lines. We expected to pre= sent our new design at IETF87, but ran out schedule. =A0

=
And at first glance this looks like encapsulation gone crazy!!
=A0
This is also my opinion. My under= standing of the option guidelines was to use encapsulation of options inste= ad of specific format. We might have mis-understood something or gone too f= ar. Either ways I am very glad to have your feed backs. We can easily remov= e some encapsulations.=A0


I haven't yet read it carefully enough to determine whether this m= akes sense to do.

=A0There is no complex or hidd= en reasons for encapsulation. We might have done it the wrong way. This ver= sion is expected to be a document for discussion. We hope next versions con= verge quickly.
=A0
=A0
<= div>
I don't like things like requiring a server to return "empty&= quot; options if it "understands" them but they were not configur= ed (or "badly" configured). And I can't see any benefit to th= e client for doing this documented (there's no special action the clien= t is specified to take) -- so why do it?

The only benefit for the client is that i= t can decide between sending a message with "Options not supported&quo= t; or "Badly configured Homenet Naming Architectures". We can rem= ove this requirement.
=A0
- Bernie (from iPad)

On Oct 20, 2013, at 3:52 PM, "Daniel Migault" <mglt.ietf@gmail.com> wrote= :

Hi,=A0

Please find a description of DHCP options intended to configure the=A0= "IPv6 Home= Network Naming Delegation".=A0[1]

Feel free to make comments!

Best Regards,=A0
Daniel
=A0
URL:=A0http://www.ietf.org= /internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.txt<= /a>
Htmlized:=A0http://tools.ietf.org/html/= draft-mglt-homenet-naming-architecture-dhc-options-00

[1]=A0=A0http://www.ietf.org/int= ernet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, Oct 20, 2013 at 9:41 PM
Subject: New Version Notification for draft-mglt-homenet-naming-architectur= e-dhc-options-00.txt
To: Wouter Cloetens <wouter.cloetens@softathome.com>, Chris Griffiths &l= t;cgriffiths@dyn.co= m>, Daniel Migault <mglt.ietf@gmail.com>, Ralf Weber <ralf.weber@nominum.com>



A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-00= .txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-homenet-naming-architecture-dhc-options=
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 DHCP DNS Public Authoritative Server Options
Creation date: =A0 2013-10-20
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 35
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-= dhc-options-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://dat= atracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options
Htmlized: =A0 =A0 =A0 =A0http://tools.i= etf.org/html/draft-mglt-homenet-naming-architecture-dhc-options-00


Abstract:
=A0 =A0The home network naming architecture as described in [I-D.mglt-
=A0 =A0homenet-front-end-naming-delegation] requires a complex naming
=A0 =A0configuration on the CPE. =A0This configuration MAY not be handled =A0 =A0easily by the average end user. =A0Furthermore, such misconfiguratio= n
=A0 =A0MAY result in making home network unreachable.

=A0 =A0This document proposes a DHCP options that provide the CPE all
=A0 =A0necessary parameters to set up the home network naming architecture.=

=A0 =A0First, this DHCP options provide automatic configuration and avoid =A0 =A0most end users' misconfiguration. =A0Most average end users may = not
=A0 =A0require specific configuration, and their ISP default configuration<= br> =A0 =A0MAY fully address their needs. =A0In that case, the naming homenet =A0 =A0architecture configuration will be completely transparent to the end=
=A0 =A0users. =A0Then, saving naming configuration outside the CPE, makes i= t
=A0 =A0resilient to change of CPE or CPE upgrades. =A0Such configuration ma= y
=A0 =A0also be configured by the end user, via the customer area of their =A0 =A0ISP.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________



--
Daniel Migault
Orang= e Labs -- Security
+33 6 70 72 69 58
--001a11c3844a80586404e93ef0df-- From volz@cisco.com Sun Oct 20 18:10:04 2013 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 1766011E8307; Sun, 20 Oct 2013 18:10:04 -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 2LoZtYtj3F3M; Sun, 20 Oct 2013 18:09:59 -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 A8E4111E80FB; Sun, 20 Oct 2013 18:09:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13025; q=dns/txt; s=iport; t=1382317798; x=1383527398; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=P455eNF/ebFXJfSyHKf38tVWSD7uYtdpYzDw7C/KS24=; b=DPZhAJPqDb4KqyGro59R1st2mz4hqCQFEFCwBA3+Wp7ErkH2eOa+3Vv4 6EBq+al2fqLWA9lNipNBd+JHcvIzO5YIcmR6BGq+c88U+Rm4dzkbafxxb mN2hBOHqj73FfB7tm4vQ4bm0GMKfAUZIdlPvAo3p5wCPQ862WJE/+P9SH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMGAHt+ZFKtJXHB/2dsb2JhbABagkNEOKxNiWaITYElFnSCJQEBAQQBAQFrCQIQAgEIDgMBAgECJAQHIQYLFAMGCAIEDgUJh2sDDw20Aw2Ja4xsgUSBGw0EBgEGA4MWgQoDlh6Ba4EviyGFN4FmgT6Bag X-IronPort-AV: E=Sophos;i="4.93,535,1378857600"; d="scan'208,217";a="274415247" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 21 Oct 2013 01:09:58 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9L19vwb015815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Oct 2013 01:09:57 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Sun, 20 Oct 2013 20:09:57 -0500 From: "Bernie Volz (volz)" To: Daniel Migault Thread-Topic: [dhcwg] Fwd: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-00.txt Thread-Index: AQHOzc3YL1Pao1qEC0uGX6iM7/BHRJn+WOcf Date: Mon, 21 Oct 2013 01:09:56 +0000 Message-ID: References: <20131020194121.22779.70469.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E47592E33A164AC6A0B866B30B35E34Aciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 21 Oct 2013 08:13:25 -0700 Cc: "dhcwg@ietf.org" , "homenet@ietf.org" Subject: Re: [homenet] [dhcwg] Fwd: New Version Notification for draft-mglt-homenet-naming-architecture-dhc-options-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, 21 Oct 2013 01:10:05 -0000 --_000_E47592E33A164AC6A0B866B30B35E34Aciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable These are comments with WG co-chair hat off. I don't recall providing input to this document: 11. Acknowledgment We would like to thank Tomasz Mrugalski and Bernie Volz for their comments on the design of the DHCP Options. And at first glance this looks like encapsulation gone crazy!! I haven't yet read it carefully enough to determine whether this makes sens= e to do. I don't like things like requiring a server to return "empty" options if it= "understands" them but they were not configured (or "badly" configured). A= nd I can't see any benefit to the client for doing this documented (there's= no special action the client is specified to take) -- so why do it? - Bernie (from iPad) On Oct 20, 2013, at 3:52 PM, "Daniel Migault" > wrote: Hi, Please find a description of DHCP options intended to configure the "IPv6 H= ome Network Naming Delegation". [1] Feel free to make comments! Best Regards, Daniel URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architec= ture-dhc-options-00.txt Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-architecture= -dhc-options-00 [1] http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-namin= g-delegation-03.txt ---------- Forwarded message ---------- From: > Date: Sun, Oct 20, 2013 at 9:41 PM Subject: New Version Notification for draft-mglt-homenet-naming-architectur= e-dhc-options-00.txt To: Wouter Cloetens >, Chris Griffiths >, Daniel Migault >, R= alf Weber > A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-00= .txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-homenet-naming-architecture-dhc-options Revision: 00 Title: DHCP DNS Public Authoritative Server Options Creation date: 2013-10-20 Group: Individual Submission Number of pages: 35 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-nam= ing-architecture-dhc-options-00.txt Status: http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-= architecture-dhc-options Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-naming-archi= tecture-dhc-options-00 Abstract: The home network naming architecture as described in [I-D.mglt- homenet-front-end-naming-delegation] requires a complex naming configuration on the CPE. This configuration MAY not be handled easily by the average end user. Furthermore, such misconfiguration MAY result in making home network unreachable. This document proposes a DHCP options that provide the CPE all necessary parameters to set up the home network naming architecture. First, this DHCP options provide automatic configuration and avoid most end users' misconfiguration. Most average end users may not require specific configuration, and their ISP default configuration MAY fully address their needs. In that case, the naming homenet architecture configuration will be completely transparent to the end users. Then, saving naming configuration outside the CPE, makes it resilient to change of CPE or CPE upgrades. Such configuration may also be configured by the end user, via the customer area of their ISP. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_E47592E33A164AC6A0B866B30B35E34Aciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
These are comments with WG = co-chair hat off.

I don't recall providing in= put to this document:

Hi, 

Please find a description of DHCP options intended to configure the&nb= sp;"IPv6 H= ome Network Naming Delegation". [1]

Feel free to make comments!

Best Regards, 
Daniel
 
URL: http://www.ietf.= org/internet-drafts/draft-mglt-homenet-naming-architecture-dhc-options-00.t= xt
Htmlized: http://tools.ietf.org/ht= ml/draft-mglt-homenet-naming-architecture-dhc-options-00

[1]  http://www.ietf.o= rg/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-03.txt



---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Sun, Oct 20, 2013 at 9:41 PM
Subject: New Version Notification for draft-mglt-homenet-naming-architectur= e-dhc-options-00.txt
To: Wouter Cloetens <wouter.cloetens@softathome.com>, Chris Griffiths &l= t;cgriffiths@dyn.co= m>, Daniel Migault <mglt.ietf@gmail.com>, Ralf Weber <ralf.weber@nominum.com>



A new version of I-D, draft-mglt-homenet-naming-architecture-dhc-options-00= .txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename:        draft-mglt-homenet-naming-architecture= -dhc-options
Revision:        00
Title:           DHCP DNS Public Authoritative Ser= ver Options
Creation date:   2013-10-20
Group:           Individual Submission
Number of pages: 35
URL:             http://www.ietf.org/internet-drafts/draft-mglt-homenet-naming-architecture-= dhc-options-00.txt
Status:          http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture= -dhc-options
Htmlized:        ht= tp://tools.ietf.org/html/draft-mglt-homenet-naming-architecture-dhc-options= -00


Abstract:
   The home network naming architecture as described in [I-D.mglt= -
   homenet-front-end-naming-delegation] requires a complex naming=
   configuration on the CPE.  This configuration MAY not be = handled
   easily by the average end user.  Furthermore, such miscon= figuration
   MAY result in making home network unreachable.

   This document proposes a DHCP options that provide the CPE all=
   necessary parameters to set up the home network naming archite= cture.

   First, this DHCP options provide automatic configuration and a= void
   most end users' misconfiguration.  Most average end users= may not
   require specific configuration, and their ISP default configur= ation
   MAY fully address their needs.  In that case, the naming = homenet
   architecture configuration will be completely transparent to t= he end
   users.  Then, saving naming configuration outside the CPE= , makes it
   resilient to change of CPE or CPE upgrades.  Such configu= ration may
   also be configured by the end user, via the customer area of t= heir
   ISP.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.i= etf.org/mailman/listinfo/dhcwg
--_000_E47592E33A164AC6A0B866B30B35E34Aciscocom_-- From internet-drafts@ietf.org Mon Oct 21 17:00:41 2013 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 91F7D11E86F5; Mon, 21 Oct 2013 17:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-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 wD0A5K6jcMoA; Mon, 21 Oct 2013 17:00:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F1F11E82D3; Mon, 21 Oct 2013 17:00:38 -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.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131022000038.32534.69890.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 17:00:38 -0700 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-11.txt 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: Tue, 22 Oct 2013 00:00:41 -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 : IPv6 Home Networking Architecture Principles Author(s) : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-11.txt Pages : 51 Date : 2013-10-21 Abstract: This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paul@cypherpunks.ca Mon Oct 21 11:16:22 2013 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 483DD11E844E; Mon, 21 Oct 2013 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 7Mc4+xYVjsCq; Mon, 21 Oct 2013 11:16:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 57BC211E8446; Mon, 21 Oct 2013 11:16:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d3Qyc6CNszDNC; Mon, 21 Oct 2013 14:16:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id YpVlsN1-MJTf; Mon, 21 Oct 2013 14:16:07 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Mon, 21 Oct 2013 14:16:07 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 97D92807CA; Mon, 21 Oct 2013 14:16:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 89F63805BD; Mon, 21 Oct 2013 14:16:07 -0400 (EDT) Date: Mon, 21 Oct 2013 14:16:07 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Daniel Migault In-Reply-To: Message-ID: References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Mailman-Approved-At: Tue, 22 Oct 2013 01:15:14 -0700 Cc: homenet@ietf.org, dnsop Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 21 Oct 2013 18:16:22 -0000 On Mon, 21 Oct 2013, Daniel Migault wrote: > Please find a draft that defines DHCP options to provision DNSSEC validators so DNSSEC > validation can always be performed. > > Feel free to make any comments. I would be happy to have f2f discussion during IETF88 to solve > this issue with a more complete document. I am a little worried to bring this into the DHCP layer. While the document makes statements about only accepting trust anchors when the DHCP server is "trusted", when thinking about CPE equipment, old handhelds, etc, there is no such trust relationship. (I'm also not very familiar with what a "trust relationship" is between a DHCP server and client?) I'm also a little nervous about using certificates to kickstart dnssec and time, especially because it just moves the problem to certificate validity times. When not under attack, it's much simpler to insecurely query for the root key and use that key for an initial time setting as well. For CPE devices, I think querying for the root key without dnssec to use as time and possible TA is something it could possibly prompt the user for. It would work without DHCP and not require new DHCP options. CPE devices could also insecurely query for the proper ICANN website and grab the trust anchor bundle (i.e. what unbound-anchor does) and use the certificate of ICANN. For enterprise devices, I would assume that an unfiltered internet connection is not available (firewalled, etc) so it might need something else. However, there is likely good reason to have trust in the LAN, and a time estimate could be obtained from the NTP server through DHCP (option 42 could provide an IP address for one entry, therefor removing the need for DNS to obtain NTP) I do see a need to transfer DNSSEC TA's once we see split-view DNS where at the very least the public view is signed and there is a "lie" for an internal only zone that needs to be believed. I am not sure how those should get authenticated though. I wouldn't want my device to accept a rogue trust anchor and a DNS forwarder to use and take over all my DNS. So I do think we need OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR. I'm less sure about OPTION_DNSSEC_CERT_TRUST_ANCHOR. OPTION_TIME seems like a good addition but I'm also afraid of this being used in combination with a (fixed) registrar/registry compromise to replay old DNSSEC signed records. It should only be honoured by devices that are known to be in a timless tate (eg if its 1970). A discussion would be very helpful to talk about the various security implications, and to ensure that we can keep the differences between DHCP and IKEv2 options for VPN as small as possible. Paul From jabley@hopcount.ca Mon Oct 21 11:27:20 2013 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 BB24411E8467 for ; Mon, 21 Oct 2013 11:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 AHfhZ3-H9N6A for ; Mon, 21 Oct 2013 11:27:20 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7658511E8220 for ; Mon, 21 Oct 2013 11:27:19 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id aq17so11943008iec.6 for ; Mon, 21 Oct 2013 11:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WFGaRYLhC+Rw7Rsr3U72CzI/JUcIf2f0LFXaSgz64zk=; b=N5awJ8evAodK4Rcf1mnRcwiiuVrFzY3045XH91ujL4vGndag/xULSZNaMYGezRLP6c BA6Vz7or6FxKamyPdgwUKcvYGE9DAcYQpi3b6nCjEzUZR3gyrqDTtnzRTkRIU8rufQnh yE6C45hyLoMhy2XHRYuy7RQsk8qSckBv+1tus= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=WFGaRYLhC+Rw7Rsr3U72CzI/JUcIf2f0LFXaSgz64zk=; b=B0USY1NeKNFyGACHNgai7FTKHcLGMorC0S3eEsDT7DhryubRL/Pqw1nsunkktOrjHb bxygYNMWamUUiYo1GGJnF8ZkhvnE4l2L9MmGa8smbCD6vNXbsJxourRFPNN8L0SJEpxt fTGSMohTWavRWdimg8X7pJuo3o0D537U5Wfy4xibYtlv9D2ulw2GvZIcs3DqkYDY/Tqd SipHp98N1tMLeYa61qFxpxi6n0ATKCZ2bKv47KYVAxudUsI5/MF38QP/paYTjGeXooyZ d/6U98vj9hooaVRCrCm0UhQg3hfzZNmc3cTvBrnScM0RX2JW0K18jZ+v+Bg4RA+d4Kjn iUWg== X-Gm-Message-State: ALoCoQm9mKoJoJJ0wOEaTBHzqALELgHozPkY/91iMOvmp37GuvvW6liAA/HZJPjei8GVkB3USONP X-Received: by 10.50.50.225 with SMTP id f1mr10630484igo.2.1382380038975; Mon, 21 Oct 2013 11:27:18 -0700 (PDT) Received: from [192.168.1.163] (CPEd85d4ca3c203-CM00222dd65b0d.cpe.net.cable.rogers.com. [99.250.3.202]) by mx.google.com with ESMTPSA id q6sm31635667igi.0.2013.10.21.11.27.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Oct 2013 11:27:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Joe Abley In-Reply-To: Date: Mon, 21 Oct 2013 14:27:20 -0400 Content-Transfer-Encoding: 7bit Message-Id: <829622C6-AE6A-45DC-B650-E7E2A5D9DC31@hopcount.ca> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> To: Paul Wouters X-Mailer: Apple Mail (2.1510) X-Mailman-Approved-At: Tue, 22 Oct 2013 01:15:15 -0700 Cc: homenet@ietf.org, dnsop , Daniel Migault Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 21 Oct 2013 18:27:21 -0000 On 2013-10-21, at 14:16, Paul Wouters wrote: > For CPE devices, I think querying for the root key without dnssec to > use as time and possible TA is something it could possibly prompt the > user for. It would work without DHCP and not require new DHCP options. > CPE devices could also insecurely query for the proper ICANN website and > grab the trust anchor bundle (i.e. what unbound-anchor does) and use the > certificate of ICANN. See also draft-jabley-dnsop-validator-bootstrap-00. Joe From fanf2@hermes.cam.ac.uk Tue Oct 22 02:42:18 2013 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 BEEA111E8184; Tue, 22 Oct 2013 02:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 hwTatXDmQzeu; Tue, 22 Oct 2013 02:42:17 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f32]) by ietfa.amsl.com (Postfix) with ESMTP id A8FCD11E8192; Tue, 22 Oct 2013 02:42:11 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:38857) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1VYYTY-0002LX-2X (Exim 4.80_167-5a66dd3) (return-path ); Tue, 22 Oct 2013 10:42:08 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VYYTY-0001y5-Ns (Exim 4.72) (return-path ); Tue, 22 Oct 2013 10:42:08 +0100 Date: Tue, 22 Oct 2013 10:42:08 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Paul Wouters In-Reply-To: Message-ID: References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch X-Mailman-Approved-At: Tue, 22 Oct 2013 02:43:13 -0700 Cc: homenet@ietf.org, dnsop , Daniel Migault Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 09:42:18 -0000 Paul Wouters wrote: > > I am a little worried to bring this into the DHCP layer. While the > document makes statements about only accepting trust anchors when > the DHCP server is "trusted", when thinking about CPE equipment, old > handhelds, etc, there is no such trust relationship. (I'm also not very > familiar with what a "trust relationship" is between a DHCP server and > client?) The draft talks vaguely about IPSEC, which immediately sets off my wishful thinking alarm bells and reminds me of 1990s security considerations sections. More specifically, how is the client supposed to set up a security association with the DHCP server when it doesn't have an IP address? This is supposed to help with bootstrapping, right? How can the client bootstrap its trust in the DHCP server in a way that is less likely to expire than the root trust anchor? Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From mglt.ietf@gmail.com Tue Oct 22 05:40:40 2013 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 A80AD11E8164; Tue, 22 Oct 2013 05:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 rKIlRE7R21My; Tue, 22 Oct 2013 05:40:37 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0762C21F936F; Tue, 22 Oct 2013 05:40:17 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id hm4so5525813wib.8 for ; Tue, 22 Oct 2013 05:40:17 -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=McQPXfHj4roulj2aRbsY7+H8tJ8NpDgp2Uxj2yb6Ij0=; b=LCyZKEobAqD1E9Ts/nDziOIcgw8kuvhM7ywMhYbOjyMx/846CMfo51fQH0p63ensku aCiewKEg1TzeqqxCvNfLBmzkVkhNWK/kuxp4EUgembbk1/Y5uCTH5eQmQcUtFJ64Ldsk +f87ae3tR+RCmNJ8d25WVCtgyNbbEBgDBdaQ6jx9TROM8q5RGychPjFHciKviqBSFYGE XkA3e5ReC0UR6vtwPjz1CADGGchujp1cWpMCPltLZwJSEnNdRWV3HEbekFcaik2zVNuD x7r24jzEmnHT/YmAIWgXMgxY+PXyzwZpjVIAMONkvUobvzxoIGMPcx6HLK5Zq5KzS3yJ hbDQ== MIME-Version: 1.0 X-Received: by 10.180.9.134 with SMTP id z6mr14483406wia.9.1382445616906; Tue, 22 Oct 2013 05:40:16 -0700 (PDT) Received: by 10.194.41.138 with HTTP; Tue, 22 Oct 2013 05:40:16 -0700 (PDT) In-Reply-To: References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> Date: Tue, 22 Oct 2013 14:40:16 +0200 Message-ID: From: Daniel Migault To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11c2b1beeaca2d04e953b35f Cc: "homenet@ietf.org" , dnsop Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 12:40:41 -0000 --001a11c2b1beeaca2d04e953b35f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Paul, Thanks for your comments. I also share your opinions. I add my comment in the body part. On Mon, Oct 21, 2013 at 8:16 PM, Paul Wouters wrote: > On Mon, 21 Oct 2013, Daniel Migault wrote: > > Please find a draft that defines DHCP options to provision DNSSEC >> validators so DNSSEC >> validation can always be performed. >> >> Feel free to make any comments. I would be happy to have f2f discussion >> during IETF88 to solve >> this issue with a more complete document. >> > > I am a little worried to bring this into the DHCP layer. While the > document makes statements about only accepting trust anchors when > the DHCP server is "trusted", when thinking about CPE equipment, old > handhelds, etc, there is no such trust relationship. (I'm also not very > familiar with what a "trust relationship" is between a DHCP server and > client?) > By trusted relationship, I wanted to clarify that authenticating the DHCP Server is not sufficient. The Client MUST trust the DHCP Server. More specifically, when you are in a corporate network you assume you are in a trusted network, so you trust information from your DHCP Server. On the contrary, in a cyber caf=E9, even if you authenticate the DHCP Server as th= e one of the cybercaf=E9, you do not necessarily trust it to the point to accept crucial information. Practically, this means that these Options must be 1) considered cautiously by the DHCP Client and 2) "only" when they are provided by trusted networks, that is mostly the corporate network, or the DSL line at home. One reason I posted the draft in the homenet WG instead of DNSOP is that the DHCP Options may not apply to devices connected to different untrusted networks. More specifically, a mobile WiFi device in your pocket that wakes up every months/years may not use these options unless they are at home. > I'm also a little nervous about using certificates to kickstart dnssec an= d > time, especially because it just moves the problem to certificate validit= y > times. When not under attack, it's much simpler to insecurely query for > the root key and use that key for an initial time setting as well. > > Thanks, this point has not been addressed in the draft. The reason to use certificate is that ISP will not deploy DNSSEC in DSL boxes, if they have no way to push securely the valid KSKs. I saw certificate as one way to provide authenticated information, and this information can be provided over untrusted/unsecured/unauthenticated channels. True that if the device is desynchronized, signature checks cannot be performed neither for DNSSEC nor for certificates. To use certificates the device needs a valid CA and a proper time. If the device is desynchronize, it should use the time value provided by the DHCP Time Option. This only works if provided by a trusted DHCP Server. As a result, for a desynchronized device it may not provide any advantages, and sending the KSK insecurely is much simpler. The question is then for desynchronized devices, does it worth protecting the KSKs with certificate, if one parameter (the time) is not authenticated. > For CPE devices, I think querying for the root key without dnssec to > use as time and possible TA is something it could possibly prompt the > user for. It would work without DHCP and not require new DHCP options. > CPE devices could also insecurely query for the proper ICANN website and > grab the trust anchor bundle (i.e. what unbound-anchor does) and use the > certificate of ICANN. > > That is definitely one way to get the root key. What we propose by providing the certificate with the KSK is very similar. The only difference is that the CA may not be only the one the ICANN but can also be the one of third parties like the ISP. In both cases, CA have to be provisioned in the devices, and the device is expected to perform signature checks, so we have the same issues as above. The big issues I see are: 1) It only applies to the Root Key. Which means the CPE cannot recover for example from TLD that had an emergency roll over. In addition the Root Key is probably the one that is mostly unlikely to have issues with emergency roll over. Most of these issues are expected to happen with other subzones. 2) If does not provide the ISP to mitigate a key roll over issue performed on the Internet. If a problem occurs, the end user will not call ICANN. > For enterprise devices, I would assume that an unfiltered internet > connection is not available (firewalled, etc) so it might need something > else. However, there is likely good reason to have trust in the LAN, > and a time estimate could be obtained from the NTP server through DHCP > (option 42 could provide an IP address for one entry, therefor removing > the need for DNS to obtain NTP) > > Good point, providing IP addresses makes DHCP Time Option unnecessary. Difference between ntp client vs DHCP Options is that using ntp client adds round trip, and requires the ntp client to be installed. If that does not cause any problems, then we should use option 42. > I do see a need to transfer DNSSEC TA's once we see split-view DNS where > at the very least the public view is signed and there is a "lie" for an > internal only zone that needs to be believed. I am not sure how those > should get authenticated though. I wouldn't want my device to accept a > rogue trust anchor and a DNS forwarder to use and take over all my DNS. > > So I do think we need OPTION_DNSSEC_KSK_RR_TRUST_**ANCHOR. I'm less sure > about OPTION_DNSSEC_CERT_TRUST_**ANCHOR. > > I see your point with split-views. I should add this to the draft. I agree that CERT may not be very useful in LAN or trusted environment. On the other hand it would really help that ISPs can provision the devices with KSKs and authenticate them. In addition I would like also a standard way to store KSK in certificate. The format adopted for the Root Zone seems very specific to the root zone. > > OPTION_TIME seems like a good addition but I'm also afraid of this being > used in combination with a (fixed) registrar/registry compromise to > replay old DNSSEC signed records. It should only be honoured by devices > that are known to be in a timless tate (eg if its 1970). > > I am not sure we should consider these devices, maybe sensors or IoT have different ideas on supporting ntp client. I feel using NTP is much better. > A discussion would be very helpful to talk about the various security > implications, and to ensure that we can keep the differences between > DHCP and IKEv2 options for VPN as small as possible. Definitely. I have not mentioned VPN use cases, but we should consider this case with more attention. Wen you say "as small as possible" do you mean that we should also define new CP attributes? I am sure I must misunderstood something, but I expect the VPN client to get the DHCP Server address from the security gateway(INTERNAL_*_DHCP) and from that the client sends the ORO to the DHCP Sever. > > > Paul > Daniel --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --001a11c2b1beeaca2d04e953b35f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thanks for your comments. I al= so share your opinions. I add my comment in the body part.


On Mon, Oct 21, = 2013 at 8:16 PM, Paul Wouters <paul@cypherpunks.ca> wrote:=
On Mon, 21 Oct 2013, Danie= l Migault wrote:

Please find a draft that defines DHCP options to provision DNSSEC validator= s so DNSSEC
validation can always be performed.

Feel free to make any comments. I would be happy to have f2f discussion dur= ing IETF88 to solve
this issue with a more complete document.

I am a little worried to bring this into the DHCP layer. While the
document makes statements about only accepting trust anchors when
the DHCP server is "trusted", when thinking about CPE equipment, = old
handhelds, etc, there is no such trust relationship. (I'm also not very=
familiar with what a "trust relationship" is between a DHCP serve= r and
client?)

By trusted relationship, I wan= ted to clarify that authenticating the DHCP Server is not sufficient. The C= lient MUST trust the DHCP Server. More specifically, when you are in a corp= orate network you assume you are in a trusted network, so you trust informa= tion from your DHCP Server. On the contrary, in a cyber caf=E9, even if you= authenticate the DHCP Server as the one of the cybercaf=E9, you do not nec= essarily trust it to the point to accept crucial information.

Practically, this means that these Options must be 1) consid= ered cautiously by the DHCP Client and 2) "only" when they are pr= ovided by trusted networks, that is mostly the corporate network, or the DS= L line at home.=A0

One reason I posted the draft in the homenet WG instead of D= NSOP is that the DHCP Options may not apply to devices connected to differe= nt untrusted networks. More specifically, a mobile WiFi device in your pock= et that wakes up every months/years may not use these options unless they a= re at home.
=A0
I'm also a little nervous about using certificates to kickstart dnssec = and
time, especially because it just moves the problem to certificate validity<= br> times. When not under attack, it's much simpler to insecurely query for=
the root key and use that key for an initial time setting as well.

Thanks, this point has not been addressed in the draf= t.

The reason to use certificate is that ISP will not deploy DNSSEC = in DSL boxes, if they have no way to push securely the valid KSKs.=A0 I saw= certificate as one way to provide authenticated information, and this info= rmation can be provided over untrusted/unsecured/unauthenticated channels. =
True that if the device is desynchronized, signature checks=A0 c= annot be performed neither for DNSSEC nor for certificates. To use certific= ates the device needs a valid CA and a proper time. If the device is desync= hronize, it should use the time value provided by the DHCP Time Option. Thi= s only works if provided by a trusted DHCP Server. As a result, for a desyn= chronized device it may not provide any advantages, and sending the KSK ins= ecurely is much simpler.

The question is then for desynchronized devices, does it wor= th protecting the KSKs with certificate, if one parameter (the time) is not= authenticated.=A0=A0

=A0
For CPE devices, I think querying for the root key without dnssec to
use as time and possible TA is something it could possibly prompt the
user for. It would work without DHCP and not require new DHCP options.
CPE devices could also insecurely query for the proper ICANN website and grab the trust anchor bundle (i.e. what unbound-anchor does) and use the certificate of ICANN.


That is definitely one way to get the root key. W= hat we propose by providing the certificate with the KSK is very similar. T= he only difference is that the CA may not be only the one the ICANN but can= also be the one of third parties like the ISP. In both cases, CA have to b= e provisioned in the devices, and the device is expected to perform signatu= re checks, so we have the same issues as above.
The big issues I see are:
=A0=A0=A0 1) It only app= lies to the Root Key. Which means the CPE cannot recover for example from T= LD that had an emergency roll over. In addition the Root Key is probably th= e one that is mostly unlikely to have issues with emergency roll over. Most= of these issues are expected to happen with other subzones.
=A0 =A0 2) If does not provide the ISP to mitigate a key roll ov= er issue performed on the Internet. If a problem occurs, the end user will = not call ICANN.
=A0
For enterprise devices, I would assume that an unfiltered internet
connection is not available (firewalled, etc) so it might need something else. However, there is likely good reason to have trust in the LAN,
and a time estimate could be obtained from the NTP server through DHCP
(option 42 could provide an IP address for one entry, therefor removing
the need for DNS to obtain NTP)


Good point, providing IP addresses makes DHCP Tim= e Option unnecessary.
Difference between ntp client vs DHCP = Options is that using ntp client adds round trip, and requires the ntp clie= nt to be installed. If that does not cause any problems, then we should use= option 42.
=A0
I do see a need to transfer DNSSEC TA's once we see split-view DNS wher= e
at the very least the public view is signed and there is a "lie" = for an
internal only zone that needs to be believed. I am not sure how those
should get authenticated though. I wouldn't want my device to accept a<= br> rogue trust anchor and a DNS forwarder to use and take over all my DNS.

So I do think we need OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR. I'm les= s sure
about OPTION_DNSSEC_CERT_TRUST_ANCHOR.


I see your point with split-views. I s= hould add this to the draft. I agree that CERT may not be very useful in LA= N or trusted environment. On the other hand it would really help that ISPs = can provision the devices with KSKs and authenticate them. In addition I wo= uld like also a standard way to store KSK in certificate. The format adopte= d for the Root Zone seems very specific to the root zone.
=A0
OPTION_TIME seems like a good addition but I'm also afraid of this bein= g
used in combination with a (fixed) registrar/registry compromise to
replay old DNSSEC signed records. It should only be honoured by devices
that are known to be in a timless tate (eg if its 1970).

I am not sure we should consider these devices, maybe= sensors or IoT have different ideas on supporting ntp client. I feel using= NTP is much better.
=A0
A discussion would be very helpful to talk about the various security
implications, and to ensure that we can keep the differences between
DHCP and IKEv2 options for VPN as small as possible.

<= /div>
Definitely. I have not mentioned VPN use cases, but we should con= sider this case with more attention. Wen you say "as small as possible= " do you mean that we should also define new CP attributes? I am sure = I must misunderstood something, but I expect the VPN client to get the DHCP= Server address from the security gateway(INTERNAL_*_DHCP) and from that th= e client sends the ORO to the DHCP Sever.
=A0=A0


Paul

Danie= l

--
Daniel Migau= lt
Orange Labs -- Security
+33 6 70 72 69 58
--001a11c2b1beeaca2d04e953b35f-- From mglt.ietf@gmail.com Tue Oct 22 05:49:41 2013 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 9B6EF11E819F; Tue, 22 Oct 2013 05:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 0bqh5aBsRxFg; Tue, 22 Oct 2013 05:49:41 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id E2E6811E8164; Tue, 22 Oct 2013 05:49:32 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id x55so7947368wes.22 for ; Tue, 22 Oct 2013 05:49:32 -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=PbouCr0hn0WeJuHTjuqCZyjJLinKrqsaFcPrrP2Dnno=; b=jPnCMwzvyDfN4DtpmusU6wqzUbLh7nsgVTkcB8lweYkIS7MCLHEf158F18+WQmST2j qGzsMUtBfXqh4GQJkrOOrDRMg35Xm1VLX+hb/Tye2JWsW0wtcpw0BxmLQAU5cy1TsCvd jGhzDdGBz0MWYhtPra81+mk6S1PnFTU7ISc1jYfa9AYGBmI3Sf+0NZixYkmzCjTlTInb 6MAgcSn/U5wpM1WWhEGbPoGFKKdwIF/PwfLP/VUewkhmpDbPqJILpPTL9Vr7eUHUNpee EPdD04M4DX4aqn34mltaFi2v9b1S24Kf59AwuuxjmIoHxxEAFtHURFIN1LIirJJ++gaA Zp4A== MIME-Version: 1.0 X-Received: by 10.194.122.168 with SMTP id lt8mr484049wjb.76.1382446172055; Tue, 22 Oct 2013 05:49:32 -0700 (PDT) Received: by 10.194.41.138 with HTTP; Tue, 22 Oct 2013 05:49:31 -0700 (PDT) In-Reply-To: <829622C6-AE6A-45DC-B650-E7E2A5D9DC31@hopcount.ca> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <829622C6-AE6A-45DC-B650-E7E2A5D9DC31@hopcount.ca> Date: Tue, 22 Oct 2013 14:49:31 +0200 Message-ID: From: Daniel Migault To: Joe Abley Content-Type: multipart/alternative; boundary=089e011777af01ac7104e953d5a5 Cc: "homenet@ietf.org" , Paul Wouters , dnsop Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 12:49:41 -0000 --089e011777af01ac7104e953d5a5 Content-Type: text/plain; charset=ISO-8859-1 Hi Joe, Thank you for your comment. draft-jabley-dnsop-validator- bootstrap-00 is mentioned in the draft. We would like to extend this to other non root KSKs. Otherwise we do not see contradictions with what is mentioned in draft-jabley-dnsop-validator-bootstrap-00. As mentionned "[...] and believe the principle described in these documents [ draft-jabley-dnsop-validator-bootstrap-00, and I-D.jabley-dnssec-trust-anchor] SHOULD be applied by the validators". Best Regards, Daniel On Mon, Oct 21, 2013 at 8:27 PM, Joe Abley wrote: > > On 2013-10-21, at 14:16, Paul Wouters wrote: > > > For CPE devices, I think querying for the root key without dnssec to > > use as time and possible TA is something it could possibly prompt the > > user for. It would work without DHCP and not require new DHCP options. > > CPE devices could also insecurely query for the proper ICANN website and > > grab the trust anchor bundle (i.e. what unbound-anchor does) and use the > > certificate of ICANN. > > See also draft-jabley-dnsop-validator-bootstrap-00. > > > Joe > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --089e011777af01ac7104e953d5a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joe,

Thank you for your comment. dra= ft-jabley-dnsop-validator-
bootstrap-00 is mentioned in the= draft. We would like to extend this to other non root KSKs. Otherwise we d= o not see contradictions with what is mentioned in draft-jabley-dnsop-valid= ator-bootstrap-00.=A0
As mentionned "[...] and believe the principle described in these docu= ments [ draft-jabley-dnsop-validator-bootstrap-00, and I-D.jabley-dnssec-tr= ust-anchor] SHOULD be applied by the validators".

Best Regards,
Daniel


On Mon, Oct 21, 2013 at= 8:27 PM, Joe Abley <jabley@hopcount.ca> wrote:

On 2013-10-21, at 14:16, Paul Wouters <paul@cypherpunks.ca> wrote:

> For CPE devices, I think querying for the root key without dnssec to > use as time and possible TA is something it could possibly prompt the<= br> > user for. It would work without DHCP and not require new DHCP options.=
> CPE devices could also insecurely query for the proper ICANN website a= nd
> grab the trust anchor bundle (i.e. what unbound-anchor does) and use t= he
> certificate of ICANN.

See also draft-jabley-dnsop-validator-bootstrap-00.


Joe



--
Daniel Mi= gault
Orange Labs -- Security
+33 6 70 72 69 58
--089e011777af01ac7104e953d5a5-- From mglt.ietf@gmail.com Tue Oct 22 06:37:27 2013 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 243F111E83B0; Tue, 22 Oct 2013 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 IMhDmawVxOxO; Tue, 22 Oct 2013 06:37:03 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC8D11E81A0; Tue, 22 Oct 2013 06:36:40 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id x55so8069468wes.36 for ; Tue, 22 Oct 2013 06:36:33 -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=bic+cGUDqgfxaz3w5ErYrT5EZoScbRDRVzarnhzu07c=; b=mkEQGYWJNnol267b0w2sXhn86fStRIwnBBiA8L2+YjP8e4mTb7FW/ZTWGO0o6a0PWX nlNLgqS8pYiUsVy4SSDv7FDyaM/MOB8sEGFW1cvrTXsc+bSFOn4d8wSXNcbQK2j4Avg1 DQBk19M5r6X6G3wByTmZ2i8PAtfPBM1PreKskO2kH3dm9AVSi+nWK89mVSOLss7acJub +Jr4eVyn+4NXxm1owEm2zemqJ1fxSYL3BYd+yuKbcY6neAV7jtT42lVf3JhxuO9F45K5 jam/6jid+BhZcnc8GRx+IAIED+xczp4c8AhbaSh5Xn4yaov665Py2n/rf0q75NLbFZzU pxjg== MIME-Version: 1.0 X-Received: by 10.194.200.100 with SMTP id jr4mr9911977wjc.37.1382448993753; Tue, 22 Oct 2013 06:36:33 -0700 (PDT) Received: by 10.194.41.138 with HTTP; Tue, 22 Oct 2013 06:36:33 -0700 (PDT) In-Reply-To: References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> Date: Tue, 22 Oct 2013 15:36:33 +0200 Message-ID: From: Daniel Migault To: Tony Finch Content-Type: multipart/alternative; boundary=047d7bb03e1e31628504e9547d74 Cc: "homenet@ietf.org" , Paul Wouters , dnsop Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 13:37:47 -0000 --047d7bb03e1e31628504e9547d74 Content-Type: text/plain; charset=ISO-8859-1 Hi Tony, Thank you for your comment. Maybe I should clarify this: Authentication of DHCP messages between the DHCP Client and the DHCP Server is accomplished through the use of the Authentication option. IPsec can be used between DHCP Relays and DHCP Servers. We also need to clarify how IPsec and DHCP interact in the case of remote VPN clients. You are right saying root KSK is probably better managed than any other KSKs as well as other trusted communications. But 1) we are not only concerned by the root KSK. The root KSK is crucial for DNSSEC, however, it is not the only cause of failures. Other KSKs may also provide DNSSEC validation failures. 2) we have no control on KSK operations. As I mentioned earlier, in the case of the root zone end users whose DNSSEC validation fails will not call IANA, but our hot lines. The key difference between the DHCP bootstrap and DNSSEC boostrap is that ISPs have no influence on DNSSEC key roll overs, whereas we manage DHCP Server bootstrap. Best Regards, Daniel On Tue, Oct 22, 2013 at 11:42 AM, Tony Finch wrote: > Paul Wouters wrote: > > > > I am a little worried to bring this into the DHCP layer. While the > > document makes statements about only accepting trust anchors when > > the DHCP server is "trusted", when thinking about CPE equipment, old > > handhelds, etc, there is no such trust relationship. (I'm also not very > > familiar with what a "trust relationship" is between a DHCP server and > > client?) > > The draft talks vaguely about IPSEC, which immediately sets off my wishful > thinking alarm bells and reminds me of 1990s security considerations > sections. More specifically, how is the client supposed to set up a > security association with the DHCP server when it doesn't have an IP > address? This is supposed to help with bootstrapping, right? How can the > client bootstrap its trust in the DHCP server in a way that is less likely > to expire than the root trust anchor? > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at > first. > Rough, becoming slight or moderate. Showers, rain at first. Moderate or > good, > occasionally poor at first. > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bb03e1e31628504e9547d74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tony,

Thank you for y= our comment.

Maybe I should clarify this: Authentication of DHCP me= ssages between the DHCP Client and the DHCP Server is accomplished through = the use of the Authentication option. IPsec can be used between DHCP Relays= and DHCP Servers. We also need to clarify how IPsec and DHCP interact in t= he case of remote VPN clients.

You are right saying root KSK is probably better managed than any= other KSKs as well as other trusted communications. But 1) we are not only= concerned by the root KSK. The root KSK is crucial for DNSSEC, however, it is not the only cause of=20 failures. Other KSKs may also provide DNSSEC validation failures. 2) we hav= e no control on KSK operations.

As I mentioned earlier, in the case = of the root zone end users whose=20 DNSSEC validation fails will not call IANA, but our hot lines.
The key = difference between the DHCP bootstrap and DNSSEC boostrap is that ISPs have= no influence on DNSSEC key roll overs, whereas we manage DHCP Server boots= trap.
=A0

Best Regards,
Daniel =A0



On Tue, Oct 22, 2013 at 11:42 A= M, Tony Finch <dot@dotat.at> wrote:
Paul Wouters <paul@cypherpunks.ca> wrote:
>
> I am a little worried to bring this into the DHCP layer. While the
> document makes statements about only accepting trust anchors when
> the DHCP server is "trusted", when thinking about CPE equipm= ent, old
> handhelds, etc, there is no such trust relationship. (I'm also not= very
> familiar with what a "trust relationship" is between a DHCP = server and
> client?)

The draft talks vaguely about IPSEC, which immediately sets off my wi= shful
thinking alarm bells and reminds me of 1990s security considerations
sections. More specifically, how is the client supposed to set up a
security association with the DHCP server when it doesn't have an IP address? This is supposed to help with bootstrapping, right? How can the client bootstrap its trust in the DHCP server in a way that is less likely<= br> to expire than the root trust anchor?

Tony.
--
f.anthony.n.finch =A0<dot@dotat.at&g= t; =A0http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first= .
Rough, becoming slight or moderate. Showers, rain at first. Moderate or goo= d,
occasionally poor at first.



--
Daniel Mi= gault
Orange Labs -- Security
+33 6 70 72 69 58
--047d7bb03e1e31628504e9547d74-- From mellon@fugue.com Tue Oct 22 06:51:27 2013 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 AE76511E83A3; Tue, 22 Oct 2013 06:51:27 -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 qME7uveXlNTd; Tue, 22 Oct 2013 06:51:21 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1001C11E81BD; Tue, 22 Oct 2013 06:51:18 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id EE8B5238038C; Tue, 22 Oct 2013 09:51:16 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ted Lemon In-Reply-To: Date: Tue, 22 Oct 2013 09:51:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> To: Daniel Migault X-Mailer: Apple Mail (2.1510) Cc: "homenet@ietf.org" , Paul Wouters , dnsop Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 13:51:27 -0000 On Oct 22, 2013, at 8:40 AM, Daniel Migault wrote: > By trusted relationship, I wanted to clarify that authenticating the = DHCP Server is not sufficient. The Client MUST trust the DHCP Server. = More specifically, when you are in a corporate network you assume you = are in a trusted network, so you trust information from your DHCP = Server. On the contrary, in a cyber caf=E9, even if you authenticate the = DHCP Server as the one of the cybercaf=E9, you do not necessarily trust = it to the point to accept crucial information.=20 But this is absolutely crucial. How do you know that you are on a = trusted network? The document doesn't say. DHCP is supposed to be = zero-touch. If we have to set up a DHCP security association in order = to be able to trust the DHCP server to tell us what the DNSSEC trust = anchors are, why not skip that step and install the trust anchors? From dominique.gue@orange.com Tue Oct 22 08:04:42 2013 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 B3FDF11E84A3 for ; Tue, 22 Oct 2013 08:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 pI461Qel816M for ; Tue, 22 Oct 2013 08:04:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 76DB111E83E7 for ; Tue, 22 Oct 2013 08:04:37 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B214F3B4985; Tue, 22 Oct 2013 17:04:36 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 944134C0E1; Tue, 22 Oct 2013 17:04:36 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0347.000; Tue, 22 Oct 2013 17:04:36 +0200 From: To: Daniel Migault , "homenet@ietf.org" Thread-Topic: [homenet] Fwd: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-03.txt Thread-Index: AQHOzc0+jhZhzO1lqUO1boDx5if89ZoAzYmQ Date: Tue, 22 Oct 2013 15:04:36 +0000 Message-ID: <20409_1382454276_52669404_20409_12626_1_25E5281E128EF4409E832EDD84CFD6A710325B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20131020194108.22740.11430.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_25E5281E128EF4409E832EDD84CFD6A710325BPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.10.22.91515 Subject: Re: [homenet] Fwd: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-03.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, 22 Oct 2013 15:04:42 -0000 --_000_25E5281E128EF4409E832EDD84CFD6A710325BPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Daniel, I have one remark regarding 5.2 paragraph and EXPIRE parameter. It seems to me that the value by default (i.e.: 42 days) is too large. Actu= ally, if we take the case where the CPE is unavailable for a long time (e.g= .: CPE switched-off), the association fqdn1/IP1 will stay valid in the Publ= ic authoritative masters. The IP Prefix Allocation module (e.g.: DHCP Serve= r) could re-allocate the prefix to another CPE. Therefore host behind this = CPE could be assigned with same IP Address (i.e.:IP1). In the Public author= itative masters, we could then have associations for fqdn1/IP1 and fqdn2/IP= 1. As a consequence, the resolution of fqdn1 will point to the wrong CPE. I would prefer to decrease the value of EXPIRE (e.g.: 1 or 7 days maximum) = depending of operator's policies for re-attribution of IP Prefix. Dominique De : homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] De la part = de Daniel Migault Envoy=E9 : dimanche 20 octobre 2013 21:48 =C0 : homenet@ietf.org Objet : [homenet] Fwd: New Version Notification for draft-mglt-homenet-fron= t-end-naming-delegation-03.txt Hi, Please find our draft presenting the "IPv6 Home Network Naming Delegation". URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-namin= g-delegation-03.txt Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-de= legation-03 Feel free to make comments! Best Regards, Daniel ---------- Forwarded message ---------- From: > Date: Sun, Oct 20, 2013 at 9:41 PM Subject: New Version Notification for draft-mglt-homenet-front-end-naming-d= elegation-03.txt To: Wouter Cloetens >, Chris Griffiths >, Daniel Migault >, R= alf Weber > A new version of I-D, draft-mglt-homenet-front-end-naming-delegation-03.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-homenet-front-end-naming-delegation Revision: 03 Title: IPv6 Home Network Naming Delegation Creation date: 2013-10-20 Group: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-mglt-homenet-fro= nt-end-naming-delegation-03.txt Status: http://datatracker.ietf.org/doc/draft-mglt-homenet-front-e= nd-naming-delegation Htmlized: http://tools.ietf.org/html/draft-mglt-homenet-front-end-na= ming-delegation-03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-homenet-fron= t-end-naming-delegation-03 Abstract: CPEs are designed to provide IP connectivity to home networks. Most CPEs assigns IP addresses to the nodes of the home network which makes it a good candidate for hosting the naming service. With IPv6, the naming service makes nodes reachable from the home network as well as from the Internet. However, CPEs have not been designed to host such a naming service exposed on the Internet. This MAY expose the CPEs to resource exhaustion which would make the home network unreachable, and most probably would also affect the home network inner communications. In addition, DNSSEC management and configuration may not be well understood or mastered by regular end users. Misconfiguration MAY also results in naming service disruption, thus these end users MAY prefer to rely on third party naming providers. This document describes a homenet naming architecture where the CPEs manage the DNS zone associates to its home network, and outsource both DNSSEC management and naming service on the Internet to a third party designated as the Public Authoritative Servers. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_25E5281E128EF4409E832EDD84CFD6A710325BPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Daniel,

I have one= remark regarding 5.2 paragraph and EXPIRE parameter.

It seems t= o me that the value by default (i.e.: 42 days) is too large. Actually, if w= e take the case where the CPE is unavailable for a long time (e.g.: CPE switched-off), the association fqdn1/IP1 will stay valid in the= Public authoritative masters. The IP Prefix Allocation module (e.g.: DHCP = Server) could re-allocate the prefix to another CPE. Therefore host behind = this CPE could be assigned with same IP Address (i.e.:IP1). In the Public authoritative masters, we could = then have associations for fqdn1/IP1 and fqdn2/IP1. As a consequence, the r= esolution of fqdn1 will point to the wrong CPE.

I would pr= efer to decrease the value of EXPIRE (e.g.: 1 or 7 days maximum) depending = of operator’s policies for re-attribution of IP Prefix.

 = ;

Dominique

 <= /p>

De : home= net-bounces@ietf.org [mailto:homenet-bounces@ietf.org] De la part de Daniel Migault
Envoy=E9 : dimanche 20 octobre 2013 21:48
=C0 : homenet@ietf.org
Objet : [homenet] Fwd: New Version Notification for draft-mglt-= homenet-front-end-naming-delegation-03.txt

 

Hi, 

 

Please find our draft presenting the "IPv6 Home= Network Naming Delegation". 

 

 

Feel free to make comments!

 

Best Regards, 

 

Daniel

---------- Forwarded = message ----------
From: <internet-drafts@ietf.= org>
Date: Sun, Oct 20, 2013 at 9:41 PM
Subject: New Version Notification for draft-mglt-homenet-front-end-naming-d= elegation-03.txt
To: Wouter Cloetens <w= outer.cloetens@softathome.com>, Chris Griffiths <cgriffiths@dyn.com>, Daniel Migault <mglt.ietf@gmail.com>, Ralf Weber <ralf.weber@nominu= m.com>



A new version of I-D, draft-mglt-homenet-front-end-naming-delegation-03.txt=
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename:        draft-mglt-homenet-front-end-naming-de= legation
Revision:        03
Title:           IPv6 Home Network Naming Delegati= on
Creation date:   2013-10-20
Group:           Individual Submission
Number of pages: 19
URL:             http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-del= egation-03.txt
Status:          http://datatracker.ietf.org/doc/draft-mglt-homenet-front-end-naming-delega= tion
Htmlized:        http:/= /tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation-03<= br> Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-homenet-front-end= -naming-delegation-03

Abstract:
   CPEs are designed to provide IP connectivity to home networks.=  Most
   CPEs assigns IP addresses to the nodes of the home network whi= ch
   makes it a good candidate for hosting the naming service. &nbs= p;With IPv6,
   the naming service makes nodes reachable from the home network= as
   well as from the Internet.

   However, CPEs have not been designed to host such a naming ser= vice
   exposed on the Internet.  This MAY expose the CPEs to res= ource
   exhaustion which would make the home network unreachable, and = most
   probably would also affect the home network inner communicatio= ns.

   In addition, DNSSEC management and configuration may not be we= ll
   understood or mastered by regular end users.  Misconfigur= ation MAY
   also results in naming service disruption, thus these end user= s MAY
   prefer to rely on third party naming providers.

   This document describes a homenet naming architecture where th= e CPEs
   manage the DNS zone associates to its home network, and outsou= rce
   both DNSSEC management and naming service on the Internet to a= third
   party designated as the Public Authoritative Servers.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



 

--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_25E5281E128EF4409E832EDD84CFD6A710325BPEXCVZYM13corpora_-- From mike@mtcc.com Tue Oct 22 08:30:02 2013 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 9C75E11E83EC for ; Tue, 22 Oct 2013 08:30:02 -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=-2.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 yHmPszcjIg54 for ; Tue, 22 Oct 2013 08:29:57 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 24CBD11E84B4 for ; Tue, 22 Oct 2013 08:29:56 -0700 (PDT) Received: from takifugu.mtcc.com (mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id r9MFTtNk028461 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 22 Oct 2013 08:29:55 -0700 Message-ID: <526699F3.20908@mtcc.com> Date: Tue, 22 Oct 2013 08:29:55 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: homenet@ietf.org References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> In-Reply-To: <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 15:30:02 -0000 On 10/22/2013 06:51 AM, Ted Lemon wrote: > On Oct 22, 2013, at 8:40 AM, Daniel Migault wrote: >> By trusted relationship, I wanted to clarify that authenticating the DHCP Server is not sufficient. The Client MUST trust the DHCP Server. More specifically, when you are in a corporate network you assume you are in a trusted network, so you trust information from your DHCP Server. On the contrary, in a cyber café, even if you authenticate the DHCP Server as the one of the cybercafé, you do not necessarily trust it to the point to accept crucial information. > But this is absolutely crucial. How do you know that you are on a trusted network? The document doesn't say. DHCP is supposed to be zero-touch. If we have to set up a DHCP security association in order to be able to trust the DHCP server to tell us what the DNSSEC trust anchors are, why not skip that step and install the trust anchors? > Since this is homenet, oughtn't we be thinking in terms of getting configuration information from things that we believe we ought to always trust, like, oh say, a server on our home network? Regardless of our current attachment point(s)? There's always been a friction between the discovery function of dhcp and the configuration function. Today's roaming -- and the complete inability for us to know what we're attached to at any given time -- brings that into stark relief. Mike From paul@cypherpunks.ca Tue Oct 22 08:57:48 2013 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 736F511E82D2; Tue, 22 Oct 2013 08:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 vnRgn16X19rk; Tue, 22 Oct 2013 08:57:43 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 28CF411E81BE; Tue, 22 Oct 2013 08:57:38 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d3zrG4CwSz1Kk; Tue, 22 Oct 2013 11:57:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id L2Zj1vP9bgz0; Tue, 22 Oct 2013 11:57:33 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Tue, 22 Oct 2013 11:57:33 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 52EA8807CA; Tue, 22 Oct 2013 11:57:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4061D805BD; Tue, 22 Oct 2013 11:57:34 -0400 (EDT) Date: Tue, 22 Oct 2013 11:57:34 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Daniel Migault In-Reply-To: Message-ID: References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: "homenet@ietf.org" , dnsop Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 15:57:48 -0000 On Tue, 22 Oct 2013, Daniel Migault wrote: > By trusted relationship, I wanted to clarify that authenticating the DHCP Server is not sufficient. The Client > MUST trust the DHCP Server. More specifically, when you are in a corporate network you assume you are in a > trusted network, so you trust information from your DHCP Server. On the contrary, in a cyber café, even if you > authenticate the DHCP Server as the one of the cybercafé, you do not necessarily trust it to the point to accept > crucial information. I'm not sure I agree. When I am in a corporate network, I don't want it to give me trust anchors for nohats.ca regardless. It does not matter to me whether it is a large enterprise or a starbucks wifi. I think at most, it should be allowed to give me a trust anchor for the domain option it gives me, meaning to re-arrange trust for the LAN I just entered. Although that moves the security issue to when I should or should not accept a domain option from DHCP. I still don't want starbucks to give me a nohats.ca search domain and modify its trust anchor. > Practically, this means that these Options must be 1) considered cautiously by the DHCP Client and 2) "only" when > they are provided by trusted networks, that is mostly the corporate network, or the DSL line at home.  That would require marking networks as "trusted" in your network manager program by the end user. > The reason to use certificate is that ISP will not deploy DNSSEC in DSL boxes, if they have no way to push > securely the valid KSKs.  I _really_ don't want ISPs pushing trust anchors. Enterprise LAN setups, home networks, sure. But not random hotspots or random ISPs. DNSSEC deployment _protects_ me from bad ISPs (like Rogers Canada) who mangle the DNS for me with "sitefinder" like ads. There have been ISPs with poisoned caches or malicious employees trying to get adviews. ISPs can and should provide a DNS caching resolver I can use, but they cannot be trusted to set any DNSSEC trust anchor. > I saw certificate as one way to provide authenticated information, and this information > can be provided over untrusted/unsecured/unauthenticated channels. > True that if the device is desynchronized, signature checks  cannot be performed neither for DNSSEC nor for > certificates. To use certificates the device needs a valid CA and a proper time. If the device is desynchronize, > it should use the time value provided by the DHCP Time Option. This only works if provided by a trusted DHCP > Server. As a result, for a desynchronized device it may not provide any advantages, and sending the KSK > insecurely is much simpler. But if the client needs that much certificate processing capability, why not just have the client do that straight against the ICANN pem bundle? That works better too if the device changes hands (as old devices often do) The only reason I see here is to have corporate issued devices take on the non-public corporate trust anchors. I don't think enterprise device management needs an internet protocol. They should just grab the device and bring it up to date with its OS/firmware before redeploying it on their internal network. You shouldn't be deploying unpatched years-old devices on a corporate lan anyway. > The big issues I see are: >     1) It only applies to the Root Key. Which means the CPE cannot recover for example from TLD that had an > emergency roll over. But the root key is special. for all other emergency rollovers, flush your DNS cache and try again? >     2) If does not provide the ISP to mitigate a key roll over issue performed on the Internet. If a problem > occurs, the end user will not call ICANN. They should call Microsoft, Apple, Google, or their Linux vendor instead. Giving ISPs so much trust power to override an enduser's trust anchors is just not safe. > For enterprise devices, I would assume that an unfiltered internet > connection is not available (firewalled, etc) so it might need something > else. However, there is likely good reason to have trust in the LAN, > and a time estimate could be obtained from the NTP server through DHCP > (option 42 could provide an IP address for one entry, therefor removing > the need for DNS to obtain NTP) > > Good point, providing IP addresses makes DHCP Time Option unnecessary. > Difference between ntp client vs DHCP Options is that using ntp client adds round trip, and requires the ntp > client to be installed. If that does not cause any problems, then we should use option 42. Even most cheap $30 wifi/routers have ntp these days. the only category that might not have it is the "internet of things" kind of devices. But those would not use DNS(SEC) either I think. > I see your point with split-views. which I think is really the most important trust anchor hand-over to deal with. And your draft might be used for that! > I should add this to the draft. I agree that CERT may not be very useful in > LAN or trusted environment. On the other hand it would really help that ISPs can provision the devices with KSKs > and authenticate them. I _really_ don't want ISPs changing trust anchors. We are moving DNSSEC to the endnode because we cannot trust either the ISPs or the link between the ISPs and us. > In addition I would like also a standard way to store KSK in certificate. While I'm really trying hard to keep DNS in DNS only :) > A discussion would be very helpful to talk about the various security > implications, and to ensure that we can keep the differences between > DHCP and IKEv2 options for VPN as small as possible. > > Definitely. I have not mentioned VPN use cases, but we should consider this case with more attention. Wen you say > "as small as possible" do you mean that we should also define new CP attributes? I am sure I must misunderstood > something, but I expect the VPN client to get the DHCP Server address from the security gateway(INTERNAL_*_DHCP) > and from that the client sends the ORO to the DHCP Sever. Each option that we add to DHCP for DNS reconfiguration is an option we would need to have an IPsec gateway relay via IKE as well to remote clients so being remote or local ends up with the same DNS configuraion. Of course, the advantage of IPsec is that it is all authenticated, unlike DHCP. Paul From mellon@fugue.com Tue Oct 22 09:01:48 2013 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 66F6011E84C4 for ; Tue, 22 Oct 2013 09:01:48 -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 HIt6gK13V2yE for ; Tue, 22 Oct 2013 09:01:42 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1751411E81D7 for ; Tue, 22 Oct 2013 09:01:30 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 1711F238033F; Tue, 22 Oct 2013 12:01:28 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ted Lemon In-Reply-To: <526699F3.20908@mtcc.com> Date: Tue, 22 Oct 2013 12:01:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1510) Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 16:01:48 -0000 On Oct 22, 2013, at 11:29 AM, Michael Thomas wrote: > Since this is homenet, oughtn't we be thinking in terms of getting = configuration information > from things that we believe we ought to always trust, like, oh say, a = server on our home network? > Regardless of our current attachment point(s)? What would the security model be here? How do we know to trust = something on our home network? We pretty much blew this off when we did = the architecture document=97the general attitude seemed to be "security = is hard, so let's do it later." So while I might agree in the abstract = that your proposal makes sense, we have no solution that actually _does_ = this. So mentioning it as an alternative isn't going to get us = anywhere. Of course, we _also_ don't have a security model for the = scenario Daniel's draft talks about. So I would say that both of these = solutions are non-starters. From joelja@bogus.com Tue Oct 22 10:02:32 2013 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 0800A11E81F7 for ; Tue, 22 Oct 2013 10:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 rHTaXS+ksuEx for ; Tue, 22 Oct 2013 10:02:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA8311E81BF for ; Tue, 22 Oct 2013 10:02:31 -0700 (PDT) Received: from mb-aye.corp.zynga.com ([199.48.105.4]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id r9MH2RMp096187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 22 Oct 2013 17:02:27 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/signed; boundary="Apple-Mail=_2DDB25E3-7375-48A2-A549-9855C718DFEB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: joel jaeggli In-Reply-To: <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> Date: Tue, 22 Oct 2013 10:02:24 -0700 Message-Id: References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.1510) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 22 Oct 2013 17:02:28 +0000 (UTC) Cc: homenet@ietf.org, Michael Thomas Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 17:02:32 -0000 --Apple-Mail=_2DDB25E3-7375-48A2-A549-9855C718DFEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 22, 2013, at 9:01 AM, Ted Lemon wrote: > On Oct 22, 2013, at 11:29 AM, Michael Thomas wrote: >> Since this is homenet, oughtn't we be thinking in terms of getting = configuration information >> from things that we believe we ought to always trust, like, oh say, a = server on our home network? >> Regardless of our current attachment point(s)? >=20 > What would the security model be here? How do we know to trust = something on our home network? We pretty much blew this off when we did = the architecture document=97the general attitude seemed to be "security = is hard, so let's do it later." I'm not so sure of that, I think there is a lack of broad-based = consensus on what balance to attempt, which is not to say that it was = blown off, it's not like there was an absence of debate. > So while I might agree in the abstract that your proposal makes = sense, we have no solution that actually _does_ this. So mentioning it = as an alternative isn't going to get us anywhere. Of course, we _also_ = don't have a security model for the scenario Daniel's draft talks about. = So I would say that both of these solutions are non-starters. If you come down on the side of relatively unrestrictive homenets one = imagines hosts security models treating those as hostile environments. > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 --Apple-Mail=_2DDB25E3-7375-48A2-A549-9855C718DFEB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJmr6AACgkQ8AA1q7Z/VrLpiwCeKh7blBYfxFEeqcup01ta9Rv7 V+YAnRNcrs64LYiMhEStlI5BaFVLFne4 =rhl8 -----END PGP SIGNATURE----- --Apple-Mail=_2DDB25E3-7375-48A2-A549-9855C718DFEB-- From mike@mtcc.com Tue Oct 22 10:06:54 2013 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 0BB3111E81BF for ; Tue, 22 Oct 2013 10:06:54 -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 oxTYIYbFHwUO for ; Tue, 22 Oct 2013 10:06:48 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 9219E21F9ED1 for ; Tue, 22 Oct 2013 10:06:44 -0700 (PDT) Received: from michael-thomass-macbook.local (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id r9MH6hpS021034 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 22 Oct 2013 10:06:44 -0700 Message-ID: <5266B09F.9020208@mtcc.com> Date: Tue, 22 Oct 2013 10:06:39 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> In-Reply-To: <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 17:06:54 -0000 On 10/22/13 9:01 AM, Ted Lemon wrote: > On Oct 22, 2013, at 11:29 AM, Michael Thomas wrote: >> Since this is homenet, oughtn't we be thinking in terms of getting configuration information >> from things that we believe we ought to always trust, like, oh say, a server on our home network? >> Regardless of our current attachment point(s)? > What would the security model be here? How do we know to trust something on our home network? We pretty much blew this off when we did the architecture document—the general attitude seemed to be "security is hard, so let's do it later." So while I might agree in the abstract that your proposal makes sense, we have no solution that actually _does_ this. So mentioning it as an alternative isn't going to get us anywhere. Of course, we _also_ don't have a security model for the scenario Daniel's draft talks about. So I would say that both of these solutions are non-starters. > > At least there is a security model on my home network, such as it is: wired needs physical access, wireless needs a password. For roaming, wireless is a closer model. So at least we have shared credentials. That's why I keep saying that "Zeroconf" is an illusion. The only way you have wireless zeroconf is to not have wireless authentication which is pretty boneheaded. Littleconf. Mike From mellon@fugue.com Tue Oct 22 10:19:51 2013 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 B3B3B11E81D1 for ; Tue, 22 Oct 2013 10:19:51 -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 1fDzbWVWxQwD for ; Tue, 22 Oct 2013 10:19:46 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id B192511E83FC for ; Tue, 22 Oct 2013 10:19:46 -0700 (PDT) Received: from [IPv6:2001:470:88a3::d92f:f1b9:a876:c805] (unknown [IPv6:2001:470:88a3:0:d92f:f1b9:a876:c805]) by toccata.fugue.com (Postfix) with ESMTPSA id B7BA6238033F; Tue, 22 Oct 2013 13:19:45 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ted Lemon In-Reply-To: Date: Tue, 22 Oct 2013 13:19:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <552CFA4E-F6E6-4447-8116-BDE559929DA2@fugue.com> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> To: joel jaeggli X-Mailer: Apple Mail (2.1510) Cc: homenet@ietf.org, Michael Thomas Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 17:19:51 -0000 On Oct 22, 2013, at 1:02 PM, joel jaeggli wrote: > I'm not so sure of that, I think there is a lack of broad-based = consensus on what balance to attempt, which is not to say that it was = blown off, it's not like there was an absence of debate. Absolutely. There was tons of debate! :) >> So while I might agree in the abstract that your proposal makes = sense, we have no solution that actually _does_ this. So mentioning it = as an alternative isn't going to get us anywhere. Of course, we _also_ = don't have a security model for the scenario Daniel's draft talks about. = So I would say that both of these solutions are non-starters. >=20 > If you come down on the side of relatively unrestrictive homenets one = imagines hosts security models treating those as hostile environments. Yes. Or if that's the kind of homenets that we wind up describing = simply because we didn't address the security problem, which I think is = the status quo. From mellon@fugue.com Tue Oct 22 10:23:03 2013 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 2D19B11E83EF for ; Tue, 22 Oct 2013 10:23:03 -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 cT68PG69oG4R for ; Tue, 22 Oct 2013 10:22:58 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id AD14811E83C0 for ; Tue, 22 Oct 2013 10:22:57 -0700 (PDT) Received: from [IPv6:2001:470:88a3::d92f:f1b9:a876:c805] (unknown [IPv6:2001:470:88a3:0:d92f:f1b9:a876:c805]) by toccata.fugue.com (Postfix) with ESMTPSA id 0645B238033F; Tue, 22 Oct 2013 13:22:56 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ted Lemon In-Reply-To: <5266B09F.9020208@mtcc.com> Date: Tue, 22 Oct 2013 13:22:55 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1510) Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 17:23:03 -0000 On Oct 22, 2013, at 1:06 PM, Michael Thomas wrote: > At least there is a security model on my home network, such as it is: = wired needs physical > access, wireless needs a password. For roaming, wireless is a closer = model. So at least we > have shared credentials. You have shared credentials with the wrong thing. They don't serve to = authenticate a DHCP packet you receive on the WiFi. Furthermore, since = they are shared, it makes no sense to use them to authenticate the = server=97everybody on the network by definition knows the password, so = anybody can prove that they have it. Passwords of this sort strictly = function to prevent unauthorized access to the network=97they can't be = used for anything else. I suppose we could mandate WPA2 enterprise on the homenet, but we still = don't have a way to use that to secure the DHCP transaction. From mike@mtcc.com Tue Oct 22 12:29:22 2013 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 013DD11E823A for ; Tue, 22 Oct 2013 12:29:22 -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 D9SlcX71ab1G for ; Tue, 22 Oct 2013 12:29:16 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id C3A7A11E821F for ; Tue, 22 Oct 2013 12:29:06 -0700 (PDT) Received: from michael-thomass-macbook.local (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id r9MJT12H024948 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Oct 2013 12:29:04 -0700 Message-ID: <5266D1F8.1050609@mtcc.com> Date: Tue, 22 Oct 2013 12:28:56 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ted Lemon References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 19:29:22 -0000 On 10/22/13 10:22 AM, Ted Lemon wrote: > On Oct 22, 2013, at 1:06 PM, Michael Thomas wrote: >> At least there is a security model on my home network, such as it is: wired needs physical >> access, wireless needs a password. For roaming, wireless is a closer model. So at least we >> have shared credentials. > You have shared credentials with the wrong thing. They don't serve to authenticate a DHCP packet you receive on the WiFi. Furthermore, since they are shared, it makes no sense to use them to authenticate the server—everybody on the network by definition knows the password, so anybody can prove that they have it. Passwords of this sort strictly function to prevent unauthorized access to the network—they can't be used for anything else. > > I suppose we could mandate WPA2 enterprise on the homenet, but we still don't have a way to use that to secure the DHCP transaction. > I didn't say anything about DHCP; I was purposefully vague about what a configuration/whatever protocol ought to be. I was only pointing out that there already exists a shared credential between my phone, say, and my home router, say. And you could use the initial contact with the holder of a shared secret (eg router) to bootstrap a 1:1 key (diffie helman is probably our friend). So you have an initial leap of faith, but beyond that you're enrolled. No AAA required. Mike From mellon@fugue.com Tue Oct 22 12:39:48 2013 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 1FB0611E8237 for ; Tue, 22 Oct 2013 12:39:38 -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 l-RJP2HPXkCf for ; Tue, 22 Oct 2013 12:39:32 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6F63D11E8217 for ; Tue, 22 Oct 2013 12:39:30 -0700 (PDT) Received: from [10.0.10.40] (c-174-62-147-182.hsd1.nh.comcast.net [174.62.147.182]) by toccata.fugue.com (Postfix) with ESMTPSA id 11594238033F; Tue, 22 Oct 2013 15:39:28 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ted Lemon In-Reply-To: <5266D1F8.1050609@mtcc.com> Date: Tue, 22 Oct 2013 15:39:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1510) Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 19:39:48 -0000 On Oct 22, 2013, at 3:28 PM, Michael Thomas wrote: > I didn't say anything about DHCP; I was purposefully vague about what = a configuration/whatever > protocol ought to be. I was only pointing out that there already = exists a shared credential between my phone, say, and my home router, = say. And you could use the initial contact with the holder of a shared = secret (eg router) to bootstrap a 1:1 key (diffie helman is probably our = friend). So you have an initial leap of faith, but beyond that you're = enrolled. No AAA required. The DHCP issue is a red herring. You don't have a shared secret. You = have a well-known token. You can't use that to make a leap of faith. I'm not saying this problem can't be solved, but it won't be solved this = way, and it must be solved before we can trust the configuration = information we get on the local wire. From mike@mtcc.com Tue Oct 22 13:01:52 2013 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 1FF0011E824D for ; Tue, 22 Oct 2013 13:01:52 -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 cYFhpuISRY0R for ; Tue, 22 Oct 2013 13:01:46 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id D633C11E8237 for ; Tue, 22 Oct 2013 13:01:45 -0700 (PDT) Received: from michael-thomass-macbook.local (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id r9MK1hPx000859 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Oct 2013 13:01:43 -0700 Message-ID: <5266D9A1.2040001@mtcc.com> Date: Tue, 22 Oct 2013 13:01:37 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ted Lemon References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> In-Reply-To: <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 20:01:52 -0000 On 10/22/13 12:39 PM, Ted Lemon wrote: > On Oct 22, 2013, at 3:28 PM, Michael Thomas wrote: >> I didn't say anything about DHCP; I was purposefully vague about what a configuration/whatever >> protocol ought to be. I was only pointing out that there already exists a shared credential between my phone, say, and my home router, say. And you could use the initial contact with the holder of a shared secret (eg router) to bootstrap a 1:1 key (diffie helman is probably our friend). So you have an initial leap of faith, but beyond that you're enrolled. No AAA required. > The DHCP issue is a red herring. You don't have a shared secret. You have a well-known token. You can't use that to make a leap of faith. > > I'm not saying this problem can't be solved, but it won't be solved this way, and it must be solved before we can trust the configuration information we get on the local wire. > It's isn't "well known", it's just a group secret. And you certainly could use it to make a leap of faith: ssh does it without a group secret at all, so it's actually somewhat better: I at least know that the thing that I'm doing the leap of faith with has knowledge of the group secret. Mike From mellon@fugue.com Tue Oct 22 13:08:44 2013 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 53B9411E8215 for ; Tue, 22 Oct 2013 13:08:44 -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 15wEg55skOO3 for ; Tue, 22 Oct 2013 13:08:39 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 42CF911E8222 for ; Tue, 22 Oct 2013 13:08:39 -0700 (PDT) Received: from [IPv6:2001:470:88a3::7093:43b0:5340:68bc] (unknown [IPv6:2001:470:88a3:0:7093:43b0:5340:68bc]) by toccata.fugue.com (Postfix) with ESMTPSA id BBE9B238033F; Tue, 22 Oct 2013 16:08:38 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ted Lemon In-Reply-To: <5266D9A1.2040001@mtcc.com> Date: Tue, 22 Oct 2013 16:08:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> <5266D9A1.2040001@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1510) Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 20:08:44 -0000 On Oct 22, 2013, at 4:01 PM, Michael Thomas wrote: > It's isn't "well known", it's just a group secret. And you certainly = could use it to make > a leap of faith: ssh does it without a group secret at all, so it's = actually somewhat better: > I at least know that the thing that I'm doing the leap of faith with = has knowledge of the > group secret. It's not a secret if it is shared by more than two hosts. It is a well = known token, which is not widely known. Any device connected to the = network can pretend to be the server if you allow that token to be used = to authenticate the server. Ssh has a public/private key pair on the server. The leap of faith = there is based on that key pair, not on a "group secret." This problem can be solved, but I am strongly opposed to handwaving. = If you want to assert that we can have a secure system, even based on a = leap of faith, I do not disagree with that, but you need to tell me what = the system _is_. Otherwise the discussion is completely hypothetical, = and we can't draw any real conclusions at all. So before the working group has any conversations about technologies = that depend on a security solution that doesn't yet exist, I would like = us to have a security solution upon which to base those technologies. = Until we do, proposals like this one just sound like security snake oil, = and we shouldn't be entertaining them. From mike@mtcc.com Tue Oct 22 13:22:15 2013 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 897F211E8271 for ; Tue, 22 Oct 2013 13:22:15 -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 agaKXN+2q6aD for ; Tue, 22 Oct 2013 13:22:09 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 9F36311E824A for ; Tue, 22 Oct 2013 13:22:09 -0700 (PDT) Received: from michael-thomass-macbook.local (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id r9MKM8Z8006115 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 22 Oct 2013 13:22:09 -0700 Message-ID: <5266DE6B.2090000@mtcc.com> Date: Tue, 22 Oct 2013 13:22:03 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> <5266D9A1.2040001@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 20:22:15 -0000 On 10/22/13 1:08 PM, Ted Lemon wrote: > On Oct 22, 2013, at 4:01 PM, Michael Thomas wrote: >> It's isn't "well known", it's just a group secret. And you certainly could use it to make >> a leap of faith: ssh does it without a group secret at all, so it's actually somewhat better: >> I at least know that the thing that I'm doing the leap of faith with has knowledge of the >> group secret. > It's not a secret if it is shared by more than two hosts. It is a well known token, which is not widely known. Any device connected to the network can pretend to be the server if you allow that token to be used to authenticate the server. Whatever you say. You win. > > Ssh has a public/private key pair on the server. The leap of faith there is based on that key pair, not on a "group secret." If you'd pause a moment from winning, I said that requiring knowledge of the group secret to do the leap of faith is somewhat better than the straight leap of faith that ssh uses. But we're far afield from my original point: that I'd rather use a server on my home network to get my configuration, rather than trusting some random ISP who I happen to be connected to at any point in time. That doesn't work for roaming, and it's questionable whether it's an especially good idea even when I'm not. > > This problem can be solved, but I am strongly opposed to handwaving. If you want to assert that we can have a secure system, even based on a leap of faith, I do not disagree with that, but you need to tell me what the system _is_. Otherwise the discussion is completely hypothetical, and we can't draw any real conclusions at all. > > So before the working group has any conversations about technologies that depend on a security solution that doesn't yet exist, I would like us to have a security solution upon which to base those technologies. Until we do, proposals like this one just sound like security snake oil, and we shouldn't be entertaining them. > This is in the context of extant draft not of my making. Are you suggesting that we shouldn't comment on that draft? Mike From mellon@fugue.com Tue Oct 22 14:07:36 2013 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 8B18711E821E for ; Tue, 22 Oct 2013 14:07:36 -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 N09fwSZM71ip for ; Tue, 22 Oct 2013 14:07:30 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8487C11E81CD for ; Tue, 22 Oct 2013 14:07:27 -0700 (PDT) Received: from [IPv6:2001:470:88a3::7093:43b0:5340:68bc] (unknown [IPv6:2001:470:88a3:0:7093:43b0:5340:68bc]) by toccata.fugue.com (Postfix) with ESMTPSA id 11417238033F; Tue, 22 Oct 2013 17:07:23 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ted Lemon In-Reply-To: <5266DE6B.2090000@mtcc.com> Date: Tue, 22 Oct 2013 17:07:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <02B569C2-3758-4709-84BD-6DEC23EC57C2@fugue.com> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> <5266D9A1.2040001@mtcc.com> <5266DE6B.2090000@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1510) Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 21:07:36 -0000 On Oct 22, 2013, at 4:22 PM, Michael Thomas wrote: > If you'd pause a moment from winning, I said that requiring knowledge = of the group secret > to do the leap of faith is somewhat better than the straight leap of = faith that ssh uses. The public key can be used to authenticate the server in future = connections as being the same server that you contacted when you first = made the leap of faith. The "group secret" proves to the server that = you know the password to the network, but it can't be used by the = network to prove that it is trustworthy. And there is no additional = token, so every time you use that server, you are making the same leap = of faith you made the first time. Leap of faith authentication = provides some additional security because you can only attack it the = first time it's used=97when the leap of faith is made. If you make a = leap of faith every time you connect, that's no different than having no = security at all. > But we're far afield from my original point: that I'd rather use a = server on my home > network to get my configuration, rather than trusting some random ISP = who I happen > to be connected to at any point in time. That doesn't work for = roaming, and it's questionable > whether it's an especially good idea even when I'm not. This is the key point: your home network is just a random network to = your device, unless you have a secure mechanism for identifying it. I = do agree with your basic point that you can't just trust any random = network; what I am trying to point out is there is currently no = mechanism we've specified that allows your device to securely = distinguish your home network from those other networks. > Are you suggesting that we shouldn't comment on that draft? If I wanted to say such an inappropriate thing, I would just say it, and = then presumably there would be a recall petition, and I'd be able to go = back to being an individual contributor, and my life would get a lot = simpler. I want desperately for the working group to comment on the = draft, and I appreciate you commenting. Please don't take debate from = me as implying that you should shut up. When I accuse you of = handwaving, it's because I want you to get specific, not because I want = you to shut up. You're in no way obliged to get specific=97that's just = what _I_ want.= From mike@mtcc.com Tue Oct 22 14:31:20 2013 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 E2EE811E80F1 for ; Tue, 22 Oct 2013 14:31:19 -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 kcASAha7E94W for ; Tue, 22 Oct 2013 14:31:14 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 520EE11E81FF for ; Tue, 22 Oct 2013 14:31:02 -0700 (PDT) Received: from michael-thomass-macbook.local (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id r9MLUwj4023833 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Oct 2013 14:31:00 -0700 Message-ID: <5266EE8C.5000909@mtcc.com> Date: Tue, 22 Oct 2013 14:30:52 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ted Lemon References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> <5266D9A1.2040001@mtcc.com> <5266DE6B.2090000@mtcc.com> <02B569C2-3758-4709-84BD-6DEC23EC57C2@fugue.com> In-Reply-To: <02B569C2-3758-4709-84BD-6DEC23EC57C2@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 21:31:20 -0000 On 10/22/13 2:07 PM, Ted Lemon wrote: > On Oct 22, 2013, at 4:22 PM, Michael Thomas wrote: >> If you'd pause a moment from winning, I said that requiring knowledge of the group secret >> to do the leap of faith is somewhat better than the straight leap of faith that ssh uses. > The public key can be used to authenticate the server in future connections as being the same server that you contacted when you first made the leap of faith. The "group secret" proves to the server that you know the password to the network, but it can't be used by the network to prove that it is trustworthy. And there is no additional token, so every time you use that server, you are making the same leap of faith you made the first time. Leap of faith authentication provides some additional security because you can only attack it the first time it's used—when the leap of faith is made. If you make a leap of faith every time you connect, that's no different than having no security at all. Yes, it just limits the bad guys to those who know that shared secret. I'll leave it to crypto-heads whether that's enough of an advantage to warrant l2/l3 entanglement (which is what you really should rip me for :) > >> But we're far afield from my original point: that I'd rather use a server on my home >> network to get my configuration, rather than trusting some random ISP who I happen >> to be connected to at any point in time. That doesn't work for roaming, and it's questionable >> whether it's an especially good idea even when I'm not. > This is the key point: your home network is just a random network to your device, unless you have a secure mechanism for identifying it. I do agree with your basic point that you can't just trust any random network; what I am trying to point out is there is currently no mechanism we've specified that allows your device to securely distinguish your home network from those other networks. Yes, of course. And it's why zeroconf is incompatible with security: you have to enroll, and enrollment without checking who you're talking to is insecure. Ssh isn't *really* zeroconf if you consider it: it asks you first whether you want to take that leap of faith which requires actually considering the possibility that something bad might happen. What I'd really like is for my device to "home" itself on a network or server with my human participation to, like ssh, say "yes, it's ok" because I'm at home on my wifi when I first bought it, and "no, it's not ok because I'm still at Bestbuy". Further, I'd say that it really isn't the "Network" that I want to trust, but some server (or two), probably running on my home network but not necessarily. In fact, I think we should stop talking about trusting a "network" altogether because it's really distinct hosts that we ought to trust or not, even if one of those hosts happens to be my home router (router != "network", of course). > >> Are you suggesting that we shouldn't comment on that draft? > If I wanted to say such an inappropriate thing, I would just say it, and then presumably there would be a recall petition, and I'd be able to go back to being an individual contributor, and my life would get a lot simpler. I want desperately for the working group to comment on the draft, and I appreciate you commenting. Please don't take debate from me as implying that you should shut up. When I accuse you of handwaving, it's because I want you to get specific, not because I want you to shut up. You're in no way obliged to get specific—that's just what _I_ want. As far as I can tell, the draft is still ISP-DHCP centric which to my mind is a non-starter, for many, many reasons. I haven't read the newest version, so apologies if I'm out of date. I'd suggest to the authors to rethink the entire scheme *without* DHCP, and without any requirement that there's a link-level relationship to do what they're trying to do: it should work from the other end of the internet directly addressed with a nice shiny ipv6 address. Mike From mellon@fugue.com Tue Oct 22 15:40:32 2013 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 C6ACA11E82C8 for ; Tue, 22 Oct 2013 15:40:31 -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 EqsWzhnbxkZM for ; Tue, 22 Oct 2013 15:40:08 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id ED75911E82A4 for ; Tue, 22 Oct 2013 15:40:03 -0700 (PDT) Received: from [IPv6:2001:470:88a3::7093:43b0:5340:68bc] (unknown [IPv6:2001:470:88a3:0:7093:43b0:5340:68bc]) by toccata.fugue.com (Postfix) with ESMTPSA id 42B49238038C; Tue, 22 Oct 2013 18:39:58 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ted Lemon In-Reply-To: <5266EE8C.5000909@mtcc.com> Date: Tue, 22 Oct 2013 18:39:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4CA27FC5-109B-41A9-8DBA-4264776D27A4@fugue.com> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> <5266D9A1.2040001@mtcc.com> <5266DE6B.2090000@mtcc.com> <02B569C2-3758-4709-84BD-6DEC23EC57C2@fugue.com> <5266EE8C.5000909@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1510) Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 22:40:32 -0000 On Oct 22, 2013, at 5:30 PM, Michael Thomas wrote: > Yes, it just limits the bad guys to those who know that shared secret. = I'll leave it > to crypto-heads whether that's enough of an advantage to warrant l2/l3 = entanglement > (which is what you really should rip me for :) I think WPA2 Enterprise uses L3 to get the access control information, = so we can forgive you for this minor faux pas. :) > Yes, of course. And it's why zeroconf is incompatible with security: = you have to enroll, > and enrollment without checking who you're talking to is insecure. Ssh = isn't *really* > zeroconf if you consider it: it asks you first whether you want to = take that leap of faith > which requires actually considering the possibility that something bad = might happen. Right. Minimal touch, not zero-touch. > What I'd really like is for my device to "home" itself on a network or = server with > my human participation to, like ssh, say "yes, it's ok" because I'm at = home on > my wifi when I first bought it, and "no, it's not ok because I'm still = at Bestbuy". Agreed. I think this is a good model. I'd like to see the working = group work on something like this (ad hat off). > Further, I'd say that it really isn't the "Network" that I want to = trust, but > some server (or two), probably running on my home network but not = necessarily. > In fact, I think we should stop talking about trusting a "network" = altogether because > it's really distinct hosts that we ought to trust or not, even if one = of those hosts > happens to be my home router (router !=3D "network", of course). Yup. > As far as I can tell, the draft is still ISP-DHCP centric which to my = mind is a non-starter, > for many, many reasons. I haven't read the newest version, so = apologies if I'm out of date. > I'd suggest to the authors to rethink the entire scheme *without* = DHCP, and without any > requirement that there's a link-level relationship to do what they're = trying to do: it should > work from the other end of the internet directly addressed with a nice = shiny ipv6 address. Yeah, I _think_ Daniel is just addressing the provisioning of the = customer edge home gateway, not hosts on the homenet. So in that = context it makes a little more sense, but I still think it's problematic = in any case where the provider isn't shipping customers devices with = custom firmware.= From mike@mtcc.com Tue Oct 22 15:53:01 2013 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 4322E11E823F for ; Tue, 22 Oct 2013 15:53:01 -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 7dlFUppKMarp for ; Tue, 22 Oct 2013 15:52:45 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1E93A11E828E for ; Tue, 22 Oct 2013 15:52:43 -0700 (PDT) Received: from michael-thomass-macbook.local (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id r9MMqfgS012336 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 22 Oct 2013 15:52:42 -0700 Message-ID: <526701B4.7090308@mtcc.com> Date: Tue, 22 Oct 2013 15:52:36 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: homenet@ietf.org References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> <5266D9A1.2040001@mtcc.com> <5266DE6B.2090000@mtcc.com> <02B569C2-3758-4709-84BD-6DEC23EC57C2@fugue.com> <5266EE8C.5000909@mtcc.com> <4CA27FC5-109B-41A9-8DBA-4264776D27A4@fugue.com> In-Reply-To: <4CA27FC5-109B-41A9-8DBA-4264776D27A4@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 22:53:01 -0000 On 10/22/13 3:39 PM, Ted Lemon wrote: >> As far as I can tell, the draft is still ISP-DHCP centric which to my mind is a non-starter, >> for many, many reasons. I haven't read the newest version, so apologies if I'm out of date. >> I'd suggest to the authors to rethink the entire scheme *without* DHCP, and without any >> requirement that there's a link-level relationship to do what they're trying to do: it should >> work from the other end of the internet directly addressed with a nice shiny ipv6 address. > Yeah, I _think_ Daniel is just addressing the provisioning of the customer edge home gateway, not hosts on the homenet. So in that context it makes a little more sense, but I still think it's problematic in any case where the provider isn't shipping customers devices with custom firmware. > Oh, ok. This goes back to the duality problem with DHCP then (discovery, configuration). Has anybody ever posited a DHCP configuration-only protocol where you could have normal transport (ie, not to a broadcast address, you could have, say, (d)TLS, it doesn't have to be link local, etc, etc)? Or maybe what they really want is tr-069? Mike From mellon@fugue.com Tue Oct 22 15:59:01 2013 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 8E76911E82A1 for ; Tue, 22 Oct 2013 15:59:01 -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 kEgW1gkCS3AH for ; Tue, 22 Oct 2013 15:58:56 -0700 (PDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEE511E8294 for ; Tue, 22 Oct 2013 15:58:55 -0700 (PDT) Received: from [IPv6:2001:470:88a3::7093:43b0:5340:68bc] (unknown [IPv6:2001:470:88a3:0:7093:43b0:5340:68bc]) by toccata.fugue.com (Postfix) with ESMTPSA id A06A3238038C; Tue, 22 Oct 2013 18:58:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Ted Lemon In-Reply-To: <526701B4.7090308@mtcc.com> Date: Tue, 22 Oct 2013 18:58:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <842C4F36-F73E-4C84-8FE0-335F6CF5B2E8@fugue.com> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> <5266D9A1.2040001@mtcc.com> <5266DE6B.2090000@mtcc.com> <02B569C2-3758-4709-84BD-6DEC23EC57C2@fugue.com> <5266EE8C.5000909@mtcc.com> <4CA27FC5-109B-41A9-8DBA-4264776D27A4@fugue.com> <526701B4.7090308@mtcc.com> To: Michael Thomas X-Mailer: Apple Mail (2.1510) Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 22:59:01 -0000 On Oct 22, 2013, at 6:52 PM, Michael Thomas wrote: > Oh, ok. This goes back to the duality problem with DHCP then = (discovery, configuration). > Has anybody ever posited a DHCP configuration-only protocol where you = could have > normal transport (ie, not to a broadcast address, you could have, say, = (d)TLS, it doesn't > have to be link local, etc, etc)? >=20 > Or maybe what they really want is tr-069? Doesn't TR-069 use DHCP? Sheng Jiang has proposed a mechanism for securing DHCP messages using = public key encryption. It's up for discussion in the DHC working group = at the moment. I haven't looked at how to use DTLS to secure DHCP messages. It would = be nice if it were possible. From mike@mtcc.com Tue Oct 22 16:02:33 2013 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 CA4D111E82A7 for ; Tue, 22 Oct 2013 16:02: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 TmgdEsG4+TxI for ; Tue, 22 Oct 2013 16:02:28 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id DF54721F9DCE for ; Tue, 22 Oct 2013 16:02:27 -0700 (PDT) Received: from michael-thomass-macbook.local (c-50-148-182-215.hsd1.ca.comcast.net [50.148.182.215]) (authenticated bits=0) by mtcc.com (8.14.7/8.14.7) with ESMTP id r9MN2PDr014824 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 22 Oct 2013 16:02:26 -0700 Message-ID: <526703FC.8040804@mtcc.com> Date: Tue, 22 Oct 2013 16:02:20 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Ted Lemon References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> <5266D9A1.2040001@mtcc.com> <5266DE6B.2090000@mtcc.com> <02B569C2-3758-4709-84BD-6DEC23EC57C2@fugue.com> <5266EE8C.5000909@mtcc.com> <4CA27FC5-109B-41A9-8DBA-4264776D27A4@fugue.com> <526701B4.7090308@mtcc.com> <842C4F36-F73E-4C84-8FE0-335F6CF5B2E8@fugue.com> In-Reply-To: <842C4F36-F73E-4C84-8FE0-335F6CF5B2E8@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 22 Oct 2013 23:02:33 -0000 On 10/22/13 3:58 PM, Ted Lemon wrote: > On Oct 22, 2013, at 6:52 PM, Michael Thomas wrote: >> Oh, ok. This goes back to the duality problem with DHCP then (discovery, configuration). >> Has anybody ever posited a DHCP configuration-only protocol where you could have >> normal transport (ie, not to a broadcast address, you could have, say, (d)TLS, it doesn't >> have to be link local, etc, etc)? >> >> Or maybe what they really want is tr-069? > Doesn't TR-069 use DHCP? > > Sheng Jiang has proposed a mechanism for securing DHCP messages using public key encryption. It's up for discussion in the DHC working group at the moment. > > I haven't looked at how to use DTLS to secure DHCP messages. It would be nice if it were possible. > Tr-069 is just a plain old tcp protocol afaik. The cpe might use a dhcp option to find the tr-069 headend though. TR-069 is pretty isp-oriented too, so i doubt they'd have a problem adding stuff like dnssec roots to their data model. Mike From zehn.cao@gmail.com Wed Oct 23 06:31:04 2013 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 F00BA11E838A for ; Wed, 23 Oct 2013 06:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[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 pYQUol-QJA9Q for ; Wed, 23 Oct 2013 06:31:03 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1DB11E8196 for ; Wed, 23 Oct 2013 06:31:03 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id i13so4217280qae.9 for ; Wed, 23 Oct 2013 06:31:02 -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; bh=SnMu7hy3l/0BgO4Wq9G/rEay4aGUBJJ/F9U4/EEkkuI=; b=UGkQAESGPEtt4Yj7G8F4BvN6Kk0Tsjaqt1dQMI2WjY1yQ18ZPdrIanbHNFQVUkYp0V smvym+wqWCZdkPA9bTMLpNz61c34u2f1pbyWpiW/TjS95aqd1r1a5Fni602HVLmqda69 VL1SofyjrXece3nTq5Jws08enEek1zOonSxD12A0s3CYQHrblWmbpI3Vt+mSCoo+54Il JXWdWm1H08uYNiK5PUtot0Znk7V8HhcP5j6W1FOqW+9kIMbY/6P8WcT2u+uRAhUQqtHQ Pmlc8cD0uUqaZ7DZJkWBFwHBB72AHKle/w+AY1sejyGaGCGURBSM0sBmDVpF4nuiq7r8 b6dw== MIME-Version: 1.0 X-Received: by 10.224.103.199 with SMTP id l7mr3925115qao.56.1382535062795; Wed, 23 Oct 2013 06:31:02 -0700 (PDT) Received: by 10.96.185.68 with HTTP; Wed, 23 Oct 2013 06:31:02 -0700 (PDT) In-Reply-To: <20131021142028.29469.28175.idtracker@ietfa.amsl.com> References: <20131021142028.29469.28175.idtracker@ietfa.amsl.com> Date: Wed, 23 Oct 2013 15:31:02 +0200 Message-ID: From: "Cao,Zhen" To: homenet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [homenet] Fwd: New Version Notification for draft-cao-homenet-mif-srvdis-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: Wed, 23 Oct 2013 13:31:04 -0000 Hello, We submit a draft on home net service discovery, and comments are welcome. Best regards, cz ---------- Forwarded message ---------- From: Date: Mon, Oct 21, 2013 at 4:20 PM Subject: New Version Notification for draft-cao-homenet-mif-srvdis-00.txt To: Zehn Cao , Aaron Yi Ding A new version of I-D, draft-cao-homenet-mif-srvdis-00.txt has been successfully submitted by Zhen Cao and posted to the IETF repository. Filename: draft-cao-homenet-mif-srvdis Revision: 00 Title: Service Discovery in the Homenet Environment with Multiple Connections Creation date: 2013-10-21 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-cao-homenet-mif-srvdis-00.txt Status: http://datatracker.ietf.org/doc/draft-cao-homenet-mif-srvdis Htmlized: http://tools.ietf.org/html/draft-cao-homenet-mif-srvdis-00 Abstract: This document analyzes the problems of service discovery in a homenet multiple connection environment. A multiple connection environment consists of multiple-interfaced nodes connecting to multiple networks or multiple provisioning domains. Given a type of service a multiple-interfaced client is looking for, the discovery progress ought to return a correct pointer to the service instance that the client is able to access without trying every available channel. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From Ray.Bellis@nominet.org.uk Wed Oct 23 07:24:39 2013 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 1332611E8407 for ; Wed, 23 Oct 2013 07:24:39 -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 v9yp8PRTrVuu for ; Wed, 23 Oct 2013 07:24:34 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 62F3711E83BC for ; Wed, 23 Oct 2013 07:24:34 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: MIME-Version; b=gyXfjdX3r/PQyyzYW0sH5QrnhUAqhP3hE4IlVDbPaPEq6W3YVLUhmnYU oBmO4rxj+GbfC5C4KYghsyB6uDhHJAOtqtE8BRKynGLUzuG61wVAOKEMR t/VHHpANAUj6CGHahV83jhkZlSMExKc+FqFsxh2/sF9I7JQE9EMdGPSis tll22uPPlqxv23flOKVP8ojrpJ2d6CorsvBVs38DUPnQjnak6CDmc7qzP s161yYmkEGs4TqisF+wJ7XEFAmfGS; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1382538274; x=1414074274; h=from:to:subject:date:message-id:mime-version; bh=Z+6P2dk5Fgbsia+6GUXffQi6z/8nsSN+Od/LTdSK4Vo=; b=F1KWJjvTgwS6j/iqxWDYNhO7uiUrz7HoVq6ojFTa/LmLEkfdTKUY3IY+ ikvh9X1Rc3G7l+zNHGxA8zq5exV3fZ1hbMcO7pcokQfdD+r3k0RDE86mK ev56JvH72F1VJztHLHg4frWyacwFYz1AOP0kRYgts2CRFr9CIuCdxtABg BV6Uh4r68nqFaTmta/fg1Yb1g0+nFkQ678i0byrefuigjsxb3PTzXfYkD rRVgRhkADbd3N7or1uX9PqpmHSGoW; X-IronPort-AV: E=Sophos;i="4.93,554,1378854000"; d="scan'208,217";a="3845541" X-IPAS-Result: AqgIAMrbZ1LV+MWR/2dsb2JhbABZgmYhOFS2FogvB4EqFnSCJwVTOAELAQIcVicEGwGHfgMJmUmhX48dg1eBCwOqEIMkgio Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 23 Oct 2013 15:24:33 +0100 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%17]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 15:24:33 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Preliminary Agenda for IETF 88 session Thread-Index: AQHOz/uXZNrzeCs6mkWhdMPQhoUhbQ== Date: Wed, 23 Oct 2013 14:24:32 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEE00AB@wds-exc1.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEE00ABwdsexc1oknanomi_" MIME-Version: 1.0 Subject: [homenet] Preliminary Agenda for IETF 88 session 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, 23 Oct 2013 14:24:39 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEE00ABwdsexc1oknanomi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The preliminary agenda is now online at: Ray and Mark --_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEE00ABwdsexc1oknanomi_ Content-Type: text/html; charset="us-ascii" Content-ID: <03CD6872AF9DC747AF659396DA6EA6C0@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable The preliminary agenda is now online at:


Ray and Mark

--_000_53F00E5CD8B2E34C81C0C89EB0B4FE732DEE00ABwdsexc1oknanomi_-- From mglt.ietf@gmail.com Wed Oct 23 10:07:06 2013 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 C686F11E8475 for ; Wed, 23 Oct 2013 10:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=-0.740, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 U0h9Y47QuknL for ; Wed, 23 Oct 2013 10:07:05 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 55B0F11E8471 for ; Wed, 23 Oct 2013 10:06:54 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ey11so7716203wid.6 for ; Wed, 23 Oct 2013 10:06:41 -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=JqOKEISpvsoDFQCG91+Mf9iJlGBsaeu9yyfRO5cH1u4=; b=h5EluU/lAFO6V7kCCHwrDalzZAlnfmUWXjfRNUaEg97Rik5FxJ/O20AnoWqXjningD 58dDGjQu1Yoi6E2vayxQwd2245z7sgh/FMWuI0wCbC6iou0EONyEhp5gemuSgk1b4Vqs H8bRHt4FwbTvxz6GbqVK0G95iM5Z6JnONogz5LwYMpOuvLHqZDbVkKeQMLQ7CDGrB3AI mcOpHaDehjvtLTTt7jpfw06qni7zFKKhtAhMT8euX3nCHFl6xmMy7j0hVoNWRgWgQ6hI UkMgRiZ/5UWn11JqcAIqMYwrW0+AAdGvaOAN5wHqKQdRQ6bdXkCu5zpiCvidCZVPnc/z /taw== MIME-Version: 1.0 X-Received: by 10.180.9.163 with SMTP id a3mr2478362wib.40.1382548001769; Wed, 23 Oct 2013 10:06:41 -0700 (PDT) Received: by 10.194.41.138 with HTTP; Wed, 23 Oct 2013 10:06:41 -0700 (PDT) In-Reply-To: <526703FC.8040804@mtcc.com> References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> <5266D9A1.2040001@mtcc.com> <5266DE6B.2090000@mtcc.com> <02B569C2-3758-4709-84BD-6DEC23EC57C2@fugue.com> <5266EE8C.5000909@mtcc.com> <4CA27FC5-109B-41A9-8DBA-4264776D27A4@fugue.com> <526701B4.7090308@mtcc.com> <842C4F36-F73E-4C84-8FE0-335F6CF5B2E8@fugue.com> <526703FC.8040804@mtcc.com> Date: Wed, 23 Oct 2013 19:06:41 +0200 Message-ID: From: Daniel Migault To: Michael Thomas , Paul Wouters Content-Type: multipart/alternative; boundary=001a11c24c5887d04004e96b8a3c Cc: "homenet@ietf.org" , Ted Lemon Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 23 Oct 2013 17:07:06 -0000 --001a11c24c5887d04004e96b8a3c Content-Type: text/plain; charset=ISO-8859-1 Hi, Thanks for all comments. I am doing a small recap. Let me know if I forgot something. I provide context and questions so people can catch up the discussion and can comment. Best Regards, Daniel 1) Replacing Time Option by the Network Time Protocol (NTP) Server Option for DHCPv6. [RFC5908] To avoid DNS request, the Option MUST provide at least an IP addresses. This option only provides IPv6 addresses. The main advantage is that the authenticity of the information does not relay anymore on a trusted relation with the DHCPv6 Server and the DHCPv6 Client, but mechanisms to authenticate [RFC5906] offers a way for NTP responses to be authenticated. Issues: a) How TA for NTP is provisioned is out of scope of the draft... but it exists. b) We assume that Home Networks are IPv6, but NTP Servers MUST also run over IPv6. Can we reasonably assume this? If not any proposition for reusing/encapsulating [RFC2132] option-42 ? >From then one can assume the device can get time in a secure way and enables signature checks. Any remarks on that point? 2) Security Models I am not sure I have been clear enough on the security model or the use case I am considering in my draft. I hope I am clarifying this point now. My device -- say a CPE or smartphone, my PC -- only performs DNSSEC resolutions, that is to say always perform signature checks, and so MUST have valid KSKs, even when a emergency key roll over is performed. Suppose a CPE is attached with a wire connection and performs DNSSEC validation for my Home Network. Suppose a KSK roll over is performed by .tld. There are two possibilities: - a) information received by the DHCP Server is reliable, valid KSKs are provided to the CPE via the OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR. The CPE updates its TA, and performs DNSSEC validation. - b) information received by the DHCP Server is not reliable. KSK is authenticated by a trusted authority (CERT). The trusted authority is a third party. It can be any authority trusted by the CPE. Suppose a smartphone is attached to a random WLAN AP and a KSK roll over is performed by .tld. Updating KSKs is necessary. The smartphone can only accept KSK validated by a trusted third party. Otherwise it ignores the KSKs provided by the DHCP Server. One way to update my KSKs is to reach a trusted network like my Home Network using a VPN for example. Suppose a smartphone attached to your home network WLAN AP or a wire line. The attachment is secured with WPA2 for example. The smartphone updates its KSKs the same way the CPE does it. Suppose the smartphone is attached to a random WLAN AP. The DHCP Server provides a KSK for the attached domain. This KSK MUST only be used for that domain and MUST be removed when the smartphone changes its administrative domain. Remarks: - a) We need to define what a Trusted DHCP Server is. - b) KSKs other than KSKs with local scope are between configuration and "local" setting for connectivity. - c) In case certification authorities are used, we hope that their keys will be not subject to emergency key roll over. Do these scenarios address the security model and clarify the scope of the draft ? 3) Trust DHCP Server The draft assumes a trust relation between a DHCP Server and a DHCP Client. Removing the Time Option reduces the necessity of this requirements. I assumed there are different relations between DHCP Client and Servers: When you receive an information from the DHCP Server two things matters: - a) Do you trust the DHCP Server = information emitted by the DHCP Server - b) Do you trust the information you receive = can anyone on path modify this information? Suppose you have no alternate way to check the information, like receiving the OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR. It is important that you answer YES to a) and b) if the DHCP Server provides information (TA) that modify the settings of the device. Note also that security protocols help to address b) but not a). Thus a) requires a configuration settings or interaction with the end user. All DHCP Servers are not the same and I consider two categories: Those you trust information you get from and those you don't. You might share a key with some, not with others and you might have different policies for each category. In any cases long term TA like TLD TA, Root TA that modify the settings of the devices MUST NOT be considered if a and b are not met. Is that fine we consider these two categories: Trusted DHCP / Untrusted DHCP? A YES means OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR may be used for TLD TA, Root TA. A NO means that OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR MUST only carry TA with a local scope (like for the split zone). 4) What are the trusted networks? Home and corporate networks may be considered as trusted network. There are different way to define you are in a trusted network: - Ask the user - Authenticate the DHCP Server - other ways ?? 5) CERT for KSKs It seems that some do not like the idea that KSKs are provided via CERT. First, I agree we should find a CA that is almost unlikely to perform key roll over. Then, a "KSKs TA office" may be created ;-). It does not exist yet, so I mentioned ISPs in my draft, but I could have specified any third party. I have no problem with that. Any remarks on the use of CERT for KSKs ? On Wed, Oct 23, 2013 at 1:02 AM, Michael Thomas wrote: > On 10/22/13 3:58 PM, Ted Lemon wrote: > >> On Oct 22, 2013, at 6:52 PM, Michael Thomas wrote: >> >>> Oh, ok. This goes back to the duality problem with DHCP then (discovery, >>> configuration). >>> Has anybody ever posited a DHCP configuration-only protocol where you >>> could have >>> normal transport (ie, not to a broadcast address, you could have, say, >>> (d)TLS, it doesn't >>> have to be link local, etc, etc)? >>> >>> Or maybe what they really want is tr-069? >>> >> Doesn't TR-069 use DHCP? >> >> Sheng Jiang has proposed a mechanism for securing DHCP messages using >> public key encryption. It's up for discussion in the DHC working group at >> the moment. >> >> I haven't looked at how to use DTLS to secure DHCP messages. It would >> be nice if it were possible. >> >> Tr-069 is just a plain old tcp protocol afaik. The cpe might use a dhcp > option to find > the tr-069 headend though. TR-069 is pretty isp-oriented too, so i doubt > they'd have a > problem adding stuff like dnssec roots to their data model. > > Mike > > ______________________________**_________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/**listinfo/homenet > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --001a11c24c5887d04004e96b8a3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for all comments. I am doing a= small recap. Let me know if I forgot something. I provide context and ques= tions so people can catch up the discussion and can comment.

Best Regards,
Daniel


1) Replacing Time Opti= on by the Network Time Protocol (NTP) Server Option for DHCPv6. [RFC5908]
To avoid DNS request, the Option MUST provide at least an IP addresse= s. This option only provides IPv6 addresses. The main advantage is that the= authenticity of the information does not relay anymore on a trusted relati= on with the DHCPv6 Server and the DHCPv6 Client, but mechanisms to authenti= cate [RFC5906] offers a way for NTP responses to be authenticated.

Issues:
=A0=A0 a) How TA for NTP is provisioned is out of scope of t= he draft... but it exists.
=A0=A0 b) We assume that Home Networks are IP= v6, but NTP Servers MUST also run over IPv6. Can we reasonably assume this?= If not any proposition for reusing/encapsulating [RFC2132] option-42 ?

From then one can assume the device can get time in a secure way and en= ables signature checks.
Any remarks on that point?


2) Securit= y Models

I am not sure I have been clear enough on the security mode= l or the use case I am considering in my draft. I hope I am clarifying this= point now.

My device -- say a CPE or smartphone, my PC -- only performs DNSSEC res= olutions, that is to say always perform signature checks, and so MUST have = valid KSKs, even when a emergency key roll over is performed.

Suppos= e a CPE is attached with a wire connection and performs DNSSEC validation f= or my Home Network. Suppose a KSK roll over is performed by .tld. There are= two possibilities:
=A0=A0=A0 - a) information received by the DHCP Server is reliable, valid K= SKs are provided to the CPE via the OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR. The = CPE updates its TA, and performs DNSSEC validation.
=A0=A0=A0 - b) infor= mation received by the DHCP Server is not reliable. KSK is authenticated by= a trusted authority (CERT). The trusted authority is a third party. It can= be any authority trusted by the CPE.

Suppose a smartphone is=A0 attached to a random WLAN AP and a KSK roll = over is performed by .tld. Updating KSKs is necessary. The smartphone can o= nly accept KSK validated by a trusted third party. Otherwise it ignores the= KSKs provided by the DHCP Server. One way to update my KSKs is to reach a = trusted network like my Home Network using a VPN for example.

Suppose a smartphone attached to your home network WLAN AP or a wire li= ne. The attachment is secured with WPA2 for example. The smartphone updates= its KSKs the same way the CPE does it.

Suppose the smartphone is at= tached to a random WLAN AP. The DHCP Server provides a KSK for the attached= domain. This KSK MUST only be used for that domain and MUST be removed whe= n the smartphone changes its administrative domain.

Remarks:
=A0=A0 - a) We need to define what a Trusted DHCP Server is= .
=A0=A0 - b) KSKs other than KSKs with local scope are between configur= ation and "local" setting for connectivity.
=A0=A0 - c) In cas= e certification authorities are used, we hope that their keys will be not s= ubject to emergency key roll over.

Do these scenarios address the security model and clarify the scope of = the draft ?

3) Trust DHCP Server

The draft assumes a trust re= lation between a DHCP Server and a DHCP Client. Removing the Time Option re= duces the necessity of this requirements. I assumed there are different rel= ations between DHCP Client and Servers: When you receive an information fro= m the DHCP Server two things matters:
=A0=A0=A0 - a) Do you trust the DHCP Server =3D information emitted by the = DHCP Server
=A0=A0=A0 - b) Do you trust the information you receive =3D= =A0 can anyone on path modify this information?

Suppose you have no = alternate way to check the information, like receiving the OPTION_DNSSEC_KS= K_RR_TRUST_ANCHOR. It is important that you answer YES to a) and b) if the = DHCP Server provides information (TA) that modify the settings of the devic= e. Note also that security protocols help to address b) but not a). Thus a)= requires a configuration settings or interaction with the end user.

All DHCP Servers are not the same and I consider two categories: Those = you trust information you get from and those you don't. You might share= a key with some, not with others and you might have different policies for= each category. In any cases long term TA like TLD TA, Root TA that modify = the settings of the devices MUST NOT be considered if a and b are not met.<= br>
Is that fine we consider these two categories: Trusted DHCP / Untrusted= DHCP?

A YES means OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR may be used for= TLD TA, Root TA. A NO means that OPTION_DNSSEC_KSK_RR_TRUST_ANCHOR MUST on= ly carry TA with a local scope (like for the split zone).

4) What are the trusted networks?

Home and corporate networks ma= y be considered as trusted network. There are different way to define you a= re in a trusted network:
=A0=A0=A0 - Ask the user
=A0=A0=A0 - Authent= icate the DHCP Server
=A0=A0=A0 - other ways ??

5) CERT for KSKs

It seems that some= do not like the idea that KSKs are provided via CERT. First, I agree we sh= ould find a CA that is almost unlikely to perform key roll over. Then, a &q= uot;KSKs TA office" may be created ;-). It does not exist yet, so I me= ntioned ISPs in my draft, but I could have specified any third party. I hav= e no problem with that.

Any remarks on the use of CERT for KSKs ?


=


On Wed, Oct 2= 3, 2013 at 1:02 AM, Michael Thomas <mike@mtcc.com> wrote:
On 10/22/13 3:58 PM, Ted L= emon wrote:
On Oct 22, 2013, at 6:52 PM, Michael Thomas <mike@mtcc.com> wrote:
Oh, ok. This goes back to the duality problem with DHCP then (discovery, co= nfiguration).
Has anybody ever posited a DHCP configuration-only protocol where you could= have
normal transport (ie, not to a broadcast address, you could have, say, (d)T= LS, it doesn't
have to be link local, etc, etc)?

Or maybe what they really want is tr-069?
Doesn't TR-069 use DHCP?

Sheng Jiang has proposed a mechanism for securing DHCP messages using publi= c key encryption. =A0 It's up for discussion in the DHC working group a= t the moment.

I haven't looked at how to use DTLS to secure DHCP messages. =A0 It wou= ld be nice if it were possible.

Tr-069 is just a plain old tcp protocol afaik. The cpe might use a dhcp opt= ion to find
the tr-069 headend though. TR-069 is pretty isp-oriented too, so i doubt th= ey'd have a
problem adding stuff like dnssec roots to their data model.

Mike

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



--
Daniel Miga= ult
Orange Labs -- Security
+33 6 70 72 69 58
--001a11c24c5887d04004e96b8a3c-- From mglt.ietf@gmail.com Wed Oct 23 13:01:03 2013 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 92D8011E81DF for ; Wed, 23 Oct 2013 13:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 fjd4b0YMyKlg for ; Wed, 23 Oct 2013 13:01:02 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 818A211E8196 for ; Wed, 23 Oct 2013 13:00:57 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id l12so7964669wiv.9 for ; Wed, 23 Oct 2013 13:00:56 -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=kiKz5g4Jcb49PGUiX7p/jwdWOerBh8DxDGR5Vc4F+gs=; b=ct3B/bCCAAeO86u+3MOaeW32QMkqVoVy1K8Zu+JwWfvfZ6g4KwRlisDMhrAiXzGKoS 9tHtuPgBj7K7Fe/QBRD0EvCLURyo4yNtgImgOpOH6NqqP2JQLLNgl2cHeAE2UqzleKMT w6COJ6BoUqmfj9nsevFn3qUH8vwYGHRbl1mrmZbe6BVzrf9HLiqkjlc8jWhs/zXNzTqb OVoz3kDsCfDcr/Kh4bl2CRz9gME3NPdP1oI0GkJsM1wnD2Sh5f8GzAkxsyFvKgi+4K7F f2azDxjMIz12EbXhsKlirSKKi10ZoNAXEg0Wewg8U3FbqZi2GYaEr3yAF3v8VioayEe1 KNhg== MIME-Version: 1.0 X-Received: by 10.194.185.73 with SMTP id fa9mr2661539wjc.29.1382558456609; Wed, 23 Oct 2013 13:00:56 -0700 (PDT) Received: by 10.194.41.138 with HTTP; Wed, 23 Oct 2013 13:00:56 -0700 (PDT) In-Reply-To: <20409_1382454276_52669404_20409_12626_1_25E5281E128EF4409E832EDD84CFD6A710325B@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20131020194108.22740.11430.idtracker@ietfa.amsl.com> <20409_1382454276_52669404_20409_12626_1_25E5281E128EF4409E832EDD84CFD6A710325B@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Wed, 23 Oct 2013 22:00:56 +0200 Message-ID: From: Daniel Migault To: dominique.gue@orange.com Content-Type: multipart/alternative; boundary=047d7bd6b048b0032304e96df968 Cc: "homenet@ietf.org" Subject: Re: [homenet] Fwd: New Version Notification for draft-mglt-homenet-front-end-naming-delegation-03.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, 23 Oct 2013 20:01:03 -0000 --047d7bd6b048b0032304e96df968 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dominique, Thank you for the comment. I am fine with having a 1 or 7 days value for expire. I do not thing it increases to much load. Any opinion on that? Daniel On Tue, Oct 22, 2013 at 5:04 PM, wrote: > Hi Daniel, **** > > I have one remark regarding 5.2 paragraph and EXPIRE parameter.**** > > It seems to me that the value by default (i.e.: 42 days) is too large. > Actually, if we take the case where the CPE is unavailable for a long tim= e > (e.g.: CPE switched-off), the association fqdn1/IP1 will stay valid in th= e > Public authoritative masters. The IP Prefix Allocation module (e.g.: DHCP > Server) could re-allocate the prefix to another CPE. Therefore host behin= d > this CPE could be assigned with same IP Address (i.e.:IP1). In the Public > authoritative masters, we could then have associations for fqdn1/IP1 and > fqdn2/IP1. As a consequence, the resolution of fqdn1 will point to the > wrong CPE.**** > > I would prefer to decrease the value of EXPIRE (e.g.: 1 or 7 days maximum= ) > depending of operator=92s policies for re-attribution of IP Prefix.**** > > ** ** > > *Dominique ***** > > ** ** > > *De :* homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] *De la > part de* Daniel Migault > *Envoy=E9 :* dimanche 20 octobre 2013 21:48 > *=C0 :* homenet@ietf.org > *Objet :* [homenet] Fwd: New Version Notification for > draft-mglt-homenet-front-end-naming-delegation-03.txt**** > > ** ** > > Hi, **** > > ** ** > > Please find our draft presenting the "IPv6 Home Network Naming > Delegation". **** > > ** ** > > URL: > http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-d= elegation-03.txt > Htmlized: > http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation= -03 > **** > > ** ** > > Feel free to make comments!**** > > ** ** > > Best Regards, **** > > ** ** > > Daniel**** > > ---------- Forwarded message ---------- > From: > Date: Sun, Oct 20, 2013 at 9:41 PM > Subject: New Version Notification for > draft-mglt-homenet-front-end-naming-delegation-03.txt > To: Wouter Cloetens , Chris Griffiths < > cgriffiths@dyn.com>, Daniel Migault , Ralf Weber < > ralf.weber@nominum.com> > > > > A new version of I-D, draft-mglt-homenet-front-end-naming-delegation-03.t= xt > has been successfully submitted by Daniel Migault and posted to the > IETF repository. > > Filename: draft-mglt-homenet-front-end-naming-delegation > Revision: 03 > Title: IPv6 Home Network Naming Delegation > Creation date: 2013-10-20 > Group: Individual Submission > Number of pages: 19 > URL: > http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-d= elegation-03.txt > Status: > http://datatracker.ietf.org/doc/draft-mglt-homenet-front-end-naming-deleg= ation > Htmlized: > http://tools.ietf.org/html/draft-mglt-homenet-front-end-naming-delegation= -03 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-homenet-front-end-naming-de= legation-03 > > Abstract: > CPEs are designed to provide IP connectivity to home networks. Most > CPEs assigns IP addresses to the nodes of the home network which > makes it a good candidate for hosting the naming service. With IPv6, > the naming service makes nodes reachable from the home network as > well as from the Internet. > > However, CPEs have not been designed to host such a naming service > exposed on the Internet. This MAY expose the CPEs to resource > exhaustion which would make the home network unreachable, and most > probably would also affect the home network inner communications. > > In addition, DNSSEC management and configuration may not be well > understood or mastered by regular end users. Misconfiguration MAY > also results in naming service disruption, thus these end users MAY > prefer to rely on third party naming providers. > > This document describes a homenet naming architecture where the CPEs > manage the DNS zone associates to its home network, and outsource > both DNSSEC management and naming service on the Internet to a third > party designated as the Public Authoritative Servers. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat**** > > > > **** > > ** ** > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 **** > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --=20 Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7bd6b048b0032304e96df968 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Dominique,=A0

Thank you for the comm= ent. I am fine with having a 1 or 7 days value for expire. I do not thing i= t increases to much load.

Any opinion on that?

Daniel


On Tue, Oct 22, 2013 at 5:04 PM, <dominiq= ue.gue@orange.com> wrote:

Hi Daniel,

I have one= remark regarding 5.2 paragraph and EXPIRE parameter.<= /p>

It seems t= o me that the value by default (i.e.: 42 days) is too large. Actually, if w= e take the case where the CPE is unavailable for a long time (e.g.: CPE switched-off), the association fqdn1/IP1 will stay valid in the= Public authoritative masters. The IP Prefix Allocation module (e.g.: DHCP = Server) could re-allocate the prefix to another CPE. Therefore host behind = this CPE could be assigned with same IP Address (i.e.:IP1). In the Public authoritative masters, we could = then have associations for fqdn1/IP1 and fqdn2/IP1. As a consequence, the r= esolution of fqdn1 will point to the wrong CPE.

I would pr= efer to decrease the value of EXPIRE (e.g.: 1 or 7 days maximum) depending = of operator=92s policies for re-attribution of IP Prefix.

=A0=

Dominique

=A0<= /p>

De=A0: homenet-bounces@ietf= .org [mailto:homenet-bounces@ietf.org] De la part de Daniel Migault
Envoy=E9=A0: dimanche 20 octobre 2013 21:48
=C0=A0: homene= t@ietf.org
Objet=A0: [homenet] Fwd: New Version Notification for draft-mglt-hom= enet-front-end-naming-delegation-03.txt

=A0

Hi,=A0

=A0

Please find our draft presenting the "IPv6 Home= Network Naming Delegation".=A0

=A0

=A0

Feel free to make comments!

=A0

Best Regards,=A0

=A0

Daniel<= /p>

---------- Forwarded = message ----------
From: <int= ernet-drafts@ietf.org>
Date: Sun, Oct 20, 2013 at 9:41 PM
Subject: New Version Notification for draft-mglt-homenet-front-end-naming-d= elegation-03.txt
To: Wouter Cloetens <wouter.cloetens@softathome.com>, Chris Griffiths &l= t;cgriffiths@dyn.co= m>, Daniel Migault <mglt.ietf@gmail.com>, Ralf Weber <ralf.weber@nominum.com>



A new version of I-D, draft-mglt-homenet-front-end-naming-delegation-03.txt=
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-homenet-front-end-naming-delegation
Revision: =A0 =A0 =A0 =A003
Title: =A0 =A0 =A0 =A0 =A0 IPv6 Home Network Naming Delegation
Creation date: =A0 2013-10-20
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 19
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-del= egation-03.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatra= cker.ietf.org/doc/draft-mglt-homenet-front-end-naming-delegation
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.= org/html/draft-mglt-homenet-front-end-naming-delegation-03
Diff: =A0 =A0 =A0 =A0 =A0 =A0http:/= /www.ietf.org/rfcdiff?url2=3Ddraft-mglt-homenet-front-end-naming-delegation= -03

Abstract:
=A0 =A0CPEs are designed to provide IP connectivity to home networks. =A0Mo= st
=A0 =A0CPEs assigns IP addresses to the nodes of the home network which
=A0 =A0makes it a good candidate for hosting the naming service. =A0With IP= v6,
=A0 =A0the naming service makes nodes reachable from the home network as =A0 =A0well as from the Internet.

=A0 =A0However, CPEs have not been designed to host such a naming service =A0 =A0exposed on the Internet. =A0This MAY expose the CPEs to resource
=A0 =A0exhaustion which would make the home network unreachable, and most =A0 =A0probably would also affect the home network inner communications.
=A0 =A0In addition, DNSSEC management and configuration may not be well
=A0 =A0understood or mastered by regular end users. =A0Misconfiguration MAY=
=A0 =A0also results in naming service disruption, thus these end users MAY<= br> =A0 =A0prefer to rely on third party naming providers.

=A0 =A0This document describes a homenet naming architecture where the CPEs=
=A0 =A0manage the DNS zone associates to its home network, and outsource =A0 =A0both DNSSEC management and naming service on the Internet to a third=
=A0 =A0party designated as the Public Authoritative Servers.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



=A0

--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.



--
Daniel Migau= lt
Orange Labs -- Security
+33 6 70 72 69 58
--047d7bd6b048b0032304e96df968-- From paul@nohats.ca Wed Oct 23 11:03:30 2013 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 BB3DD21F9C53 for ; Wed, 23 Oct 2013 11:03: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 N0ONDp8mz+TI for ; Wed, 23 Oct 2013 11:03:26 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id ABA0311E813A for ; Wed, 23 Oct 2013 11:03:22 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3d4fZt54dVzB9S; Wed, 23 Oct 2013 14:03:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qlv2cdBrN4Ji; Wed, 23 Oct 2013 14:03:17 -0400 (EDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 23 Oct 2013 14:03:17 -0400 (EDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 4A10E807CA; Wed, 23 Oct 2013 14:03:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3E872805BD; Wed, 23 Oct 2013 14:03:17 -0400 (EDT) Date: Wed, 23 Oct 2013 14:03:17 -0400 (EDT) From: Paul Wouters To: Daniel Migault In-Reply-To: Message-ID: References: <20131021071220.8650.43280.idtracker@ietfa.amsl.com> <60D5957C-C482-49DB-864F-0623602D3151@fugue.com> <526699F3.20908@mtcc.com> <4254A47D-520F-4C3E-B26B-0FC15E61154A@fugue.com> <5266B09F.9020208@mtcc.com> <5266D1F8.1050609@mtcc.com> <9F27F089-170E-49CE-A9AB-057D947C2BC4@fugue.com> <5266D9A1.2040001@mtcc.com> <5266DE6B.2090000@mtcc.com> <02B569C2-3758-4709-84BD-6DEC23EC57C2@fugue.com> <5266EE8C.5000909@mtcc.com> <4CA27FC5-109B-41A9-8DBA-4264776D27A4@fugue.com> <526701B4.7090308@mtcc.com> <842C4F36-F73E-4C84-8FE0-335F6CF5B2E8@fugue.com> <526703FC.8040804@mtcc.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 Content-Transfer-Encoding: 8BIT X-Mailman-Approved-At: Thu, 24 Oct 2013 08:26:50 -0700 Cc: "homenet@ietf.org" , Michael Thomas , Ted Lemon Subject: Re: [homenet] [DNSOP] Fwd: New Version Notification for draft-mglt-homenet-dnssec-validator-dhc-options-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, 23 Oct 2013 18:03:30 -0000 On Wed, 23 Oct 2013, Daniel Migault wrote: > 2) Security Models > > I am not sure I have been clear enough on the security model or the use case > I am considering in my draft. I hope I am clarifying this point now. > > My device -- say a CPE or smartphone, my PC -- only performs DNSSEC > resolutions, that is to say always perform signature checks, and so MUST > have valid KSKs, even when a emergency key roll over is performed. I am not sure if you need to address emergency rollovers. There are ways using prepublishing of future KSKs to address emergency rollovers. CPE's don't need to know anything about that. You are adding to confusion by using "rollover" and not "emergency rollover" below. Rollovers cause no problems. Well prepared emergency rollovers cause no problem. Badly done emergency rollovers cause inevitable problems for everyone. > Suppose a CPE is attached with a wire connection and performs DNSSEC > validation for my Home Network. Suppose a KSK roll over is performed by > .tld. There are two possibilities: There should be no issue for the CPE. A proper DS will be in the root for the old and new key before they roll. It can validate signatures from the old and the new key. When it rolls, there is no problem. The big problem for CPE's is when they miss a root key rollover because they were on the shelve for a few years. >     - a) information received by the DHCP Server is reliable, >     - b) information received by the DHCP Server is not reliable. If this truly is an emergency rollover that was ill prepared, than the DHCP server is in the same boat at the CPE. No one has the right information. At best you can flush your entire cache and hope DS record at the parent (or root) is valid. > Suppose a smartphone is  attached to a random WLAN AP and a KSK roll over is > performed by .tld. Updating KSKs is necessary. No it's not. See http://tools.ietf.org/html/rfc6781 > Suppose a smartphone attached to your home network WLAN AP or a wire line. > The attachment is secured with WPA2 for example. The smartphone updates its > KSKs the same way the CPE does it. Didn't you just move the problem from the phone to the CPE. Where does the CPE get its update from. How can the CPE trust it? And why can't the phone use the same method? > Suppose the smartphone is attached to a random WLAN AP. The DHCP Server > provides a KSK for the attached domain. This KSK MUST only be used for that > domain and MUST be removed when the smartphone changes its administrative > domain. Right. Now this is the REAL problem that you might be able to solve with DHCP. You enter a split-dns view and the network uses a DNS domain that is not visible in the public view. The smartphone cannot resolve down from its trusted root key to validate this domain. The smartphone and the DHCP server have to agree on a "DNS lie". How to authenticate that? The problem is, the dns domain relayed itself insecurely. Let's say my phone uses some non-FQDN like "mail". When a DHCP network tells me the current LAN domain is "google.com", they can intercept my mail meant to go to google (We have TLS to protect us currently) Worse, if they can convey a trust anchor for "google.com" then they could potentially MITM all my real google connections. (Imagine they put their own TLS key in their local "google.cmo" TLSA record) So if you want to convey a KSK for a dns domain, you need to establish some way for the phone to be able to agree to the domain and trust anchor. Let's assume that the transport is secure (like WPA2 enterprise or whatever) - how does the phone make a choice about the vaildity of the dns dmain received. And when it does, then it can also decide to temporarilly trust that trust anchor. The "temporarilly" bit is done by flushing the cache, which you must do anyway. For example, when I use my VPN to connect to redhat.com, the VPN reconfigures my DNS for "redhat.com" to point to a 10.a.b.c DNS server. I can now resolve internal-only redhat.com names. But also, other DNS names just get their internap IP. bugzilla.redhat.com gets an internal IP address. When I disconnect, I need to access bugzilla.redhat.com by its external IP. Therefor, the VPN software (openswan/libreswan) and NetworkManager (for openvpn/vpnc) flush the cache and request-list whenever the VPN comes up or goes down. > Remarks: >    - a) We need to define what a Trusted DHCP Server is. Yes. I would try something like "one you physically connect to, or use a password for (eg wireless)". By connecting to such a network, the user implicitely conveys trust in the dhcp server. (however, it should still do due diligene before accepting random domains and trust anchors but I don't know how it can do that) >    - b) KSKs other than KSKs with local scope are between configuration and > "local" setting for connectivity. I think KSKs other that local scope should never be considered with a possible acception of the root trust anchor. > 3) Trust DHCP Server > > The draft assumes a trust relation between a DHCP Server and a DHCP Client. > Removing the Time Option reduces the necessity of this requirements. Not realy. See above example of a rogue network telling me it is "google.com". > 5) CERT for KSKs > > It seems that some do not like the idea that KSKs are provided via CERT. > First, I agree we should find a CA that is almost unlikely to perform key > roll over. Then, a "KSKs TA office" may be created ;-). It does not exist > yet, so I mentioned ISPs in my draft, but I could have specified any third > party. I have no problem with that. It creates the same problem the root key has. Now you have two such problems. Paul From tjc@ecs.soton.ac.uk Sat Oct 26 00:54:21 2013 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 6A08021F9C7D for ; Sat, 26 Oct 2013 00:54:21 -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 jWCw3LFfcuH8 for ; Sat, 26 Oct 2013 00:54:19 -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 EA71911E8264 for ; Sat, 26 Oct 2013 00:54:18 -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 r9Q7sDQB019023 for ; Sat, 26 Oct 2013 08:54:13 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r9Q7sDQB019023 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1382774053; bh=4e3aZj9IkLm83dqiyglGjSCGBB8=; h=From:Subject:Date:References:To:Mime-Version; b=4s5xITvsmJkdHX5Ef6Jl+6CgZOM5/sLOF5jbxNZwZFEQPSkSwLVGQH4SpJRJbaXvz 4LOdVKcyD+IavBWO3iBxqV+6303KWNJuOHMWHxb17A1cVaIZL0eicFhNeaskN6/MGC VBv4eO6C8g3v+qnsccftc77bz8t7fOaL8H3gFJwU= 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 (valid=N/A) id p9P8sD0959612570Xw ret-id none; Sat, 26 Oct 2013 08:54:13 +0100 Received: from [192.168.1.108] (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 r9Q7s7qT026160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 26 Oct 2013 08:54:08 +0100 From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_03195D78-A3A8-405B-A861-67B3FA53EA20" Date: Sat, 26 Oct 2013 08:54:07 +0100 References: <20131025170640.20750.43877.idtracker@ietfa.amsl.com> <1251F91C-E0D0-452E-B397-BDFDC9818419@ecs.soton.ac.uk> To: "homenet@ietf.org Group" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p9P8sD095961257000; tid=p9P8sD0959612570Xw; 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: r9Q7sDQB019023 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [homenet] Fwd: WG Action: Formed Extensions for Scalable DNS Service Discovery (dnssd) 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, 26 Oct 2013 07:54:21 -0000 --Apple-Mail=_03195D78-A3A8-405B-A861-67B3FA53EA20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, For those who may have missed the announcement, the new dnssd WG has now = been formed, see below. =20 During the BoF phase the group was formerly known as mdnsext. The name = of the mail list has thus also changed from mdnsext@ietf.org to = dnssd@ietf.org (all subsrcibers of the former should have been moved to = the latter). dnssd meets on Friday from 11:00am in Vancouver. The provisional agenda = is here: https://datatracker.ietf.org/meeting/88/agenda/dnssd/ Tim Begin forwarded message: > From: The IESG > Subject: WG Action: Formed Extensions for Scalable DNS Service = Discovery (dnssd) > Date: 25 October 2013 18:06:40 BST > To: IETF-Announce > Cc: dnssd WG > Reply-To: ietf@ietf.org >=20 > A new IETF working group has been formed in the Internet Area. For > additional information please contact the Area Directors or the WG > Chairs. >=20 > Extensions for Scalable DNS Service Discovery (dnssd) > ------------------------------------------------ > Current Status: Proposed WG >=20 > Chairs: > Ralph Droms > Tim Chown >=20 > Assigned Area Director: > Ted Lemon >=20 > Mailing list > Address: dnssd@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dnssd > Archive: http://www.ietf.org/mail-archive/web/dnssd >=20 > Charter: >=20 > Background > ---------- >=20 > Zero configuration networking protocols are currently well suited to > discover services within the scope of a single link. In particular, > the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes > referred to using Apple Computer Inc.'s trademark, Bonjour) are > widely used for DNS-based service discovery and host name resolution > on a single link. >=20 > The DNS-SD/mDNS protocol suite is used in many scenarios including > home, campus, and enterprise networks. However, the zero = configuration > mDNS protocol is constrained to link-local multicast scope by design, > and therefore cannot be used to discover services on remote links. >=20 > In a home network that consists of a single (possibly bridged) link, > users experience the expected discovery behavior; available services > appear because all devices share a common link. However, in = multi-link > home networks (as envisaged by the homenet WG) or in routed campus or > enterprise networks, devices and users can only discover services on > the same link, which is a significant limitation. This has led to > calls, such as the Educause petition, to develop an appropriate = service > discovery solution to span multiple links or to perform discovery = across > a wide area, not necessarily on directly connected links. >=20 > In addition, the "Smart Energy Profile 2 Application Protocol = Standard", > published by ZigBee Alliance and HomePlug Powerline Alliance specifies > the DNS-SD/mDNS protocol suite as the basis for its method of zero > configuration service discovery. However, its use of wireless mesh > multi-link subnets in conjunction with traditional routed networks = will > require extensions to the DNS-SD/mDNS protocols to allow operation > across multiple links. >=20 > The scenarios in which multi-link service discovery is required may > be zero configuration environments, environments where administrative > configuration is supported, or a mixture of the two. >=20 > As demand for service discovery across wider area routed networks > grows, some vendors are beginning to ship proprietary solutions. It > is thus both timely and important that efforts to develop improved,=20 > scalable, autonomous service discovery solutions for routed networks=20= > are coordinated towards producing a single, standards-based solution. >=20 > Working Group Description > ------------------------- >=20 > The focus of the WG is to develop a solution for extended, scalable=20 > DNS-SD. This work is likely to highlight problems and challenges with=20= > naming protocols, as some level of coexistence will be required = between=20 > local zero configuration name services and those forming part of the=20= > global DNS. It is important that these issues are captured and=20 > documented for further analysis; solving those problems is however not=20= > within the scope of this WG. >=20 > The WG will consider the tradeoffs between reusing/extending existing > protocols and developing entirely new ones. It is highly desirable > that any new solution is backwardly compatible with existing = DNS-SD/mDNS > deployments. Any solution developed by the dnssd WG must not conflict > or interfere with the operation of other zero-configuration service = and > naming protocols such as uPnP or LLMNR. Integration with such = protocols > is out of scope for this WG. >=20 > Current zero configuration discovery protocols are constrained to > operate within a single link, which implicitly limits the scope of > discovery. In extending service discovery protocols to operate over > multiple links, devices will inherently become discoverable over a > wider area, which may introduce security or privacy concerns. The WG > will consider such concerns when exploring the solution space for > multi-link service discovery. >=20 > To that end, the primary goals of the dnssd WG are as follows: >=20 > 1. To document a set of requirements for scalable, autonomous > DNS-based service discovery in routed, multi-link networks in the > following five scenarios: >=20 > (A) Personal Area networks, e.g., one laptop and one printer. > This is the simplest example of a service discovery network, > and may or may not have external connectivity.=20 > =20 > (B) Home networks, as envisaged by the homenet WG, consisting of=20 > one or more exit routers, with one or more upstream providers=20 > or networks, and an arbitrary internal topology with=20 > heterogeneous media where routing is automatically configured.=20= > The home network would typically be a single zero configuration=20= > administrative domain with a relatively limited number of=20 > devices.=20 > =20 > (C) Wireless 'hotspot' networks, which may include wireless networks > made available in public places, or temporary or permanent > infrastructures targeted towards meeting or conference style > events, e.g., as provided for IETF meetings. In such > environments other devices may be more likely to be 'hostile' > to the user. >=20 > (D) Enterprise networks, consisting of larger routed networks,=20 > with large numbers of devices, which may be deployments=20 > spanning over multiple sites with multiple upstreams, and > one more more administrative domains (depending on internal > administrative delegation). The large majority of the=20 > forwarding and security devices are configured. These may > be commercial or academic networks, with differing levels=20 > of administrative control over certain devices on the network, > and BYOD devices commonplace in the campus scenario. >=20 > (E) Mesh networks such as RPL/6LoWPAN, with one or more links per > routable prefix, which may or may not have external = connectivity. > The topology may use technologies including 802.11 wireless,=20 > HomePlug AV and GP, and ZigBee IP.=20 >=20 > In the above scenarios, the aim is to facilitate service discovery=20= > across the defined site. It is also desirable that a user or = device,=20 > when away from such a site, is still able to discover services=20 > within that site, e.g. a user discovering services in their home=20 > network while remote from it. >=20 > It is also desirable that multiple discovery scopes are supported, > from the point of view of either performing discovery within a=20 > specified scope or advertisement within a specified scope, and=20 > being able to discover (enumerate) the set of scopes such that=20 > an application could then choose to do either. It should be noted > that scope in this sense might refer to 'building' or 'room' and = thus=20 > might have no correlation to network topology. >=20 > 2. To develop an improved, scalable solution for service discovery=20 > that can operate in multi-link networks, where devices may be > in neighboring or non-neighboring links, applicable to > the scenarios above. The solution will consider tradeoffs between > reusing/extending existing protocols and developing entirely new > protocols.=20 >=20 > The solution should include documentation or definition of the > interfaces that can be implemented, separately to transport of=20 > the information. >=20 > 3. To document challenges and problems encountered in the coexistence=20= > of zero configuration and global DNS name services in such=20 > multi-link networks, including consideration of both the name=20 > resolution mechanism and the namespace. >=20 > It is important that the dnssd WG takes input from stakeholders in > the scenarios it is considering. For example, the homenet WG is > currently evaluating its own requirements for naming and service > discovery; it is up to the homenet WG as to whether it wishes to > recommend adoption of the solution developed in the dnssd WG, but > coordination between the WGs is desirable. >=20 >=20 > Milestones: > Sep 2013 - Formation of the WG > Oct 2013 - Adopt requirements draft as WG document > Jan 2014 - Submit requirements draft to the IESG as an Informational > RFC > Mar 2014 - Adopt wide-area service discovery solution draft as WG > document=20 > Mar 2014 - Adopt Informational document on the problems and = challenges > arising for zeroconf and unicast DNS name services > Sep 2014 - Submit wide-area service discovery solution draft to the > IESG as Standards Track RFC=20 > Sep 2014 - Submit the zeroconf and unicast DNS "problems and > challenges" draft to the IESG as Informational. >=20 >=20 --Apple-Mail=_03195D78-A3A8-405B-A861-67B3FA53EA20 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

For those who may have missed = the announcement, the new dnssd WG has now been formed, see below. =  

During the BoF phase the group was = formerly known as mdnsext.  The name of the mail list has thus also = changed from mdnsext@ietf.org to = dnssd@ietf.org (all subsrcibers of = the former should have been moved to the = latter).

dnssd meets on Friday from 11:00am in = Vancouver. The provisional agenda is here:

Ti= m

Begin forwarded message:

From: The IESG <iesg-secretary@ietf.org>
Subject: = WG Action: Formed = Extensions for Scalable DNS Service Discovery = (dnssd)
Date: = 25 October 2013 = 18:06:40 BST
To: = IETF-Announce <ietf-announce@ietf.org>
<= /span>
Cc: = dnssd WG <dnssd@ietf.org>
Reply-To: ietf@ietf.org

A= new IETF working group has been formed in the Internet Area. = For
additional information please contact the Area Directors or the = WG
Chairs.

Extensions for Scalable DNS Service Discovery =  (dnssd)
------------------------------------------------
Curre= nt Status: Proposed WG

Chairs:
 Ralph Droms <rdroms.ietf@gmail.com>
=  Tim Chown <tjc@ecs.soton.ac.uk>

Ass= igned Area Director:
 Ted Lemon <ted.lemon@nominum.com>
Mailing list
 Address: dnssd@ietf.org
 To = Subscribe: https://www.ietf.org/= mailman/listinfo/dnssd
 Archive: http://www.ietf.org/ma= il-archive/web/dnssd

Charter:

Background
----------
Zero configuration networking protocols are currently well suited = to
discover services within the scope of a single link.  In = particular,
the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite = (sometimes
referred to using Apple Computer Inc.'s trademark, = Bonjour) are
widely used for DNS-based service discovery and host = name resolution
on a single link.

The DNS-SD/mDNS protocol = suite is used in many scenarios including
home, campus, and = enterprise networks.  However, the zero configuration
mDNS = protocol is constrained to link-local multicast scope by design,
and = therefore cannot be used to discover services on remote links.

In = a home network that consists of a single (possibly bridged) = link,
users experience the expected discovery behavior; available = services
appear because all devices share a common link. =  However, in multi-link
home networks (as envisaged by the = homenet WG) or in routed campus or
enterprise networks, devices and = users can only discover services on
the same link, which is a = significant limitation.  This has led to
calls, such as the = Educause petition, to develop an appropriate service
discovery = solution to span multiple links or to perform discovery across
a wide = area, not necessarily on directly connected links.

In addition, = the "Smart Energy Profile 2 Application Protocol Standard",
published = by ZigBee Alliance and HomePlug Powerline Alliance specifies
the = DNS-SD/mDNS protocol suite as the basis for its method of = zero
configuration service discovery.  However, its use of = wireless mesh
multi-link subnets in conjunction with traditional = routed networks will
require extensions to the DNS-SD/mDNS protocols = to allow operation
across multiple links.

The scenarios in = which multi-link service discovery is required may
be zero = configuration environments, environments where = administrative
configuration is supported, or a mixture of the = two.

As demand for service discovery across wider area routed = networks
grows, some vendors are beginning to ship proprietary = solutions.  It
is thus both timely and important that efforts to = develop improved,
scalable, autonomous service discovery solutions = for routed networks
are coordinated towards producing a single, = standards-based solution.

Working Group = Description
-------------------------

The focus of the WG is = to develop a solution for extended, scalable
DNS-SD.  This work = is likely to highlight problems and challenges with
naming = protocols, as some level of coexistence will be required between =
local zero configuration name services and those forming part of the =
global DNS.  It is important that these issues are captured and =
documented for further analysis; solving those problems is however = not
within the scope of this WG.

The WG will consider the = tradeoffs between reusing/extending existing
protocols and developing = entirely new ones.  It is highly desirable
that any new solution = is backwardly compatible with existing DNS-SD/mDNS
deployments. =  Any solution developed by the dnssd WG must not conflict
or = interfere with the operation of other zero-configuration service = and
naming protocols such as uPnP or LLMNR.  Integration with = such protocols
is out of scope for this WG.

Current zero = configuration discovery protocols are constrained to
operate within a = single link, which implicitly limits the scope of
discovery. In = extending service discovery protocols to operate over
multiple links, = devices will inherently become discoverable over a
wider area, which = may introduce security or privacy concerns. The WG
will consider such = concerns when exploring the solution space for
multi-link service = discovery.

To that end, the primary goals of the dnssd WG are as = follows:

1. To document a set of requirements for scalable, = autonomous
  DNS-based service discovery in routed, = multi-link networks in the
  following five = scenarios:

  (A) Personal Area networks, e.g., one = laptop and one printer.
      This is = the simplest example of a service discovery network,
=       and may or may not have external = connectivity.
=       
  (B) Home networks, = as envisaged by the homenet WG, consisting of
=       one or more exit routers, with one = or more upstream providers
      or = networks, and an arbitrary internal topology with
=       heterogeneous media where routing is = automatically configured.
      The = home network would typically be a single zero configuration
=       administrative domain with a = relatively limited number of
=       devices.
=    
  (C) Wireless 'hotspot' networks, = which may include wireless networks
=       made available in public places, or = temporary or permanent
=       infrastructures targeted towards = meeting or conference style
=       events, e.g., as provided for IETF = meetings.  In such
=       environments other devices may be = more likely to be 'hostile'
      to = the user.

  (D) Enterprise networks, consisting of = larger routed networks,
      with = large numbers of devices, which may be deployments
=       spanning over multiple sites with = multiple upstreams, and
      one more = more administrative domains (depending on internal
=       administrative delegation). =  The large majority of the
=       forwarding and security devices are = configured.  These may
      be = commercial or academic networks, with differing levels
=       of administrative control over = certain devices on the network,
=       and BYOD devices commonplace in the = campus scenario.

  (E) Mesh networks such as = RPL/6LoWPAN, with one or more links per
=       routable prefix, which may or may = not have external connectivity.
=       The topology may use technologies = including 802.11 wireless,
=       HomePlug AV and GP, and ZigBee IP. =

  In the above scenarios, the aim is to facilitate = service discovery
  across the defined site.  It is = also desirable that a user or device,
  when away from = such a site, is still able to discover services
  within = that site, e.g. a user discovering services in their home
=   network while remote from it.

  It is also = desirable that multiple discovery scopes are supported,
=   from the point of view of either performing discovery within = a
  specified scope or advertisement within a specified = scope, and
  being able to discover (enumerate) the set = of scopes such that
  an application could then choose to = do either. It should be noted
  that scope in this sense = might refer to 'building' or 'room' and thus
  might have = no correlation to network topology.

2. To develop an improved, = scalable solution for service discovery
  that can = operate in multi-link networks, where devices may be
  in = neighboring or non-neighboring links, applicable to
  the = scenarios above.  The solution will consider tradeoffs between
=   reusing/extending existing protocols and developing entirely = new
  protocols.

  The solution should = include documentation or definition of the
  interfaces = that can be implemented, separately to transport of
  the = information.

3. To document challenges and problems encountered = in the coexistence
  of zero configuration and global DNS = name services in such
  multi-link networks, including = consideration of both the name
  resolution mechanism and = the namespace.

It is important that the dnssd WG takes input from = stakeholders in
the scenarios it is considering.  For example, = the homenet WG is
currently evaluating its own requirements for = naming and service
discovery; it is up to the homenet WG as to = whether it wishes to
recommend adoption of the solution developed in = the dnssd WG, but
coordination between the WGs is = desirable.


Milestones:
 Sep 2013 - Formation of the = WG
 Oct 2013 - Adopt requirements draft as WG document
=  Jan 2014 - Submit requirements draft to the IESG as an = Informational
RFC
 Mar 2014 - Adopt wide-area service = discovery solution draft as WG
document
 Mar 2014 - Adopt = Informational document on the problems and challenges
arising for = zeroconf and unicast DNS name services
 Sep 2014 - Submit = wide-area service discovery solution draft to the
IESG as Standards = Track RFC
 Sep 2014 - Submit the zeroconf and unicast DNS = "problems and
challenges" draft to the IESG as = Informational.



= --Apple-Mail=_03195D78-A3A8-405B-A861-67B3FA53EA20--