From nobody Mon Jun 2 09:53:16 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEA61A0360 for ; Mon, 2 Jun 2014 09:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87SG0niCrrB0 for ; Mon, 2 Jun 2014 09:53:14 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B104E1A0241 for ; Mon, 2 Jun 2014 09:53:13 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so5461203wev.19 for ; Mon, 02 Jun 2014 09:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=XCe1BUA7hM8e6WUkxE0WY2g3XPTLRSczl+3NzCDVQFI=; b=uah0Id/zTHo4P0wwCOYpur86TDe5xV5+MRsItDX9fY56InMgFDHnZEvGf3fkHWPxON LEtu3HNV/Nbrg37TaDOhgklhspB1OVmPEG3Jjcyn8VWvar+ZiuCSWwIWspw8BQay/t6k BZXi+gy2wi4ON0xXVs0P+bwOKyi9bla+PvH9uapMYGFMYyXfhg/+XYVQ68kjLmB1rd/K mWUyBjtNPma+IwM0LW6TLEA5c3ae/LUCR0FU8em8EQGmlvblw28tvmu/OBC7+Do5zzZs 9ny3b0AmJqezqrISXgtmgPPJy84/nbzkOHmiuj8HViZ/JWLu0CNLQBvra3YLJ2ypZBX3 oAlw== MIME-Version: 1.0 X-Received: by 10.194.57.225 with SMTP id l1mr51907406wjq.25.1401727986612; Mon, 02 Jun 2014 09:53:06 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.222.7 with HTTP; Mon, 2 Jun 2014 09:53:06 -0700 (PDT) In-Reply-To: <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> Date: Mon, 2 Jun 2014 09:53:06 -0700 X-Google-Sender-Auth: Lxxlk9D3fRtvjBGDaaBLm5VGZog Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/w2QTAzlj2kK8ZNUuMb_hRrNBe7A Cc: dhcwg Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:53:15 -0000 At Fri, 30 May 2014 20:47:12 -0400, Ted Lemon wrote: > > I think it is important to add a section that enumerates those and > > similar use cases. Otherwise you risk that this work will be stalled > > and you'd be asked to write a separate problem statement document. > > A use case can't be theoretical. You should have an actual use for it. I fully agree, but then I'd wonder if all we can come up with is theoretical use cases how we can define an effective solution to them. > So I think documenting use cases like a "high security network" is pointl= ess. The point of this mechanism is to authenticate DHCP transactions in = both directions using public keys. Why do we need a list of use cases for= this? This is something we've been asked for for over a decade. Does s= omeone seriously think there's a different way to do this that's more appro= priate? If so, please explain! Does someone think that the actual uses = documented in the draft won't work? If so, please say why. I didn't know if this (=3D "authenticating DHCP transactions in both directions using public keys", correct?) is something people have asked for over a decade, but if so, I'd like to know why they've been asking for it, since, once I read this particular draft carefully I realize that's not clear to me at all. Defining a mechanism simply because someone(s) asked for it without clear understanding of "why" doesn't make sense to me. One possibility is that I'm too dumb and can't just understand something so obvious to others, in which case I'll simply shut up. But, the fact that at least two others wanted to have use cases seems to suggest that at least it's not only me who can't fully understand why we need it. And, if at least three people have difficulty in understanding it, that probably means there are potentially may more. So, I think this has to be documented somewhere explicitly. Whether it should be in the protocol document is a different question, though, so... > I certainly think that if people want to suggest ways of clarifying the d= ocument, that would be beneficial, but let's not get carried away throwing = the kitchen sink into the document for no good reason. That makes it slow= er to review and is as likely to generate controversy as quell it. ...this is fine, but in that case I'd like to see the separate discussion and documentation first, as I already said in an earlier message of mine: http://www.ietf.org/mail-archive/web/dhcwg/current/msg15520.html It doesn't make sense to me to defer the clarification of "why" because it slows to review the "solution". But you don't seem to like this idea either, presumably due to the processing delay. My understanding is, hence a brief summary of use cases in this draft as a kind of compromise. If the use cases are so obvious to some people, this can be pretty simple and avoid making the document a kitchen sink. I actually showed one possible outline of this addition: http://www.ietf.org/mail-archive/web/dhcwg/current/msg15526.= html We can then answer the question that many future readers of this document (i.e., why we need this?) would have at the time of its publication. And, we can still minimize the processing delay by avoiding to require a completely separate document to explain the use cases as a prerequisite of the protocol document. I thought it was a reasonable and pragmatic suggestion. But if the majority of the wg still doesn't think it worth doing, we should probably just agree to disagree, and in which case I'll stop at that point; I don't have a strong motivation to prevent its publication. -- JINMEI, Tatuya From nobody Mon Jun 2 13:29:34 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B74A1A0439 for ; Mon, 2 Jun 2014 13:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcFl8tDGL__C for ; Mon, 2 Jun 2014 13:29:30 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C646C1A03F7 for ; Mon, 2 Jun 2014 13:29:29 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id m5so3600610qaj.30 for ; Mon, 02 Jun 2014 13:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pY7atl0/bmhpEsXuyccdmymRnkZluGefQFAoXfKz6GI=; b=1BXsYqhev30slk0LzHHV3s3LNlxZiffXvQez9oKMvvQ7H+dRbGNLwGoG8aurC2BKUq DPiBdkMrv4qVJYdrxairE70s1BRpyAGv2lE0R+NS9yR72rKFfBo9bOhBKXwrJV80sb8s DpmzR1Y3Z71Lg7sF/Xpm8eprXRDefq+g3hRNQumP+f3jv66Y0vtfHWQD0X/JKcVSKK5h fN9eOxQABUhZrsQKQUBaWI/MsRnsDOV14Hni3xl4d6RHVxX4LW98c3GYEPV+RY7zt1ar xnIN7IWSA5BFbT5JSTRrdiEV4nZvYCLdInHRWH3kgypc8road0E9Wup3U2J8110pKenC Z2Sg== X-Received: by 10.140.81.16 with SMTP id e16mr48724648qgd.110.1401740963820; Mon, 02 Jun 2014 13:29:23 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:559c:4366:f1ef:99de? ([2001:420:2481:20:559c:4366:f1ef:99de]) by mx.google.com with ESMTPSA id j53sm9000113qge.36.2014.06.02.13.29.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 13:29:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: Date: Mon, 2 Jun 2014 16:29:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> To: Lemon Ted X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/WN7Vscad-KadXCR_AA4oGcIdg9M Cc: dhcwg , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:29:32 -0000 On Jun 2, 2014, at 12:53 PM 6/2/14, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: > At Fri, 30 May 2014 20:47:12 -0400, > Ted Lemon wrote: >=20 >>> I think it is important to add a section that enumerates those and >>> similar use cases. Otherwise you risk that this work will be stalled >>> and you'd be asked to write a separate problem statement document. >>=20 >> A use case can't be theoretical. You should have an actual use for = it. >=20 > I fully agree, but then I'd wonder if all we can come up with > is theoretical use cases how we can define an effective solution to > them. >=20 >> So I think documenting use cases like a "high security network" is = pointless. The point of this mechanism is to authenticate DHCP = transactions in both directions using public keys. Why do we need a = list of use cases for this? This is something we've been asked for for = over a decade. Does someone seriously think there's a different way to = do this that's more appropriate? If so, please explain! Does someone = think that the actual uses documented in the draft won't work? If so, = please say why. >=20 > I didn't know if this (=3D "authenticating DHCP transactions in both > directions using public keys", correct?) is something people have > asked for over a decade, but if so, I'd like to know why they've been > asking for it, since, once I read this particular draft carefully I > realize that's not clear to me at all. Defining a mechanism simply > because someone(s) asked for it without clear understanding of "why" > doesn't make sense to me. >=20 > One possibility is that I'm too dumb and can't just understand > something so obvious to others, in which case I'll simply shut up. I'm willing to agree that I'm off in the weeds. But I haven't been = convinced, yet. I think the purpose of authentication is to provide trustworthy DHCP = transactions. That trustworthiness depends on both the authenticate = messages and the trust of the other endpoint. I think the document = could use some more words about that nuance. Doesn't have to be use cases, per se, and the document certainly = shouldn't dictate where authentication is useful and where it isn't. = Jinmei-san has more precisely described the thread I've been trying to = pull on, which is "why authenticate" and "under what circumstances does = this mechanism answer the question 'why authenticate'". >=20 > But, the fact that at least two others wanted to have use cases seems > to suggest that at least it's not only me who can't fully understand > why we need it. And, if at least three people have difficulty in > understanding it, that probably means there are potentially may more. > So, I think this has to be documented somewhere explicitly. Whether > it should be in the protocol document is a different question, though, > so... >=20 >> I certainly think that if people want to suggest ways of clarifying = the document, that would be beneficial, but let's not get carried away = throwing the kitchen sink into the document for no good reason. That = makes it slower to review and is as likely to generate controversy as = quell it. >=20 > ...this is fine, but in that case I'd like to see the separate > discussion and documentation first, as I already said in an earlier > message of mine: > http://www.ietf.org/mail-archive/web/dhcwg/current/msg15520.html > It doesn't make sense to me to defer the clarification of "why" > because it slows to review the "solution". >=20 > But you don't seem to like this idea either, presumably due to the > processing delay. My understanding is, hence a brief summary of use > cases in this draft as a kind of compromise. If the use cases are so > obvious to some people, this can be pretty simple and avoid making the > document a kitchen sink. I actually showed one possible outline of > this addition: = http://www.ietf.org/mail-archive/web/dhcwg/current/msg15526.html > We can then answer the question that many future readers of this > document (i.e., why we need this?) would have at the time of its > publication. And, we can still minimize the processing delay by > avoiding to require a completely separate document to explain the use > cases as a prerequisite of the protocol document. I just re-read = http://www.ietf.org/mail-archive/web/dhcwg/current/msg15526.html I very much like your categorization of applicability considerations, = which address "why authenticate" and "considerations for each case". >=20 > I thought it was a reasonable and pragmatic suggestion. But if the > majority of the wg still doesn't think it worth doing, we should > probably just agree to disagree, and in which case I'll stop at that > point; I don't have a strong motivation to prevent its publication. In my opinion, the suggestion was, indeed, reasonable and pragmatic. I, = too, am willing to drop the discussion if the WG feels otherwise. - Ralph >=20 > -- > JINMEI, Tatuya >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jun 2 13:53:07 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DB51A040A for ; Mon, 2 Jun 2014 13:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OLq-wkcI4_s for ; Mon, 2 Jun 2014 13:53:02 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43181A03DF for ; Mon, 2 Jun 2014 13:53:02 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 8288D1B8078 for ; Mon, 2 Jun 2014 13:52:57 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 5AE6A19005C; Mon, 2 Jun 2014 13:52:57 -0700 (PDT) Received: from [10.1.10.98] (173.162.205.174) by CAS-01.WIN.NOMINUM.COM (64.89.228.131) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Jun 2014 13:52:57 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ted Lemon In-Reply-To: Date: Mon, 2 Jun 2014 16:52:54 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> To: Ralph Droms X-Mailer: Apple Mail (2.1878.2) X-Originating-IP: [173.162.205.174] Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/5D82bdQhREHDC1lasMvHGT3jxVY Cc: dhcwg , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 20:53:05 -0000 I have no personal objection to Jinmei's text, although I think it's = incomplete. Could you guys work with Sheng to see if you can come up = with a mutually agreeable update? From nobody Mon Jun 2 22:55:34 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8981A00D8 for ; Mon, 2 Jun 2014 22:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWhFqCzGVkrT for ; Mon, 2 Jun 2014 22:55:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB601A00CF for ; Mon, 2 Jun 2014 22:55:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEU72363; Tue, 03 Jun 2014 05:55:25 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 06:54:36 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Jun 2014 06:55:24 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 3 Jun 2014 13:55:15 +0800 From: Sheng Jiang To: Ted Lemon , Ralph Droms Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18 Thread-Index: AQHPY9fqOkQX2Up+wk+VaPjsYGUK15tZT5yAgAA2TwCABDKIAIAAPGmAgAAGlwCAARwosA== Date: Tue, 3 Jun 2014 05:55:14 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE88462@nkgeml512-mbx.china.huawei.com> References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> In-Reply-To: Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/HYDbItZA2iO0nUQH5n2fIs-v0mc Cc: dhcwg , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 05:55:33 -0000 VGhlIGF1dGhvcnMgcGxhbiB0byBwcm9kdWNlIGFuIHVwZGF0ZSB2ZXJzaW9uLCB3aGljaCBhZGRy ZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGR1cmluZyB0aGUgV0dMQywgaW4gdHdvIHdlZWtz LiBUaGUgImFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IiB3b3VsZCBiZSBtYWpvciB0YXJnZXQgaW4g dGhpcyB1cGRhdGUuIFdlIHdpbGwgY29tZSB1cCB3aXRoIGEgcHJvcG9zYWwgdGV4dCBhbmQgaW52 b2tlIGRpc2N1c3Npb24gaW4gZW1haWwgbGlzdCBpbiBhIGNvdXBsZSBvZiBkYXlzLg0KDQpCZXN0 IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206 IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBM ZW1vbg0KPlNlbnQ6IFR1ZXNkYXksIEp1bmUgMDMsIDIwMTQgNDo1MyBBTQ0KPlRvOiBSYWxwaCBE cm9tcw0KPkNjOiBkaGN3Zzsg56We5piO6YGU5ZOJDQo+U3ViamVjdDogUmU6IFtkaGN3Z10gV0dM QyBmb3IgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYtMDIgLSBSZXNwb25kIGJ5IE1heQ0KPjE4DQo+ DQo+SSBoYXZlIG5vIHBlcnNvbmFsIG9iamVjdGlvbiB0byBKaW5tZWkncyB0ZXh0LCBhbHRob3Vn aCBJIHRoaW5rIGl0J3MgaW5jb21wbGV0ZS4NCj5Db3VsZCB5b3UgZ3V5cyB3b3JrIHdpdGggU2hl bmcgdG8gc2VlIGlmIHlvdSBjYW4gY29tZSB1cCB3aXRoIGEgbXV0dWFsbHkNCj5hZ3JlZWFibGUg dXBkYXRlPw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ZGhjd2cgbWFpbGluZyBsaXN0DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= From nobody Tue Jun 3 09:19:44 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD8F1A0310 for ; Tue, 3 Jun 2014 09:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUsrEVbvhDNi for ; Tue, 3 Jun 2014 09:19:38 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53051A02FC for ; Tue, 3 Jun 2014 09:19:36 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so7124993wes.9 for ; Tue, 03 Jun 2014 09:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AP6paJ8VIVKa/9E4oL99zG4lOvfNkG1IqXTH5XVunqg=; b=EByREnI8ZqjlrLwnch/hWayCLx4NM7wOAU9j+KFP0j1fjq6Y/nOk6OdKCIn4xT8sVh LMHcTJZm9sey0cywvx/U0wfwOb1xyCIOH9nA14kIKbGXFluvKjng+YR1Vab1Da20h8B0 XCBYZNjb4OcG8x5PV8LHax98NKfPqPHwQNuUMXP11aSh1qUdgkCPr3eOCvTWe3iLqJ56 bLrWc7d2IIs+pu/HXRmLnt64VXuehCO4WnUaHO1jLKRbsS4AIfsz9wRiL3nxeCL2Pzpf SDUan/fzMboCup0q6UELVDp730hSKeTqqEKBQA0ou1AHzjcm8gxObaUJ1ggbh2XdwsrT Mqkw== X-Received: by 10.194.200.65 with SMTP id jq1mr39817389wjc.33.1401812369668; Tue, 03 Jun 2014 09:19:29 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id je7sm4105956wic.14.2014.06.03.09.19.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Jun 2014 09:19:28 -0700 (PDT) Message-ID: <538DF58E.9030708@gmail.com> Date: Tue, 03 Jun 2014 18:19:26 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dhcwg References: <535FEDAD.5010103@gmail.com> In-Reply-To: <535FEDAD.5010103@gmail.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140603181926268 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/zkd1myvTPONzkcHpQHeKiUXqsDw Subject: [dhcwg] WGLC summary for draft-ietf-dhc-sedhcpv6-02 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 16:19:40 -0000 On 29.04.2014 20:21, Tomek Mrugalski wrote: > The draft is available here: > http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-02 > > Please send your comments by May 18th 2014. If you do not feel this > document should advance, please state your reasons why. It took us a bit longer to wrap this up, but here is goes. We received quite a few insightful comments and had a decent discussion following up. Number of issues were raised, but the the comments were supportive in general as nobody objected that work. Even though this WGLC technically passed, authors will need to update their draft. One particular area that requires some work is an applicability statement. Once updated rev is posted, we will do another WGLC to confirm that those changes addresses raised issues adequately. Just a heads up for the authors: I know that Francis Dupont will do the review of this draft as part of the GEN-ART review. He only had time to casually look at it so far, but has some crypto related comments. I'm not aware of the details, though. We'll have to wait and see when he posts his comments to the ML. Hopefully, that will happen next week. Bernie & Tomek From nobody Tue Jun 3 13:39:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CE51A0348; Tue, 3 Jun 2014 13:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0XPPgPYGRJB; Tue, 3 Jun 2014 13:39:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7891A0344; Tue, 3 Jun 2014 13:39:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140603203940.8397.21502.idtracker@ietfa.amsl.com> Date: Tue, 03 Jun 2014 13:39:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/EQ6CrL4IYzgmqpfV2XMTUjGd0ec Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-active-leasequery-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 20:39:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Active DHCPv4 Lease Query Authors : Kim Kinnear Mark Stapp Bernie Volz Neil Russell Filename : draft-ietf-dhc-dhcpv4-active-leasequery-01.txt Pages : 22 Date : 2014-06-03 Abstract: The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been extended with a Leasequery capability that allows a client to request information about DHCPv4 bindings. That mechanism is limited to queries for individual bindings. In some situations individual binding queries may not be efficient, or even possible. In addition, continuous update of an external client with Leasequery data is sometimes desired. This document expands on the DHCPv4 Leasequery protocol, and allows for active transfer of near real-time DHCPv4 address binding information data via TCP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-active-leasequery/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-active-leasequery-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-active-leasequery-01 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 nobody Tue Jun 3 14:07:00 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB0D1A01A8 for ; Tue, 3 Jun 2014 14:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3Zaae_HV1Pc for ; Tue, 3 Jun 2014 14:06:58 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB571A0370 for ; Tue, 3 Jun 2014 14:06:57 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so7318542wgh.23 for ; Tue, 03 Jun 2014 14:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mLP/F+tGH6mgG2tckzlfMBbbwVslK5UHNeKdT45DQwE=; b=TAwkUaD3PQ4S/QElCOHApQV+cgpDoOeRzTY2b3uheBVv8WuJi8d/qvo9OkkNftJTMP J5X+0mSPBueDusO9mGk+5cd3c5OtFGK6FIXEFFpbAckzJwlyYJQNjKk79L7GRAMqUQJ8 QG3D/cyUzsMl4R/RcJsYpwOtUddbnOGlZ/DLTnN+4G3Q2/06Olzen8XsnUF9FBvh6YCj VcEpeUHJ2GfoA1rkRI7MZ+wVjaT+KZq4HQXQJOFEIniFXgkA6ekekqYqU7o8iRgM9N6M yGn7R0aIEl67QZFiQrUrABi+Z8o+XUlN7+dvx/awPYX53bk4T9dIcnR7cNl8tskAdcaR orZg== MIME-Version: 1.0 X-Received: by 10.194.57.208 with SMTP id k16mr63714953wjq.51.1401829609859; Tue, 03 Jun 2014 14:06:49 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.222.7 with HTTP; Tue, 3 Jun 2014 14:06:49 -0700 (PDT) In-Reply-To: References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> Date: Tue, 3 Jun 2014 14:06:49 -0700 X-Google-Sender-Auth: hrfnFosqLwzsxumG9-doW9J_JIE Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ted Lemon Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/3UKzPQUW8EgjnkW2Gl8gWBqxcu0 Cc: dhcwg , Ralph Droms Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 21:06:59 -0000 At Mon, 2 Jun 2014 16:52:54 -0400, Ted Lemon wrote: > I have no personal objection to Jinmei's text, although I think it's > incomplete. Could you guys work with Sheng to see if you can come > up with a mutually agreeable update? I'm happy to do that. I've seen a followup message from the draft authors with the plan of starting the discussion, so I think we can continue this topic there. -- JINMEI, Tatuya From nobody Wed Jun 4 05:37:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794761A01D2 for ; Wed, 4 Jun 2014 05:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RE4nJfbZIfZ1 for ; Wed, 4 Jun 2014 05:37:31 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA8D1A01B9 for ; Wed, 4 Jun 2014 05:37:30 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id i50so15571094qgf.3 for ; Wed, 04 Jun 2014 05:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HhKfwwU0VsgzvbuOjNWdA8xj8nmxP429z7URkhM4iVI=; b=kYgm5PtvnI0vflnhWGSXipfSS6FF1XLHIAxMS9hdu9lp46HgAWFEQp1VuiCVpa1+YG Nl8fbV4Wi7WDnVEyCMayV3lFmGuHeuTQS9B6+Y8DVxGu4825FQO4vubM0Fj1j+v7+bWG Nf3nMC/pfdorFAlks2lP0EjVkG/qWObd8N/b7LGwCCKDBjEo4lsMBOuXKLUy8AGeGFwF ToxXWawy4N0da7ZhZf7hugCH/IGbq+MNQvzw4kc6E22XJhydOUP54N9Dlrpnmyx1pTAS tznDiVAhX0dxtD5i/6NF91LWXvqqm1F7nBP5+6AgDfcc/qRSxp/JdUMwGTJB5Z0PR7uh gU+Q== X-Received: by 10.140.25.37 with SMTP id 34mr67369115qgs.60.1401885444319; Wed, 04 Jun 2014 05:37:24 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:6ce4:3700:86c8:1597? ([2001:420:2481:20:6ce4:3700:86c8:1597]) by mx.google.com with ESMTPSA id d9sm3977009qac.15.2014.06.04.05.37.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 05:37:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: Date: Wed, 4 Jun 2014 08:37:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5F38B14A-07F6-4788-B82A-159CEF99EF32@gmail.com> References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> To: Lemon Ted X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/VV3LJP-ESdahWgdA-fRysYoElFY Cc: dhcwg , =?utf-8?B?56We5piO6YGU5ZOJ?= Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-02 - Respond by May 18 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 12:37:32 -0000 On Jun 3, 2014, at 5:06 PM 6/3/14, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: > At Mon, 2 Jun 2014 16:52:54 -0400, > Ted Lemon wrote: >=20 >> I have no personal objection to Jinmei's text, although I think it's >> incomplete. Could you guys work with Sheng to see if you can come >> up with a mutually agreeable update? >=20 > I'm happy to do that. I've seen a followup message from the draft > authors with the plan of starting the discussion, so I think we can > continue this topic there. I'll participate in that discussion, as well. - Ralph >=20 > -- > JINMEI, Tatuya From nobody Wed Jun 4 14:01:00 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DEA1A0309; Wed, 4 Jun 2014 14:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTsiiGX5CSiq; Wed, 4 Jun 2014 14:00:42 -0700 (PDT) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8451A03A1; Wed, 4 Jun 2014 14:00:26 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 0D2EA84025A; Wed, 4 Jun 2014 16:00:20 -0500 (CDT) Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id g9bZ--ztJAmj; Wed, 4 Jun 2014 16:00:16 -0500 (CDT) Received: from localhost (localhost [IPv6:::1]) by mail.pt.net (Postfix) with ESMTP id 31B6B84030D; Wed, 4 Jun 2014 16:00:16 -0500 (CDT) X-Virus-Scanned: amavisd-new at mail.pt.net Received: from mail.pt.net ([IPv6:::1]) by localhost (mail.pt.net [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id K41YPDcZVYAz; Wed, 4 Jun 2014 16:00:16 -0500 (CDT) Received: from mail.pt.net (mail.pt.net [206.210.194.11]) by mail.pt.net (Postfix) with ESMTP id 687A18402E7; Wed, 4 Jun 2014 16:00:14 -0500 (CDT) From: Lewis Donzis To: , References: <20140603203940.8397.21502.idtracker@ietfa.amsl.com> Date: Wed, 4 Jun 2014 16:00:14 -0500 (CDT) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraConnectorForOutlook/8.0.6.1063) In-Reply-To: <20140603203940.8397.21502.idtracker@ietfa.amsl.com> Thread-Index: M9seEj+i4K+ZAWjVYBWO2qc66yrpVQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Topic: I-D Action: draft-ietf-dhc-dhcpv4-active-leasequery-01.txt Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/PaE3B27_M8XgUGQQNnJYq0a5yDg Cc: dhcwg@ietf.org Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-active-leasequery-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 21:00:47 -0000 I am happy to see the changes that we requested incorporated into this draft. Thanks very much! lew > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, June 03, 2014 3:40 PM > To: i-d-announce@ietf.org > Cc: dhcwg@ietf.org > Subject: [dhcwg] I-D Action: > draft-ietf-dhc-dhcpv4-active-leasequery-01.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the Dynamic Host Configuration > Working Group of the IETF. > > Title : Active DHCPv4 Lease Query > Authors : Kim Kinnear > Mark Stapp > Bernie Volz > Neil Russell > Filename : draft-ietf-dhc-dhcpv4-active-leasequery-01.txt > Pages : 22 > Date : 2014-06-03 > > Abstract: > The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has been > extended with a Leasequery capability that allows a client > to request > information about DHCPv4 bindings. That mechanism is limited to > queries for individual bindings. In some situations individual > binding queries may not be efficient, or even possible. > In addition, > continuous update of an external client with Leasequery data is > sometimes desired. This document expands on the DHCPv4 Leasequery > protocol, and allows for active transfer of near real-time DHCPv4 > address binding information data via TCP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-active- > leasequery/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-active-leasequery-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-active- > leasequery-01 > > > 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/ > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > From nobody Thu Jun 5 02:39:06 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A080E1A015B for ; Thu, 5 Jun 2014 02:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkPDmLwRUwp3 for ; Thu, 5 Jun 2014 02:39:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEFE1A011F for ; Thu, 5 Jun 2014 02:39:02 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHW16836; Thu, 05 Jun 2014 09:38:55 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 10:38:00 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Jun 2014 10:38:54 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 5 Jun 2014 17:38:42 +0800 From: Sheng Jiang To: Ted Lemon , Ralph Droms , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: Deployment consideration for SeDHCPv6 Thread-Index: AQHPgKHv1Ac5DKV250+NBNKyOimJag== Date: Thu, 5 Jun 2014 09:38:41 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE891C2@nkgeml512-mbx.china.huawei.com> References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AE88462@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AE88462@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/uB0Z8sU40yxRyLtiPrmfcY-hJwk Cc: dhcwg Subject: [dhcwg] Deployment consideration for SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 09:39:05 -0000 SGksIEppbm1laSwgUmFscGgsIFRlZCBhbmQgYWxsLA0KDQpUaGUgYmVsb3cgdGV4dCBpcyB0aGUg cHJvcG9zYWwgZnJvbSBTZURIQ1B2NiBhdXRob3JzIGluIG9yZGVyIHRvIGNsYXJpZnkgdGhlIGFw cGxpY2FiaWxpdHkuIFdlIHBsYW4gdG8gYWRkIHRoZXNlIHRleHQsIG9mIGNvdXJzZSBhZnRlciBy ZWFjaGluZyBjb25zZW5zdXMgaW4gdGhlIG1haWwgbGlzdCwgaW50byB0aGUgbmV4dCB1cGRhdGUg dmVyc2lvbi4gQW55IGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCg0KRGVwbG95bWVudCBjb25z aWRlcmF0aW9uDQoNClRoaXMgZG9jdW1lbnQgaGFzIGRlZmluZWQgdHdvIGxldmVscyBvZiBhdXRo ZW50aWNhdGlvbjogZnVsbCBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiBjZXJ0aWZpY2F0ZSBvciBw cmUtc2hhcmVkIGtleSB2ZXJpZmljYXRpb24gYW5kIHdlYWtlciBhdXRoZW50aWNhdGlvbiBiYXNl ZCBvbiBsZWFwLW9mLWZhaXRoLiBCb3RoIGxldmVscyBjYW4gYmUgYXBwbGllZCBvbiBzZXJ2ZXJz IGFuZCBjbGllbnRzLiBUaGUgZGVwbG95bWVudCBzY2VuYXJpb3MgY2FuIGJlIGNhdGVnb3JpemVk IGFzIGJlbG93Og0KDQrvgawJQXV0aGVudGljYXRpbmcgYSBzZXJ2ZXIgb24gYSBjbGllbnQNCu+B rgkgICAtIEJvdGggZnVsbHkgYXV0aGVudGljYXRpb24gYW5kIGxlYXAtb2YtZmFpdGggY2FuIGJl IHVzZWQuIFRoZSBsYXR0ZXIgaXMgd2Vha2VyLiBCdXQsIGl0IGlzIGJldHRlciB0aGFuIG5vIHBy b3RlY3Rpb24gYnkgbmFycm93aW5nIHRoZSBhdHRhY2sgc2NvcGUuDQoNCu+BrAlBdXRoZW50aWNh dGluZyBhIGNsaWVudCBvbiBhIHNlcnZlcg0K74GuCSAgIC0gV2l0aCBmdWxseSBhdXRoZW50aWNh dGlvbiwgdGhlIHNlcnZlciBjYW4gc2VsZWN0aXZlbHkgc2VydmUgYSBzcGVjaWZpYyBjbGllbnQg KG9yIGRlbnkgc3BlY2lmaWMgY2xpZW50cykuIFRoZSBzZXJ2ZXIgY2FuIHByZXZlbnQgYW4gYXR0 YWNrZXIgZnJvbSBicmVha2luZyBhbiBleGlzdGluZyBESENQdjYgc2Vzc2lvbiBvZiBhIGNsaWVu dC4gVGhlIHNlcnZlciBjYW4gYWxzbyBwcmV2ZW50IGFuIGF0dGFja2VyIGZyb20gcHJldGVuZGlu ZyB0byBiZSBhIHBhc3QgbGVnaXRpbWF0ZSBjbGllbnQuDQrvga4JICAgLSBXaXRoIGxlYXAtb2Yt ZmFpdGggYXV0aGVudGljYXRpb24sIHRoZSBzZXJ2ZXIgY2FuIG9ubHkgcHJldmVudCBhbiBhdHRh Y2tlciBmcm9tIGJyZWFraW5nIGFuIGV4aXN0aW5nIERIQ1B2NiBzZXNzaW9uIG9mIGEgY2xpZW50 IGFuZCBwcmV0ZW5kaW5nIHRvIGJlIGEgcGFzdCBsZWdpdGltYXRlIGNsaWVudC4NCu+BrgkgICAt IEEgc2VydmVyIG1heSBtYWludGFpbiBib3RoIGZ1bGx5IGF1dGhlbnRpY2F0aW9uIGFuZCBsZWFw LW9mLWZhaXRoIGF1dGhlbnRpY2F0aW9uIGF0IHRoZSBzYW1lIHRpbWUuIEluIHN1Y2ggc2NlbmFy aW9zLCB0aGUgY2xpZW50cyBhdXRoZW50aWNhdGVkIHRocm91Z2ggbGVhcC1vZi1mYWl0aCBub3Jt YWxseSBoYXZlIGxvd2VyIHByaW9yaXR5IG9yL2FuZCBsaW1pdGVkIG5ldHdvcmsgYWNjZXNzLiBP bmUgZXhhbXBsZSB3b3VsZCBiZSBpbiBhbiBlbnRlcnByaXNlIG5ldHdvcmssIG9mZmljZSBkZXZp Y2VzIG9yIGVtcGxveWVyc+KAmSBkZXZpY2VzIHVzZWQgZnVsbCBhdXRoZW50aWNhdGlvbiBhcmUg YWxsb3dlZCB0byBhY2Nlc3MgYWxsIG5ldHdvcmsgcmVzb3VyY2VzLCBpbmNsdWRpbmcgdGhlIGlu dGVybmFsIGRhdGFiYXNlOyBkZXZpY2VzIG9mIG9jY2FzaW9uYWwgdmlzaXRvcnMgYWxzbyBnZXQg YXV0aGVudGljYXRlZCwgYnV0IHRocm91Z2ggbGVhcC1vZi1mYWl0aCwgdGhleSBjYW4gb25seSBh Y2Nlc3MgcHVibGljIHdlYiBzZXJ2aWNlcyBvZiB0aGlzIGVudGVycHJpc2UgYW5kIHRoZSBJbnRl cm5ldC4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj5Gcm9tOiBkaGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBTaGVuZyBKaWFuZw0KPlNlbnQ6IFR1ZXNkYXksIEp1bmUgMDMsIDIwMTQgMTo1NSBQ TQ0KPlRvOiBUZWQgTGVtb247IFJhbHBoIERyb21zDQo+Q2M6IGRoY3dnOyDnpZ7mmI7pgZTlk4kN Cj5TdWJqZWN0OiBSZTogW2RoY3dnXSBXR0xDIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0w MiAtIFJlc3BvbmQgYnkgTWF5DQo+MTgNCj4NCj5UaGUgYXV0aG9ycyBwbGFuIHRvIHByb2R1Y2Ug YW4gdXBkYXRlIHZlcnNpb24sIHdoaWNoIGFkZHJlc3NlcyB0aGUNCj5jb21tZW50cyByZWNlaXZl ZCBkdXJpbmcgdGhlIFdHTEMsIGluIHR3byB3ZWVrcy4gVGhlICJhcHBsaWNhYmlsaXR5DQo+c3Rh dGVtZW50IiB3b3VsZCBiZSBtYWpvciB0YXJnZXQgaW4gdGhpcyB1cGRhdGUuIFdlIHdpbGwgY29t ZSB1cCB3aXRoIGENCj5wcm9wb3NhbCB0ZXh0IGFuZCBpbnZva2UgZGlzY3Vzc2lvbiBpbiBlbWFp bCBsaXN0IGluIGEgY291cGxlIG9mIGRheXMuDQo+DQo+QmVzdCByZWdhcmRzLA0KPg0KPlNoZW5n DQo+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IGRoY3dnIFttYWlsdG86 ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBMZW1vbg0KPj5TZW50OiBU dWVzZGF5LCBKdW5lIDAzLCAyMDE0IDQ6NTMgQU0NCj4+VG86IFJhbHBoIERyb21zDQo+PkNjOiBk aGN3Zzsg56We5piO6YGU5ZOJDQo+PlN1YmplY3Q6IFJlOiBbZGhjd2ddIFdHTEMgZm9yIGRyYWZ0 LWlldGYtZGhjLXNlZGhjcHY2LTAyIC0gUmVzcG9uZCBieSBNYXkNCj4+MTgNCj4+DQo+PkkgaGF2 ZSBubyBwZXJzb25hbCBvYmplY3Rpb24gdG8gSmlubWVpJ3MgdGV4dCwgYWx0aG91Z2ggSSB0aGlu ayBpdCdzIGluY29tcGxldGUuDQo+PkNvdWxkIHlvdSBndXlzIHdvcmsgd2l0aCBTaGVuZyB0byBz ZWUgaWYgeW91IGNhbiBjb21lIHVwIHdpdGggYSBtdXR1YWxseQ0KPj5hZ3JlZWFibGUgdXBkYXRl Pw0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+ZGhjd2cgbWFpbGluZyBsaXN0DQo+PmRoY3dnQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZGhjd2cNCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPmRoY3dnIG1haWxpbmcgbGlzdA0KPmRoY3dnQGlldGYu b3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0K From nobody Fri Jun 6 11:51:57 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894741A016C for ; Fri, 6 Jun 2014 11:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8l2ujaFfUHd8 for ; Fri, 6 Jun 2014 11:51:54 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425BB1A0156 for ; Fri, 6 Jun 2014 11:51:54 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id q59so3242522wes.38 for ; Fri, 06 Jun 2014 11:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wBGO4awlAT/3Gp7dp2Wqf4ReOgwKQOmNBbvh7OlCYIY=; b=WcazypuPortMqlguMhbkDFx5V5FWdgdRUb9lF3Osg6ikxGSblFYWsR3Fm16Jvn5QQB nsMCblKVqR5cJX0Wdj81jCDy371v+869Uzv5+BOqQaNVgFcYU+qKuKIXWtPOut9jiLHh ZEYDafNcOh2tWof0OSlUc/jpwfapNpIQGRL6BPiysWRLEvi83dn7mUdDZ7FQGDD39bsa URc7X9PEihOyhBbUJ64q5LxL2manesuGY7GElYVMYrM+Pn6Ra3rNFyIJNhhUbhXj1EcX M5hyvqCRB70q6+YzhVH9NXvJ1uaSfwtalMsPUDoOR+SYfzhoHM7vvl1ZenXxi4QUap7L Irug== MIME-Version: 1.0 X-Received: by 10.194.57.225 with SMTP id l1mr9703038wjq.25.1402080706227; Fri, 06 Jun 2014 11:51:46 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.222.7 with HTTP; Fri, 6 Jun 2014 11:51:46 -0700 (PDT) In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AE891C2@nkgeml512-mbx.china.huawei.com> References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AE88462@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AE891C2@nkgeml512-mbx.china.huawei.com> Date: Fri, 6 Jun 2014 11:51:46 -0700 X-Google-Sender-Auth: 4cjidjLINS23WNIFged4EBQf28Q Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Sheng Jiang Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/c22Tb2bG9OhsklcLlvFPIIuAsO8 Cc: dhcwg , Ted Lemon , Ralph Droms Subject: Re: [dhcwg] Deployment consideration for SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 18:51:56 -0000 At Thu, 5 Jun 2014 09:38:41 +0000, Sheng Jiang wrote: > The below text is the proposal from SeDHCPv6 authors in order to > clarify the applicability. We plan to add these text, of course > after reaching consensus in the mail list, into the next update > version. Any comments are appreciated. The proposed text seems to be almost a minor revise of my outline I showed on the list, so I guess Ted would still complain that it's incomplete:-). I'm not sure how much we should be "complete" in this document (especially if we wouldn't like to make the document a kitchen sink), but I'll show my own try below. Not intending to push this particular text, but I thought I'm responsible for providing something more concrete as someone who keeps raising the point. X. Deployment consideration This document defines two levels of authentication: full authentication based on certificate or pre-shared key verification and weaker authentication based on leap-of-faith (LoF). As a mechanism, both levels can be applied on servers and clients. Depending on the details of expected threats and other constraints, some cases may have limited applicability. This section discusses such details. X.1 Authentication on a client For clients, DHCP authentication generally means authenticating the server (the sender of DHCP messages) and verifying message integrity. This is satisfied with full authentication. Due to the configuration overhead, however, full authentication may not always be feasible. It would still be viable in a controlled environment with skilled stuff, such as a corporate intranet. If LoF is used, message integrity is provided but there is a chance for the client to incorrectly trust a malicious server at the beginning of the first session with the server (and therefore keep trusting it thereafter). But LoF guarantees the subsequent messages are sent by the same server that sent the public key, and therefore narrows the attack scope. This may make sense if the network can be reasonably considered secure and requesting pre-configuration is deemed to be infeasible. A small home network would be an example of such cases. For environments that are neither controlled nor really trustworthy, such as a network cafe, full authentication wouldn't be feasible due to configuration overhead, while pure LoF, i.e. silently trusting the server at the first time, would be too insecure. But some middleground might be justified, such as requiring human intervention at the point of LoF. X.2 Authentication on a server As for authentication on a server, there are several different scenarios to consider, each of which has different applicability issues. A server may have to selectively serve a specific client or deny specific clients depending on the identify of the client. This will require full authentication, since if the server allows LoF any malicious user can pretend to be a new legitimate client. Also, the use of certification wouldn't be feasible in this case, since it's less likely for all such clients to have valid (and generally different) certificates. So the applicable case may be limited, but a controlled environment with skilled stuff and a specifically expected set of clients such as a corporate intranet may still find it useful and viable. A server can prevent an attack on the DHCP session with an existing client from a malicious client, e.g., by sending a bogus Release message: the server would remember the original client's public key at the beginning of the DHCP session and authenticate subsequent messages (and their sender). Neither full authentication nor LoF is needed for this purpose, since the server does not have to trust the public key itself. So this can be generally used for any usage of DHCP. A server can prevent an attack by a malicious client that pretends to be a valid past client and tries to establish a new DHCP session (whether this is a real security threat may be a subject of debate, but this is probably at least annoying). This is similar to the first scenario, but full authentication may not necessarily be required; since the purpose is to confirm a returning client has the same identify as a valid past client, the server only has to remember the client's public key at the first time. So LoF can be used at the risk of allowing a malicious client to mount this attack before the initial session with a valid client. An uncontrolled, but reasonable reliable network like a home network may use this defense with LoF. -- JINMEI, Tatuya From nobody Fri Jun 6 19:38:15 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9EB1A02F1 for ; Fri, 6 Jun 2014 19:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3n3wTBT5KJi for ; Fri, 6 Jun 2014 19:38:10 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF41C1A02AC for ; Fri, 6 Jun 2014 19:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12379; q=dns/txt; s=iport; t=1402108683; x=1403318283; h=from:to:cc:subject:date:message-id:mime-version; bh=3C8GrNLqQ0UVf7EOOQmsF2/O4zAXRXJqF4Bo4hGzv7g=; b=DF4P8qFVkClG2jWHURKdjGNnplZ/5xCuiH15WxL6/XFW87u7UFgYDKA7 9jNsfRFaIlAPuY/JGJUExkQqw9gVspAZTWgf7UAmQtwnTPhuILL0wvK8k maneztarhdsennFBGmkT3bnhLqM8pCh8xDONyXHmPt/zUNzI4N0REkWRo Q=; X-IronPort-AV: E=Sophos; i="4.98,992,1392163200"; d="scan'208,217"; a="50949563" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP; 07 Jun 2014 02:38:01 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s572c05M005763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Jun 2014 02:38:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.16]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 6 Jun 2014 21:38:00 -0500 From: "Bernie Volz (volz)" To: "Dhc Chairs (dhc-chairs@tools.ietf.org)" Thread-Topic: Agenda Items for Toronto (IETF-90, July 20-25) - Stateful Issues Agenda Request Thread-Index: Ac+B+RkPo7B9+LtwSl+WvP1xObpwxw== Date: Sat, 7 Jun 2014 02:38:00 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5A82AD@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.69] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1B5A82ADxmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/whwsQqMbjcbC8c7A82wNFcBhPUY Cc: "dhcwg@ietf.org" , "Ole Troan \(ot@cisco.com\)" Subject: Re: [dhcwg] Agenda Items for Toronto (IETF-90, July 20-25) - Stateful Issues Agenda Request X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 02:38:12 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1B5A82ADxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: I request some time to discuss the still pending DHCPv6 Stateful Issues dra= ft. This will be a fairly significant revision (it is not yet available). Name of session: DHCPv6 Stateful Issues Draft Update Name of draft: draft-ietf-dhc-dhcpv6-stateful-issues Time Requested: 20 minutes Presenter Names: Ole Troan, Marcin Siodelski, Bernie Volz (exact = presenters TBD) Brief Description: Discuss the major changes in the (coming) ne= w version and initiate debate as needed to expedite resolving any concerns = in order to go to WG last-call (either with the new version or the next). T= his work is also critical for DHCPv6bis. - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Wednesday, May 21, 2014 2:42 PM To: dhcwg@ietf.org Subject: [dhcwg] Agenda Items for Toronto (IETF-90, July 20-25) Hi: While still 2 months out, I did want to get folks to start thinking about p= resenting at the DHC WG meeting in Toronto. Please send us (dhc-chairs@tools.ietf.org= ) requests for sessions and include: Name of session: Name of draft(s): Time requested: Presenter name(s): Brief description of what issues need discussing and what you hope to accom= plish by presenting: More details about the Toronto IETF can be found at http://www.ietf.org/mee= ting/90/index.html. - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1B5A82ADxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:<= /p>

 

I request some time to= discuss the still pending DHCPv6 Stateful Issues draft. This will be a fai= rly significant revision (it is not yet available).

 

Name of session: =             DHCPv6 S= tateful Issues Draft Update

Name of draft:  &= nbsp;           &nbs= p;   draft-ietf-dhc-dhcpv6-stateful-issues

Time Requested: &= nbsp;           20 minute= s

Presenter Names: =           Ole Troan, Marcin Si= odelski, Bernie Volz (exact presenters TBD)

Brief Description:&nbs= p;            Discus= s the major changes in the (coming) new version and initiate debate as need= ed to expedite resolving any concerns in order to go to WG last-call (eithe= r with the new version or the next). This work is also critical for DHCPv6bis.<= /p>

 

-&nb= sp;         Bernie

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, May 21, 2014 2:42 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Agenda Items for Toronto (IETF-90, July 20-25)=

 

Hi:

 

While still 2 months out, I did want to get folks to= start thinking about presenting at the DHC WG meeting in Toronto.

 

Please send us (dhc-chairs@tools.ietf.org) requests for sessions and include:<= o:p>

 

Name of session:

Name of draft(s):

Time requested:

Presenter name(s):

Brief description of what issues need discussing and= what you hope to accomplish by presenting:

 

More details about the Toronto IETF can be found at = http://www.ietf.org/meeting/90/index.html.

 

-     &= nbsp;    Tomek & Bernie

--_000_489D13FBFA9B3E41812EA89F188F018E1B5A82ADxmbrcdx04ciscoc_-- From nobody Tue Jun 10 02:26:39 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F601A0390 for ; Tue, 10 Jun 2014 02:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgPbXp49FgeN for ; Tue, 10 Jun 2014 02:26:35 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6AB71A001B for ; Tue, 10 Jun 2014 02:26:34 -0700 (PDT) Received: from [109.144.197.18] (helo=[10.210.205.254]) by cappuccino.rob.sh with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WuIK8-0005ze-5i; Tue, 10 Jun 2014 10:26:32 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_47C73CB1-C97A-409D-A49D-4E031F490AA7" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Rob Shakir In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B04792A@xmb-rcd-x04.cisco.com> Date: Tue, 10 Jun 2014 10:26:34 +0100 Message-Id: <0A8E2C3C-2490-445B-9404-EA1F3BCCF2FD@rob.sh> References: <489D13FBFA9B3E41812EA89F188F018E1B04792A@xmb-rcd-x04.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/XkWtPqM9uS33_eMADBEsCTesUkM Cc: "dhcwg@ietf.org" , Rob Shakir Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues - Section 4.2. Placement of Status Codes X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 09:26:38 -0000 --Apple-Mail=_47C73CB1-C97A-409D-A49D-4E031F490AA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 25 May 2014, at 14:43, Bernie Volz (volz) wrote: > ** ACTION NEEDED FROM YOU: > =20 > Does anyone have any concerns or objections regarding this change? Hi Bernie, First off, thanks to you and your co-authors for looking at this one in = more detail, and the comprehensive write-up. I=92m wholly supportive of = the change that you propose - I think this is the cleanest and most = logical recommendation to make. Kind regards, r. --Apple-Mail=_47C73CB1-C97A-409D-A49D-4E031F490AA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 25 May 2014, at 14:43, Bernie Volz = (volz) <volz@cisco.com> = wrote:

** ACTION NEEDED FROM YOU:
 
Does = anyone have any concerns or objections regarding this = change?

Hi = Bernie,

First off, thanks to you and your = co-authors for looking at this one in more detail, and the comprehensive = write-up. I=92m wholly supportive of the change that you propose - I = think this is the cleanest and most logical recommendation to = make.

Kind = regards,
r.

= --Apple-Mail=_47C73CB1-C97A-409D-A49D-4E031F490AA7-- From nobody Thu Jun 12 08:34:19 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505DE1B2A9E; Thu, 12 Jun 2014 08:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 565JV7Nfr2CM; Thu, 12 Jun 2014 08:34:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F961B2A93; Thu, 12 Jun 2014 08:34:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140612153416.26252.51493.idtracker@ietfa.amsl.com> Date: Thu, 12 Jun 2014 08:34:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/_FQAzXil41YzzpPB5RCn9f2KaFA Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv4-over-dhcpv6-09.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 15:34:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCPv4 over DHCPv6 Transport Authors : Qi Sun Yong Cui Marcin Siodelski Suresh Krishnan Ian Farrer Filename : draft-ietf-dhc-dhcpv4-over-dhcpv6-09.txt Pages : 16 Date : 2014-06-12 Abstract: IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv4-over-dhcpv6-09 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 nobody Fri Jun 13 07:14:05 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4741B2934 for ; Fri, 13 Jun 2014 07:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBli7r4gm9zT for ; Fri, 13 Jun 2014 07:14:02 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0DA1B2869 for ; Fri, 13 Jun 2014 07:14:01 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s5DEDxGn042278 for ; Fri, 13 Jun 2014 16:13:59 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201406131413.s5DEDxGn042278@givry.fdupont.fr> From: Francis Dupont To: dhcwg@ietf.org Date: Fri, 13 Jun 2014 16:13:59 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/0dzYPMAhgn_DCTHONFm4_ajPkUw Subject: [dhcwg] review of draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:14:04 -0000 My colleague and DHC WG chair Tomasz (aka Tomek) Mrugalski asked me to review the last version of the Secure DHCPv6 document. First it is far better than the very first version (obviously the recommendation to look at SeND (RFC 3971) was useful :-), and (I checked at the last IETF meeting) there is no claimed IPR about it. Unfortunately it is still far from to be ready, for instance the section 5.1 Public Key Option page 7 is fully wrong, even in its example (a RSA public key has a second component, the public exponent). But my main concern is the applicability of the certificate stuff (*public key* certificate BTW). The issue is either the node has fully access to the PKI and a pointer (e.g., IKEv2 URI and hash) is simpler/better, or a mechanism has to provide the trust anchor, the certificate chain and crls, etc. It was done in SEND the (very) hard way... In the case of secure DHCPv6 IMHO it should be more efficient to postpone the certificate stuff, so I propose: - drop the certificate option - adopt for the public key the DNSKEY wire format (it is known to work, has very similar constraint, and code already exists) - in the signature option, merge the HAsh and SignAture IDs into a single 16 bit ID taken for instance from the RRSIG. - add a provision for nodes without access to an UTC real clock (BTW SeND was written before the emergence of mobile hardware with very bad real clocks, cf a discussion in the PCP WG with some NTP people). In the good thing to keep, timestamps (IMHO the anti-replay should be promoted in the introduction), the leap of faith mode (oops, replace everywhere model by mode), etc. Regards Francis.Dupont@fdupont.fr PS: for the authors: I have a lot minor technical and editorial comments in the case you want them before the next version? (please ask at fdupont@isc.org) From nobody Sun Jun 15 20:07:02 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3351B29F7 for ; Sun, 15 Jun 2014 20:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdRFyLhzs2_L for ; Sun, 15 Jun 2014 20:06:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3571A0265 for ; Sun, 15 Jun 2014 20:06:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIL30957; Mon, 16 Jun 2014 03:06:55 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Jun 2014 04:06:55 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 16 Jun 2014 11:06:43 +0800 From: Sheng Jiang To: Francis Dupont , "dhcwg@ietf.org" Thread-Topic: [dhcwg] review of draft-ietf-dhc-sedhcpv6-02.txt Thread-Index: AQHPhxHHDWmmVtn3xk6Y2sFvCvyQjptzBFBw Date: Mon, 16 Jun 2014 03:06:43 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE8C3F8@nkgeml512-mbx.china.huawei.com> References: <201406131413.s5DEDxGn042278@givry.fdupont.fr> In-Reply-To: <201406131413.s5DEDxGn042278@givry.fdupont.fr> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/tb4LBcyDQpUKPjijwbcEXkZ6VG0 Subject: Re: [dhcwg] review of draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 03:06:59 -0000 SGksIEZyYW5jaXMsDQoNClRoYW5rcyBzbyBtdWNoIGZvciB5b3VyIHJldmlldy4gV2Ugd2lsbCBh ZGRyZXNzIG1vc3Qgb2YgeW91ciBjb21tZW50cyBpbiB0aGUgbmV4dCB1cGRhdGUuIEhvd2V2ZXIs IHlvdXIgcHJvcG9zZWQgImRyb3AgdGhlIGNlcnRpZmljYXRlIG9wdGlvbiIgaXMgdG9vIG1hZ25p ZmljZW50LCBmb3Igd2hpY2ggd2UgbmVlZCBXRyBjb25zZW5zdXMgdG8gY2hhbmdlIGl0LiBUaGVy ZSBhcmUgc29tZSBleHBsYW5hdGlvbiBhbmQgb3BpbmlvbnMgZnJvbSBhdXRob3JzIGJlbG93Lg0K DQo+QnV0IG15IG1haW4gY29uY2VybiBpcyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgY2VydGlm aWNhdGUgc3R1ZmYNCj4oKnB1YmxpYyBrZXkqIGNlcnRpZmljYXRlIEJUVykuIFRoZSBpc3N1ZSBp cyBlaXRoZXIgdGhlIG5vZGUgaGFzDQo+ZnVsbHkgYWNjZXNzIHRvIHRoZSBQS0kgYW5kIGEgcG9p bnRlciAoZS5nLiwgSUtFdjIgVVJJIGFuZCBoYXNoKQ0KPmlzIHNpbXBsZXIvYmV0dGVyLCBvciBh IG1lY2hhbmlzbSBoYXMgdG8gcHJvdmlkZSB0aGUgdHJ1c3QgYW5jaG9yLA0KPnRoZSBjZXJ0aWZp Y2F0ZSBjaGFpbiBhbmQgY3JscywgZXRjLiBJdCB3YXMgZG9uZSBpbiBTRU5EIHRoZSAodmVyeSkN Cj5oYXJkIHdheS4uLg0KPg0KPkluIHRoZSBjYXNlIG9mIHNlY3VyZSBESENQdjYgSU1ITyBpdCBz aG91bGQgYmUgbW9yZSBlZmZpY2llbnQNCj50byBwb3N0cG9uZSB0aGUgY2VydGlmaWNhdGUgc3R1 ZmYsIHNvIEkgcHJvcG9zZToNCj4gLSBkcm9wIHRoZSBjZXJ0aWZpY2F0ZSBvcHRpb24NCg0KV2Ug ZnVsbHkgYWdyZWUgdGhlIGRlcGxveW1lbnQgb2YgUEtJIGlzIGRpZmZpY3VsdC4gSG93ZXZlciwg aW4gdGhlIHNlY3VyZSBESENQdjYsIHRoZSBjZXJ0aWZpY2F0ZSBpcyBvbmUgb2YgYWx0ZXJuYXRp dmUgbWVjaGFuaXNtcywgcGFyYWxsZWwgd2l0aCBsZWFwIG9mIGZhaXRoIG1vZGUuIFRoZSB0d28g bW9kZXMgcHJvdmlkZSBkaWZmZXJlbnQgbGV2ZWxzIG9mIHNlY3VyaXR5LiBUaGV5IGFyZSBjb21w bGVtZW50YXJ5IGZvciBlYWNoIG90aGVyLiBGdXJ0aGVybW9yZSwgd2l0aG91dCB0aGUgc3VwcG9y dCBhIFBLSSwgdGhlIGNlcnRpZmljYXRlcyBjYW4gYWxzbyBiZSB1c2VkIGluIHRoZSBMb0YgbW9k ZS4gSW4gYW55IGNhc2UsIHRoZSBkZXBsb3ltZW50IGNvdWxkIGNob29zZSBvbmx5IHB1YmxpYyBr ZXkgcGx1cyBMb0YgbW9kZSwgaWYgUEtJIGlzIHRvbyBjb21wbGljYXRlZCBmb3IgdGhlbS4gVGhl cmVmb3JlLCB3ZSB0aGluayBrZWVwaW5nIHRoZSBwb3NzaWJpbGl0eSBvZiBjZXJ0aWZpY2F0ZSBt b2RlIGhhcyBtb3JlIGJlbmVmaXQgdGhhbiBoYXJtLg0KDQpCZXN0IHJlZ2FyZHMsDQoNClNoZW5n ICsgRGFjaGVuZw0K From nobody Mon Jun 16 05:40:11 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5821A0023 for ; Mon, 16 Jun 2014 05:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blRb2HFbqRIN for ; Mon, 16 Jun 2014 05:40:00 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226A41A000B for ; Mon, 16 Jun 2014 05:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6879; q=dns/txt; s=iport; t=1402922401; x=1404132001; h=from:to:subject:date:message-id:mime-version; bh=SSDPVrdmbhIXQjmnZhB1tSbAe9kRlOM0ebvHNPxT/Ag=; b=K7RAbETvHbAmtfp9N582kYGKneLs9vNzjLtfvl2H2bIpTG/Od96hTxkT 3hbP6kf03aY0YLPScjyABJgZbipzqyr6gKGqhsHczIUK7OyLh36DXaN9U VlFYHUcZFaeGSzjTBWt2a6AS/mSxVIn4SRk0kn+Dz6QjGcyLg2ZuqQuoM M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUFAPjknlOtJA2N/2dsb2JhbABagkZHUlqpaQEBAQEBBwWZHwGBERZ1hAUBBC1eASodORQSAQQTCAGIOQ2heK0xF4VjhXSCboNlgRYErhuDQGyBRA X-IronPort-AV: E=Sophos;i="5.01,486,1400025600"; d="scan'208,217";a="330288418" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jun 2014 12:40:00 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5GCdxCo014429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 16 Jun 2014 12:39:59 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Mon, 16 Jun 2014 07:39:59 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: Reminder - Need Agenda Items for Toronto (IETF-90, July 20-25) Thread-Index: Ac+JX+Rebtz4Ah52QuyIRUTYDhnVvw== Date: Mon, 16 Jun 2014 12:39:58 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5C38A3@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.255.79] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1B5C38A3xmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/8AgEjEimfKgDfxOaLcumO4ayn_M Subject: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20-25) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 12:40:01 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1B5C38A3xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: Please send us (dhc-chairs@tools.ietf.org= ) requests for sessions for the DHC WG meeting in Toronto. Include: Name of session: Name of draft(s): Time requested: Presenter name(s): Brief description of what issues need discussing and what you hope to accom= plish by presenting: More details about the Toronto IETF can be found at http://www.ietf.org/mee= ting/90/index.html. - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1B5C38A3xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi:

 =

Please send us (dhc-chair= s@tools.ietf.org) requests for sessions for the DHC WG meeting i= n Toronto. Include:

 =

Name of session:

Name of draft(s):

Time requested:

Presenter name(s):<= /o:p>

Brief description of wha= t issues need discussing and what you hope to accomplish by presenting:

 =

More details about the T= oronto IETF can be found at http://www.ietf.org/meeting/90/index.html.

 =

- = ;         Tomek & Bern= ie

--_000_489D13FBFA9B3E41812EA89F188F018E1B5C38A3xmbrcdx04ciscoc_-- From nobody Tue Jun 17 06:54:40 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4326A1A0155 for ; Tue, 17 Jun 2014 06:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srQvi6nwDpc7 for ; Tue, 17 Jun 2014 06:54:32 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC971A001B for ; Tue, 17 Jun 2014 06:54:31 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id bs8so5904465wib.7 for ; Tue, 17 Jun 2014 06:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Q8olv8+dLdle7goxOO1NbCLFtcMy/ZS9VZQwxjWCErA=; b=NT8zhui2Iw/Jz7l0t0Yh3ut6vMmLCOU1UnHDR9CfFIcXO8EDwUqE5gFr+jewgqirYx nyzkJk/fEEleDLwZ97OEJhbZWEFLxaKeJjkfkyLhK3lappuW1DZgXKt29OoY6U5zaIuC KkTdLaHHEZKx36sAF0JUgjDo4ddCX7SKHQDazI1ZJymiJtj8U+nTKappCK1I7zXltajX oYY/UD/fIeI+7WDRZ6WyhRNfLiBHVXi6HUUgRadOtiABr/i8QIv5ixEDbrKZpEk2bQEF +UXIOBv5sEjHQE1U44lzgoe33xMA1z4xe1gdIAOtxfGvcUbmKDk6Zhro29JaA4HkWv/V OgfQ== X-Received: by 10.195.12.34 with SMTP id en2mr39029461wjd.13.1403013270305; Tue, 17 Jun 2014 06:54:30 -0700 (PDT) Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by mx.google.com with ESMTPSA id s8sm11916198eeo.14.2014.06.17.06.54.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 06:54:29 -0700 (PDT) Message-ID: <53A04891.6020708@gmail.com> Date: Tue, 17 Jun 2014 15:54:25 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dhcwg@ietf.org References: <489D13FBFA9B3E41812EA89F188F018E1B5C38A3@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5C38A3@xmb-rcd-x04.cisco.com> X-Enigmail-Version: 1.5.2 X-TagToolbar-Keys: D20140617155425784 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/fffTA0jpjihAoqy415slgVkWYFU Subject: Re: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20-25) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 13:54:37 -0000 On 16.06.2014 14:39, Bernie Volz (volz) wrote: > Hi: Please send us (dhc-chairs@tools.ietf.org) requests for sessions > for the DHC WG meeting in Toronto. Include: Name of session: DHC Name of draft(s): draft-ietf-dhc-topo-conf-02 Time requested: 5 mins Presenter name(s): Tomek Mrugalski Brief description of what issues need discussing and what you hope to accomplish by presenting: Summary of recent changes; ask whether WG thinks it's ready for WGLC Tomek From nobody Tue Jun 17 10:15:57 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7F81A0103 for ; Tue, 17 Jun 2014 10:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyNxyRWsNHJO for ; Tue, 17 Jun 2014 10:15:51 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A341A010F for ; Tue, 17 Jun 2014 10:15:45 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id j15so9615487qaq.12 for ; Tue, 17 Jun 2014 10:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3DByaURbrIDVNnBRy5z7JYsMEy83ul0IvcxPdafSBtc=; b=sADpGv7McZKruuo/nDnH+kmBooekc81bOMILo12Br2ONDARHLAJwT/vYt1m9D7/62W cQ5it63NIlrZcDZDM9cgiVGwS2gyb9BdgeJuvJVTMk7lWfkUOLotHIyJjVDy75EUmnSr hK20q5ckSw3tqx6xdR3Q4pc5RVLdlF84fk2j6sqyVIwgZt9Tk/kZ+fAj1vo2ststUkO/ aHu18aIYoFlHJ/wnt6C80D9fUtMQoKMYVIdnYjz9yuFPrWbi7RfrsAsyayhl5+iamGt3 EadGXSBP6NGHGOSn8TUxvsDd1jKopzdUzNE1D22+IpiKBF9hYkAMt28L784Tn0go3CeB aMZA== X-Received: by 10.224.114.145 with SMTP id e17mr37930007qaq.53.1403025343802; Tue, 17 Jun 2014 10:15:43 -0700 (PDT) Received: from [10.82.101.26] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id k5sm7489190qao.30.2014.06.17.10.15.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 10:15:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ralph Droms In-Reply-To: Date: Tue, 17 Jun 2014 13:15:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <791EB108-E4E8-4A82-84BC-CB36E277CAC4@gmail.com> References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AE88462@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AE891C2@nkgeml512-mbx.china.huawei.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= , Sheng Jiang X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/yAG5xAJ-8hR1nmVQhQlC8w73WHA Cc: dhcwg , Lemon Ted Subject: Re: [dhcwg] Deployment consideration for SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 17:15:53 -0000 Sheng - I think Jinmei-san's suggested text is very good, although I do = have one question about authentication on a server. The text includes = examples for the various scenarios, which addresses my primary concern. Jinmei-san - I have one question about your text. Can you explain in a = little more detail how the second and third examples of authentication = on a server work, in which you say the server only has to remember the = client's public key so neither full authentication nor LoF is required? - Ralph On Jun 6, 2014, at 2:51 PM 6/6/14, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = wrote: > At Thu, 5 Jun 2014 09:38:41 +0000, > Sheng Jiang wrote: >=20 >> The below text is the proposal from SeDHCPv6 authors in order to >> clarify the applicability. We plan to add these text, of course >> after reaching consensus in the mail list, into the next update >> version. Any comments are appreciated. >=20 > The proposed text seems to be almost a minor revise of my outline I > showed on the list, so I guess Ted would still complain that it's > incomplete:-). I'm not sure how much we should be "complete" in this > document (especially if we wouldn't like to make the document a > kitchen sink), but I'll show my own try below. Not intending to push > this particular text, but I thought I'm responsible for providing > something more concrete as someone who keeps raising the point. >=20 > X. Deployment consideration >=20 > This document defines two levels of authentication: full > authentication based on certificate or pre-shared key verification and > weaker authentication based on leap-of-faith (LoF). As a mechanism, > both levels can be applied on servers and clients. Depending on the > details of expected threats and other constraints, some cases may have > limited applicability. This section discusses such details. >=20 > X.1 Authentication on a client >=20 > For clients, DHCP authentication generally means authenticating the > server (the sender of DHCP messages) and verifying message integrity. >=20 > This is satisfied with full authentication. Due to the configuration > overhead, however, full authentication may not always be feasible. It > would still be viable in a controlled environment with skilled stuff, > such as a corporate intranet. >=20 > If LoF is used, message integrity is provided but there is a chance > for the client to incorrectly trust a malicious server at the > beginning of the first session with the server (and therefore keep > trusting it thereafter). But LoF guarantees the subsequent messages > are sent by the same server that sent the public key, and therefore > narrows the attack scope. This may make sense if the network can be > reasonably considered secure and requesting pre-configuration is > deemed to be infeasible. A small home network would be an example of > such cases. >=20 > For environments that are neither controlled nor really trustworthy, > such as a network cafe, full authentication wouldn't be feasible due > to configuration overhead, while pure LoF, i.e. silently trusting the > server at the first time, would be too insecure. But some > middleground might be justified, such as requiring human intervention > at the point of LoF. >=20 > X.2 Authentication on a server >=20 > As for authentication on a server, there are several different > scenarios to consider, each of which has different applicability > issues. >=20 > A server may have to selectively serve a specific client or deny > specific clients depending on the identify of the client. This will > require full authentication, since if the server allows LoF any > malicious user can pretend to be a new legitimate client. Also, the > use of certification wouldn't be feasible in this case, since it's > less likely for all such clients to have valid (and generally > different) certificates. So the applicable case may be limited, but a > controlled environment with skilled stuff and a specifically expected > set of clients such as a corporate intranet may still find it useful > and viable. >=20 > A server can prevent an attack on the DHCP session with an existing > client from a malicious client, e.g., by sending a bogus Release > message: the server would remember the original client's public key > at the beginning of the DHCP session and authenticate subsequent > messages (and their sender). Neither full authentication nor LoF is > needed for this purpose, since the server does not have to trust the > public key itself. So this can be generally used for any usage of > DHCP. >=20 > A server can prevent an attack by a malicious client that pretends to > be a valid past client and tries to establish a new DHCP session > (whether this is a real security threat may be a subject of debate, > but this is probably at least annoying). This is similar to the first > scenario, but full authentication may not necessarily be required; > since the purpose is to confirm a returning client has the same > identify as a valid past client, the server only has to remember the > client's public key at the first time. So LoF can be used at the risk > of allowing a malicious client to mount this attack before the initial > session with a valid client. An uncontrolled, but reasonable reliable > network like a home network may use this defense with LoF. >=20 > -- > JINMEI, Tatuya From nobody Tue Jun 17 15:27:21 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E70E1A017F for ; Tue, 17 Jun 2014 15:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCfRDkCMzUaG for ; Tue, 17 Jun 2014 15:27:19 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324F01A017B for ; Tue, 17 Jun 2014 15:27:19 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x13so6484wgg.15 for ; Tue, 17 Jun 2014 15:27:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=6uZZajZImwwIYz1j/TDETBLSTznDcndjfuEPW+7jm1o=; b=VysvSSTAr/HfBTfv7K0yfbfeOwIAYHobMIsCQ5rbJ0GnaDKFtkeh+zA9InriIPTh8s 220BFmtKvTNJ/QPHJJK9sAwW4htWYLLN+827OK5OfT9WpGJ5XtfnKXm98sggRdOE6Iba j/P2Lh2u7AF7cocC+U2PfhNCYWhs0M7vudaMP+9X/wg28yXPSpyOULnEL9kvUVIp09pA hHidVUhDLmw4g7BoA8Edti1meOHef7kLj/TwrWaJjKcu/3QTLjQ+ExhwOFKQ5yi+dDny xcXhTIj0qoQs5aDPDu7YFsa4M/WrGbF0dbYynT/GyVjJYSfmVE5clGtpW429dunddIEp RbUg== MIME-Version: 1.0 X-Received: by 10.180.83.105 with SMTP id p9mr39946376wiy.8.1403044037634; Tue, 17 Jun 2014 15:27:17 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.222.7 with HTTP; Tue, 17 Jun 2014 15:27:17 -0700 (PDT) In-Reply-To: <791EB108-E4E8-4A82-84BC-CB36E277CAC4@gmail.com> References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AE88462@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AE891C2@nkgeml512-mbx.china.huawei.com> <791EB108-E4E8-4A82-84BC-CB36E277CAC4@gmail.com> Date: Tue, 17 Jun 2014 15:27:17 -0700 X-Google-Sender-Auth: F_c12uARRakHvG2lwJYNdxR4J-I Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Ralph Droms Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/YbTxzchmKhE6GigmN-EljZs_5aQ Cc: dhcwg , Lemon Ted Subject: Re: [dhcwg] Deployment consideration for SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 22:27:20 -0000 At Tue, 17 Jun 2014 13:15:39 -0400, Ralph Droms wrote: > Jinmei-san - I have one question about your text. Can you explain in a l= ittle more detail how the second and third examples of authentication on a = server work, in which you say the server only has to remember the client's = public key so neither full authentication nor LoF is required? In the second example, the client sends its public key in Solicit, and the server remembers it during the DHCP session starting from that Solicit. The server uses the public key to authenticate any subsequent message from that client (or anyone claiming to be that client) for that DHCP session. I said LoF (let alone full authentication) isn't needed because when the server accepts and remembers the public key sent in the Solicit, it doesn't do so for the purpose of authenticating the Solicit itself. It only remembers the public key to confirm that subsequent messages of the session are certainly sent from the same client as the one sent the Solicit, and there's no "leap" here. In the third example, I actually didn't say LoF isn't required. Could the text read as if I did? -- JINMEI, Tatuya p.s., I noticed one type in the text, a kind only non native English user would do: s/stuff/staff/ below: > > This is satisfied with full authentication. Due to the configuration > > overhead, however, full authentication may not always be feasible. It > > would still be viable in a controlled environment with skilled stuff, > > such as a corporate intranet. [...] > > different) certificates. So the applicable case may be limited, but a > > controlled environment with skilled stuff and a specifically expected > > set of clients such as a corporate intranet may still find it useful > > and viable. if we use any part of my suggested text, please correct these > authors. From nobody Wed Jun 18 02:30:28 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7882E1A0104 for ; Wed, 18 Jun 2014 02:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.552 X-Spam-Level: X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8iuIS-8ywuB for ; Wed, 18 Jun 2014 02:30:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F981A00A6 for ; Wed, 18 Jun 2014 02:30:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFO09581; Wed, 18 Jun 2014 09:30:20 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 18 Jun 2014 10:30:19 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Wed, 18 Jun 2014 17:30:16 +0800 From: Sheng Jiang To: Ralph Droms , =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] Deployment consideration for SeDHCPv6 Thread-Index: AQHPgKHv1Ac5DKV250+NBNKyOimJaptj6VoAgBEuy4CAAZYj8A== Date: Wed, 18 Jun 2014 09:30:16 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE8D3C9@nkgeml512-mbx.china.huawei.com> References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AE88462@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AE891C2@nkgeml512-mbx.china.huawei.com> <791EB108-E4E8-4A82-84BC-CB36E277CAC4@gmail.com> In-Reply-To: <791EB108-E4E8-4A82-84BC-CB36E277CAC4@gmail.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/WdnJlYsfJKCC2-mQrFsV9PgBaz0 Cc: dhcwg , Lemon Ted Subject: Re: [dhcwg] Deployment consideration for SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2014 09:30:25 -0000 VGhhbmtzIFJhbHBoIGZvciBjb25maXJtYXRpb24uIFRoYW5rcyBKaW5tZWkgZm9yIGhlbHBmdWwg aW5wdXQuIFdlIGhhdmUgaW5jbHVkZWQgdGhlc2UgdGV4dCBpbiB0aGUgb25nb2luZyB1cGRhdGUg dmVyc2lvbi4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj5Gcm9tOiBSYWxwaCBEcm9tcyBbbWFpbHRvOnJkcm9tcy5pZXRmQGdtYWlsLmNv bV0NCj5TZW50OiBXZWRuZXNkYXksIEp1bmUgMTgsIDIwMTQgMToxNiBBTQ0KPlRvOiDnpZ7mmI7p gZTlk4k7IFNoZW5nIEppYW5nDQo+Q2M6IExlbW9uIFRlZDsgZGhjd2cNCj5TdWJqZWN0OiBSZTog W2RoY3dnXSBEZXBsb3ltZW50IGNvbnNpZGVyYXRpb24gZm9yIFNlREhDUHY2DQo+DQo+U2hlbmcg LSBJIHRoaW5rIEppbm1laS1zYW4ncyBzdWdnZXN0ZWQgdGV4dCBpcyB2ZXJ5IGdvb2QsIGFsdGhv dWdoIEkgZG8gaGF2ZQ0KPm9uZSBxdWVzdGlvbiBhYm91dCBhdXRoZW50aWNhdGlvbiBvbiBhIHNl cnZlci4gIFRoZSB0ZXh0IGluY2x1ZGVzIGV4YW1wbGVzDQo+Zm9yIHRoZSB2YXJpb3VzIHNjZW5h cmlvcywgd2hpY2ggYWRkcmVzc2VzIG15IHByaW1hcnkgY29uY2Vybi4NCj4NCj5KaW5tZWktc2Fu IC0gSSBoYXZlIG9uZSBxdWVzdGlvbiBhYm91dCB5b3VyIHRleHQuICBDYW4geW91IGV4cGxhaW4g aW4gYSBsaXR0bGUNCj5tb3JlIGRldGFpbCBob3cgdGhlIHNlY29uZCBhbmQgdGhpcmQgZXhhbXBs ZXMgb2YgYXV0aGVudGljYXRpb24gb24gYSBzZXJ2ZXINCj53b3JrLCBpbiB3aGljaCB5b3Ugc2F5 IHRoZSBzZXJ2ZXIgb25seSBoYXMgdG8gcmVtZW1iZXIgdGhlIGNsaWVudCdzIHB1YmxpYyBrZXkN Cj5zbyBuZWl0aGVyIGZ1bGwgYXV0aGVudGljYXRpb24gbm9yIExvRiBpcyByZXF1aXJlZD8NCj4N Cj4tIFJhbHBoDQo+DQo+T24gSnVuIDYsIDIwMTQsIGF0IDI6NTEgUE0gNi82LzE0LCDnpZ7mmI7p gZTlk4kgPGppbm1laUB3aWRlLmFkLmpwPiB3cm90ZToNCj4NCj4+IEF0IFRodSwgNSBKdW4gMjAx NCAwOTozODo0MSArMDAwMCwNCj4+IFNoZW5nIEppYW5nIDxqaWFuZ3NoZW5nQGh1YXdlaS5jb20+ IHdyb3RlOg0KPj4NCj4+PiBUaGUgYmVsb3cgdGV4dCBpcyB0aGUgcHJvcG9zYWwgZnJvbSBTZURI Q1B2NiBhdXRob3JzIGluIG9yZGVyIHRvDQo+Pj4gY2xhcmlmeSB0aGUgYXBwbGljYWJpbGl0eS4g V2UgcGxhbiB0byBhZGQgdGhlc2UgdGV4dCwgb2YgY291cnNlDQo+Pj4gYWZ0ZXIgcmVhY2hpbmcg Y29uc2Vuc3VzIGluIHRoZSBtYWlsIGxpc3QsIGludG8gdGhlIG5leHQgdXBkYXRlDQo+Pj4gdmVy c2lvbi4gQW55IGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCj4+DQo+PiBUaGUgcHJvcG9zZWQg dGV4dCBzZWVtcyB0byBiZSBhbG1vc3QgYSBtaW5vciByZXZpc2Ugb2YgbXkgb3V0bGluZSBJDQo+ PiBzaG93ZWQgb24gdGhlIGxpc3QsIHNvIEkgZ3Vlc3MgVGVkIHdvdWxkIHN0aWxsIGNvbXBsYWlu IHRoYXQgaXQncw0KPj4gaW5jb21wbGV0ZTotKS4gIEknbSBub3Qgc3VyZSBob3cgbXVjaCB3ZSBz aG91bGQgYmUgImNvbXBsZXRlIiBpbiB0aGlzDQo+PiBkb2N1bWVudCAoZXNwZWNpYWxseSBpZiB3 ZSB3b3VsZG4ndCBsaWtlIHRvIG1ha2UgdGhlIGRvY3VtZW50IGENCj4+IGtpdGNoZW4gc2luayks IGJ1dCBJJ2xsIHNob3cgbXkgb3duIHRyeSBiZWxvdy4gIE5vdCBpbnRlbmRpbmcgdG8gcHVzaA0K Pj4gdGhpcyBwYXJ0aWN1bGFyIHRleHQsIGJ1dCBJIHRob3VnaHQgSSdtIHJlc3BvbnNpYmxlIGZv ciBwcm92aWRpbmcNCj4+IHNvbWV0aGluZyBtb3JlIGNvbmNyZXRlIGFzIHNvbWVvbmUgd2hvIGtl ZXBzIHJhaXNpbmcgdGhlIHBvaW50Lg0KPj4NCj4+IFguIERlcGxveW1lbnQgY29uc2lkZXJhdGlv bg0KPj4NCj4+IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0d28gbGV2ZWxzIG9mIGF1dGhlbnRpY2F0 aW9uOiBmdWxsDQo+PiBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiBjZXJ0aWZpY2F0ZSBvciBwcmUt c2hhcmVkIGtleSB2ZXJpZmljYXRpb24gYW5kDQo+PiB3ZWFrZXIgYXV0aGVudGljYXRpb24gYmFz ZWQgb24gbGVhcC1vZi1mYWl0aCAoTG9GKS4gIEFzIGEgbWVjaGFuaXNtLA0KPj4gYm90aCBsZXZl bHMgY2FuIGJlIGFwcGxpZWQgb24gc2VydmVycyBhbmQgY2xpZW50cy4gIERlcGVuZGluZyBvbiB0 aGUNCj4+IGRldGFpbHMgb2YgZXhwZWN0ZWQgdGhyZWF0cyBhbmQgb3RoZXIgY29uc3RyYWludHMs IHNvbWUgY2FzZXMgbWF5IGhhdmUNCj4+IGxpbWl0ZWQgYXBwbGljYWJpbGl0eS4gIFRoaXMgc2Vj dGlvbiBkaXNjdXNzZXMgc3VjaCBkZXRhaWxzLg0KPj4NCj4+IFguMSBBdXRoZW50aWNhdGlvbiBv biBhIGNsaWVudA0KPj4NCj4+IEZvciBjbGllbnRzLCBESENQIGF1dGhlbnRpY2F0aW9uIGdlbmVy YWxseSBtZWFucyBhdXRoZW50aWNhdGluZyB0aGUNCj4+IHNlcnZlciAodGhlIHNlbmRlciBvZiBE SENQIG1lc3NhZ2VzKSBhbmQgdmVyaWZ5aW5nIG1lc3NhZ2UgaW50ZWdyaXR5Lg0KPj4NCj4+IFRo aXMgaXMgc2F0aXNmaWVkIHdpdGggZnVsbCBhdXRoZW50aWNhdGlvbi4gIER1ZSB0byB0aGUgY29u ZmlndXJhdGlvbg0KPj4gb3ZlcmhlYWQsIGhvd2V2ZXIsIGZ1bGwgYXV0aGVudGljYXRpb24gbWF5 IG5vdCBhbHdheXMgYmUgZmVhc2libGUuICBJdA0KPj4gd291bGQgc3RpbGwgYmUgdmlhYmxlIGlu IGEgY29udHJvbGxlZCBlbnZpcm9ubWVudCB3aXRoIHNraWxsZWQgc3R1ZmYsDQo+PiBzdWNoIGFz IGEgY29ycG9yYXRlIGludHJhbmV0Lg0KPj4NCj4+IElmIExvRiBpcyB1c2VkLCBtZXNzYWdlIGlu dGVncml0eSBpcyBwcm92aWRlZCBidXQgdGhlcmUgaXMgYSBjaGFuY2UNCj4+IGZvciB0aGUgY2xp ZW50IHRvIGluY29ycmVjdGx5IHRydXN0IGEgbWFsaWNpb3VzIHNlcnZlciBhdCB0aGUNCj4+IGJl Z2lubmluZyBvZiB0aGUgZmlyc3Qgc2Vzc2lvbiB3aXRoIHRoZSBzZXJ2ZXIgKGFuZCB0aGVyZWZv cmUga2VlcA0KPj4gdHJ1c3RpbmcgaXQgdGhlcmVhZnRlcikuICBCdXQgTG9GIGd1YXJhbnRlZXMg dGhlIHN1YnNlcXVlbnQgbWVzc2FnZXMNCj4+IGFyZSBzZW50IGJ5IHRoZSBzYW1lIHNlcnZlciB0 aGF0IHNlbnQgdGhlIHB1YmxpYyBrZXksIGFuZCB0aGVyZWZvcmUNCj4+IG5hcnJvd3MgdGhlIGF0 dGFjayBzY29wZS4gIFRoaXMgbWF5IG1ha2Ugc2Vuc2UgaWYgdGhlIG5ldHdvcmsgY2FuIGJlDQo+ PiByZWFzb25hYmx5IGNvbnNpZGVyZWQgc2VjdXJlIGFuZCByZXF1ZXN0aW5nIHByZS1jb25maWd1 cmF0aW9uIGlzDQo+PiBkZWVtZWQgdG8gYmUgaW5mZWFzaWJsZS4gIEEgc21hbGwgaG9tZSBuZXR3 b3JrIHdvdWxkIGJlIGFuIGV4YW1wbGUgb2YNCj4+IHN1Y2ggY2FzZXMuDQo+Pg0KPj4gRm9yIGVu dmlyb25tZW50cyB0aGF0IGFyZSBuZWl0aGVyIGNvbnRyb2xsZWQgbm9yIHJlYWxseSB0cnVzdHdv cnRoeSwNCj4+IHN1Y2ggYXMgYSBuZXR3b3JrIGNhZmUsIGZ1bGwgYXV0aGVudGljYXRpb24gd291 bGRuJ3QgYmUgZmVhc2libGUgZHVlDQo+PiB0byBjb25maWd1cmF0aW9uIG92ZXJoZWFkLCB3aGls ZSBwdXJlIExvRiwgaS5lLiBzaWxlbnRseSB0cnVzdGluZyB0aGUNCj4+IHNlcnZlciBhdCB0aGUg Zmlyc3QgdGltZSwgd291bGQgYmUgdG9vIGluc2VjdXJlLiAgQnV0IHNvbWUNCj4+IG1pZGRsZWdy b3VuZCBtaWdodCBiZSBqdXN0aWZpZWQsIHN1Y2ggYXMgcmVxdWlyaW5nIGh1bWFuIGludGVydmVu dGlvbg0KPj4gYXQgdGhlIHBvaW50IG9mIExvRi4NCj4+DQo+PiBYLjIgQXV0aGVudGljYXRpb24g b24gYSBzZXJ2ZXINCj4+DQo+PiBBcyBmb3IgYXV0aGVudGljYXRpb24gb24gYSBzZXJ2ZXIsIHRo ZXJlIGFyZSBzZXZlcmFsIGRpZmZlcmVudA0KPj4gc2NlbmFyaW9zIHRvIGNvbnNpZGVyLCBlYWNo IG9mIHdoaWNoIGhhcyBkaWZmZXJlbnQgYXBwbGljYWJpbGl0eQ0KPj4gaXNzdWVzLg0KPj4NCj4+ IEEgc2VydmVyIG1heSBoYXZlIHRvIHNlbGVjdGl2ZWx5IHNlcnZlIGEgc3BlY2lmaWMgY2xpZW50 IG9yIGRlbnkNCj4+IHNwZWNpZmljIGNsaWVudHMgZGVwZW5kaW5nIG9uIHRoZSBpZGVudGlmeSBv ZiB0aGUgY2xpZW50LiAgVGhpcyB3aWxsDQo+PiByZXF1aXJlIGZ1bGwgYXV0aGVudGljYXRpb24s IHNpbmNlIGlmIHRoZSBzZXJ2ZXIgYWxsb3dzIExvRiBhbnkNCj4+IG1hbGljaW91cyB1c2VyIGNh biBwcmV0ZW5kIHRvIGJlIGEgbmV3IGxlZ2l0aW1hdGUgY2xpZW50LiAgQWxzbywgdGhlDQo+PiB1 c2Ugb2YgY2VydGlmaWNhdGlvbiB3b3VsZG4ndCBiZSBmZWFzaWJsZSBpbiB0aGlzIGNhc2UsIHNp bmNlIGl0J3MNCj4+IGxlc3MgbGlrZWx5IGZvciBhbGwgc3VjaCBjbGllbnRzIHRvIGhhdmUgdmFs aWQgKGFuZCBnZW5lcmFsbHkNCj4+IGRpZmZlcmVudCkgY2VydGlmaWNhdGVzLiAgU28gdGhlIGFw cGxpY2FibGUgY2FzZSBtYXkgYmUgbGltaXRlZCwgYnV0IGENCj4+IGNvbnRyb2xsZWQgZW52aXJv bm1lbnQgd2l0aCBza2lsbGVkIHN0dWZmIGFuZCBhIHNwZWNpZmljYWxseSBleHBlY3RlZA0KPj4g c2V0IG9mIGNsaWVudHMgc3VjaCBhcyBhIGNvcnBvcmF0ZSBpbnRyYW5ldCBtYXkgc3RpbGwgZmlu ZCBpdCB1c2VmdWwNCj4+IGFuZCB2aWFibGUuDQo+Pg0KPj4gQSBzZXJ2ZXIgY2FuIHByZXZlbnQg YW4gYXR0YWNrIG9uIHRoZSBESENQIHNlc3Npb24gd2l0aCBhbiBleGlzdGluZw0KPj4gY2xpZW50 IGZyb20gYSBtYWxpY2lvdXMgY2xpZW50LCBlLmcuLCBieSBzZW5kaW5nIGEgYm9ndXMgUmVsZWFz ZQ0KPj4gbWVzc2FnZTogdGhlIHNlcnZlciB3b3VsZCByZW1lbWJlciB0aGUgb3JpZ2luYWwgY2xp ZW50J3MgcHVibGljIGtleQ0KPj4gYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgREhDUCBzZXNzaW9u IGFuZCBhdXRoZW50aWNhdGUgc3Vic2VxdWVudA0KPj4gbWVzc2FnZXMgKGFuZCB0aGVpciBzZW5k ZXIpLiAgTmVpdGhlciBmdWxsIGF1dGhlbnRpY2F0aW9uIG5vciBMb0YgaXMNCj4+IG5lZWRlZCBm b3IgdGhpcyBwdXJwb3NlLCBzaW5jZSB0aGUgc2VydmVyIGRvZXMgbm90IGhhdmUgdG8gdHJ1c3Qg dGhlDQo+PiBwdWJsaWMga2V5IGl0c2VsZi4gIFNvIHRoaXMgY2FuIGJlIGdlbmVyYWxseSB1c2Vk IGZvciBhbnkgdXNhZ2Ugb2YNCj4+IERIQ1AuDQo+Pg0KPj4gQSBzZXJ2ZXIgY2FuIHByZXZlbnQg YW4gYXR0YWNrIGJ5IGEgbWFsaWNpb3VzIGNsaWVudCB0aGF0IHByZXRlbmRzIHRvDQo+PiBiZSBh IHZhbGlkIHBhc3QgY2xpZW50IGFuZCB0cmllcyB0byBlc3RhYmxpc2ggYSBuZXcgREhDUCBzZXNz aW9uDQo+PiAod2hldGhlciB0aGlzIGlzIGEgcmVhbCBzZWN1cml0eSB0aHJlYXQgbWF5IGJlIGEg c3ViamVjdCBvZiBkZWJhdGUsDQo+PiBidXQgdGhpcyBpcyBwcm9iYWJseSBhdCBsZWFzdCBhbm5v eWluZykuICBUaGlzIGlzIHNpbWlsYXIgdG8gdGhlIGZpcnN0DQo+PiBzY2VuYXJpbywgYnV0IGZ1 bGwgYXV0aGVudGljYXRpb24gbWF5IG5vdCBuZWNlc3NhcmlseSBiZSByZXF1aXJlZDsNCj4+IHNp bmNlIHRoZSBwdXJwb3NlIGlzIHRvIGNvbmZpcm0gYSByZXR1cm5pbmcgY2xpZW50IGhhcyB0aGUg c2FtZQ0KPj4gaWRlbnRpZnkgYXMgYSB2YWxpZCBwYXN0IGNsaWVudCwgdGhlIHNlcnZlciBvbmx5 IGhhcyB0byByZW1lbWJlciB0aGUNCj4+IGNsaWVudCdzIHB1YmxpYyBrZXkgYXQgdGhlIGZpcnN0 IHRpbWUuICBTbyBMb0YgY2FuIGJlIHVzZWQgYXQgdGhlIHJpc2sNCj4+IG9mIGFsbG93aW5nIGEg bWFsaWNpb3VzIGNsaWVudCB0byBtb3VudCB0aGlzIGF0dGFjayBiZWZvcmUgdGhlIGluaXRpYWwN Cj4+IHNlc3Npb24gd2l0aCBhIHZhbGlkIGNsaWVudC4gIEFuIHVuY29udHJvbGxlZCwgYnV0IHJl YXNvbmFibGUgcmVsaWFibGUNCj4+IG5ldHdvcmsgbGlrZSBhIGhvbWUgbmV0d29yayBtYXkgdXNl IHRoaXMgZGVmZW5zZSB3aXRoIExvRi4NCj4+DQo+PiAtLQ0KPj4gSklOTUVJLCBUYXR1eWENCg0K From nobody Thu Jun 19 09:03:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FCC1A027E for ; Thu, 19 Jun 2014 09:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlGFTXFYTI0I for ; Thu, 19 Jun 2014 09:03:22 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CB041A026F for ; Thu, 19 Jun 2014 09:03:22 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id hw13so2106428qab.17 for ; Thu, 19 Jun 2014 09:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:from:subject:date:to; bh=LdRTKROvwTtWtykKMQwG8RiWP+m181W7mmpoSJTkDcw=; b=G/n3jZD42jaAKr8wsu5QSi1KHgiF2ekgjt7oHQg4oLrsE25FRvVLnqKAd6Yt21/zr6 LQKozxOxkKzCdRfibxgi2YVpdcixiwjGA7XBaw3czpbKshDcXn2+V4VBvjOhcIhAD70v 2IcTnSsgeaeOFkGOSwxCu94NJ7uiR8QUF/FL9IP8VK3PCRTNn6jmxCS52GLLbwvc5OSJ JYnT4buzJVfG585fT/BqUYGcejEJ5wvgwYApg+1csexvXIOIS2s6hmcnZxz6oKcLf5QD bR8a62FVF1mJ/UcKIUjJzNn+7XN8g3oXXFM8VJB3VUtO44mySHWOpbiTM0+d14st39Tx UPIw== X-Received: by 10.229.44.65 with SMTP id z1mr8544019qce.7.1403193801728; Thu, 19 Jun 2014 09:03:21 -0700 (PDT) Received: from [10.116.164.51] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id v10sm9089029qas.40.2014.06.19.09.03.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Jun 2014 09:03:20 -0700 (PDT) References: <535FEDAD.5010103@gmail.com> <5388F901.1000709@gmail.com> <78B235AF-D94C-40F1-9C76-4159B3A0A043@nominum.com> <5D36713D8A4E7348A7E10DF7437A4B923AE88462@nkgeml512-mbx.china.huawei.com> <5D36713D8A4E7348A7E10DF7437A4B923AE891C2@nkgeml512-mbx.china.huawei.com> <791EB108-E4E8-4A82-84BC-CB36E277CAC4@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (11D201) From: Ralph Droms Date: Thu, 19 Jun 2014 12:03:18 -0400 To: =?utf-8?B?56We5piO6YGU5ZOJ?= Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/gAY4Z-GcJy9qe-_vP6VmTMyslQo Cc: dhcwg , Lemon Ted Subject: Re: [dhcwg] Deployment consideration for SeDHCPv6 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 16:03:23 -0000 > On Jun 17, 2014, at 6:27 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: >=20 > At Tue, 17 Jun 2014 13:15:39 -0400, > Ralph Droms wrote: >=20 >> Jinmei-san - I have one question about your text. Can you explain in a l= ittle more detail how the second and third examples of authentication on a s= erver work, in which you say the server only has to remember the client's pu= blic key so neither full authentication nor LoF is required? >=20 > In the second example, the client sends its public key in Solicit, and > the server remembers it during the DHCP session starting from that > Solicit. The server uses the public key to authenticate any > subsequent message from that client (or anyone claiming to be that > client) for that DHCP session. I said LoF (let alone full > authentication) isn't needed because when the server accepts and > remembers the public key sent in the Solicit, it doesn't do so for the > purpose of authenticating the Solicit itself. It only remembers the > public key to confirm that subsequent messages of the session are > certainly sent from the same client as the one sent the Solicit, and > there's no "leap" here. I see. I missed the point that the messages still use the authentication op= tion to prove that the messages come from the same source and to prove messa= ge integrity, but the source is not checked for authorization to use the ser= ver. >=20 > In the third example, I actually didn't say LoF isn't required. Could > the text read as if I did? I reread the text. You are right, it does not say LoF is not required. I m= isread the text initially. - Ralph >=20 > -- > JINMEI, Tatuya >=20 > p.s., I noticed one type in the text, a kind only non native English > user would do: s/stuff/staff/ below: >=20 >>> This is satisfied with full authentication. Due to the configuration >>> overhead, however, full authentication may not always be feasible. It >>> would still be viable in a controlled environment with skilled stuff, >>> such as a corporate intranet. > [...] >>> different) certificates. So the applicable case may be limited, but a >>> controlled environment with skilled stuff and a specifically expected >>> set of clients such as a corporate intranet may still find it useful >>> and viable. >=20 > if we use any part of my suggested text, please correct these > authors. From nobody Thu Jun 19 10:57:12 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3990A1A02B3; Thu, 19 Jun 2014 10:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1flxZy_W20mp; Thu, 19 Jun 2014 10:57:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EDA1A02CF; Thu, 19 Jun 2014 10:57:06 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140619175706.31494.41411.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 10:57:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/sIBTNWqvNViEUio1SAwJibxx5c8 Cc: dhc mailing list , dhc chair , RFC Editor Subject: [dhcwg] Protocol Action: 'DHCPv4 over DHCPv6 Transport' to Proposed Standard (draft-ietf-dhc-dhcpv4-over-dhcpv6-09.txt) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 17:57:10 -0000 The IESG has approved the following document: - 'DHCPv4 over DHCPv6 Transport' (draft-ietf-dhc-dhcpv4-over-dhcpv6-09.txt) as Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ted Lemon and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6/ Technical Summary: This document specifies a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6. Working Group Summary: The WG was asked to develop a standard for how IPv4 configuration parameters could be obtained when no native IPv4 communication was necessarily possible (i.e., native DHCPv4 could not be used because there was no IPv4 transport). The WG developed several proposals and preferred this mechanism. The standard encapsulates standard DHCPv4 messages inside DHCPv6 messages to provide for transporting the DHCPv4 client requests to a server that can process the DHCPv4 requests. Please also see draft-ietf-dhc-v4configuration as it provides additional motivation and analysis of alternatives. Document Quality: This document has had thorough reviews by many interested and knowledgeable folks (beyond those mentioned in the acknowledgements section). There were no significant points of difficulty or controversy with the contents of the document, though there has been some controversy as to whether this technology is needed at all as native IPv4 (DHCPv4) could be supported directly over many "IPv6 only" technologies. An implementation has been done - see http://www.ietf.org/proceedings/89/slides/slides-89-dhc-8.pptx. Personnel: Bernie Volz is the document shepherd. Ted Lemon is the responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I read the document thoroughly, and submitted quite a few editorial suggestions to the authors, which they implemented. I believe it is ready for publication. From nobody Thu Jun 19 23:13:11 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3491A064E; Thu, 19 Jun 2014 23:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFTDNq_PBqnu; Thu, 19 Jun 2014 23:12:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 104411A0658; Thu, 19 Jun 2014 23:11:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140620061139.7260.34441.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 23:11:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/-1HmC2aWFKjbWJD0anC2vM76qsM Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 06:12:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Secure DHCPv6 with Public Key Authors : Sheng Jiang Sean Shen Dacheng Zhang Tatuya Jinmei Filename : draft-ietf-dhc-sedhcpv6-03.txt Pages : 23 Date : 2014-06-19 Abstract: The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables DHCPv6 servers to pass configuration parameters. It offers configuration flexibility. If not secured, DHCPv6 is vulnerable to various attacks, particularly spoofing attacks. This document analyzes the security issues of DHCPv6 and specifies a Secure DHCPv6 mechanism for communication between DHCPv6 clients and DHCPv6 servers. This mechanism is based on public/private key pairs. The authority of the sender may depend on either pre-configuration mechanism or Public Key Infrastructure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-sedhcpv6-03 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 nobody Thu Jun 19 23:21:49 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C7A1A064A for ; Thu, 19 Jun 2014 23:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUJmET5FStkh for ; Thu, 19 Jun 2014 23:21:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4681A0646 for ; Thu, 19 Jun 2014 23:21:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIV08188; Fri, 20 Jun 2014 06:21:44 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Jun 2014 07:21:44 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 20 Jun 2014 14:21:38 +0800 From: Sheng Jiang To: dhcwg Thread-Topic: New Version Notification for draft-ietf-dhc-sedhcpv6-03.txt Thread-Index: AQHPjE61ZsQ4p1Tk7E2krDTsVSBXEZt5hhaA Date: Fri, 20 Jun 2014 06:21:38 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE8F024@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/lH2mXSTy0MKHeE7R1S2Zpd16vYo Subject: [dhcwg] FW: New Version Notification for draft-ietf-dhc-sedhcpv6-03.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 06:21:48 -0000 SGksIGFsbCwNCg0KVGhlIGF1dGhvcnMgaGF2ZSBzdWJtaXR0ZWQgYW4gdXBkYXRlIHZlcnNpb24g aW4gb3JkZXIgdG8gYWRkcmVzc2VkIGNvbW1lbnRzIGZyb20gV0dMQy4gIA0KDQogIEFkZGVkIGEg bmV3IHNlY3Rpb24gIkRlcGxveW1lbnQgQ29uc2lkZXJhdGlvbiI7DQogIENvcnJlY3RlZCB0aGUg Zm9ybWF0IG9mIGZpZWxkIGluIHRoZSBQdWJsaWMgS2V5IE9wdGlvbjsNCiAgQWRkZWQgY29uc2lk ZXJhdGlvbiBmb3IgbGFyZ2UgREhDUHY2IG1lc3NhZ2UgdHJhbnNtaXNzaW9uOw0KICBBZGRlZCBU aW1lc3RhbXBGYWlsIGVycm9yIGNvZGU7DQogIFJlZmluZWQgdGhlIHJldHJhbnNtaXNzaW9uIHJ1 bGVzIG9uIGNsaWVudHM7DQogIFJlZmluZWQgdGhlIHRleHQgYW5kIHR5cG9zLg0KDQpNb3JlIHJl dmlld3MgYW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCg0KQmVzdCByZWdhcmRzLA0KDQpT aGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+U2VudDogRnJp ZGF5LCBKdW5lIDIwLCAyMDE0IDI6MTIgUE0NCj5UbzogU2VhbiBTaGVuOyBaaGFuZ2RhY2hlbmcg KERhY2hlbmcpOyBUYXR1eWEgSmlubWVpOyBTaGVuZyBKaWFuZzsNCj5aaGFuZ2RhY2hlbmcgKERh Y2hlbmcpOyBTaGVuZyBKaWFuZzsgVGF0dXlhIEppbm1laTsgU2VhbiBTaGVuDQo+U3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0wMy50 eHQNCj4NCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYt MDMudHh0DQo+aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTaGVuZyBKaWFuZyBh bmQgcG9zdGVkIHRvIHRoZQ0KPklFVEYgcmVwb3NpdG9yeS4NCj4NCj5OYW1lOgkJZHJhZnQtaWV0 Zi1kaGMtc2VkaGNwdjYNCj5SZXZpc2lvbjoJMDMNCj5UaXRsZToJCVNlY3VyZSBESENQdjYgd2l0 aCBQdWJsaWMgS2V5DQo+RG9jdW1lbnQgZGF0ZToJMjAxNC0wNi0xOQ0KPkdyb3VwOgkJZGhjDQo+ UGFnZXM6CQkyMw0KPlVSTDoNCj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLWRoYy1zZWRoY3B2Ni0wMy50eHQNCj5TdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMtc2VkaGNwdjYvDQo+SHRtbGl6 ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGhjLXNlZGhj cHY2LTAzDQo+RGlmZjoNCj5odHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWRoYy1zZWRoY3B2Ni0wMw0KPg0KPkFic3RyYWN0Og0KPiAgIFRoZSBEeW5hbWljIEhvc3Qg Q29uZmlndXJhdGlvbiBQcm90b2NvbCBmb3IgSVB2NiAoREhDUHY2KSBlbmFibGVzDQo+ICAgREhD UHY2IHNlcnZlcnMgdG8gcGFzcyBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMuICBJdCBvZmZlcnMN Cj4gICBjb25maWd1cmF0aW9uIGZsZXhpYmlsaXR5LiAgSWYgbm90IHNlY3VyZWQsIERIQ1B2NiBp cyB2dWxuZXJhYmxlIHRvDQo+ICAgdmFyaW91cyBhdHRhY2tzLCBwYXJ0aWN1bGFybHkgc3Bvb2Zp bmcgYXR0YWNrcy4gIFRoaXMgZG9jdW1lbnQNCj4gICBhbmFseXplcyB0aGUgc2VjdXJpdHkgaXNz dWVzIG9mIERIQ1B2NiBhbmQgc3BlY2lmaWVzIGEgU2VjdXJlIERIQ1B2Ng0KPiAgIG1lY2hhbmlz bSBmb3IgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIERIQ1B2NiBjbGllbnRzIGFuZCBESENQdjYNCj4g ICBzZXJ2ZXJzLiAgVGhpcyBtZWNoYW5pc20gaXMgYmFzZWQgb24gcHVibGljL3ByaXZhdGUga2V5 IHBhaXJzLiAgVGhlDQo+ICAgYXV0aG9yaXR5IG9mIHRoZSBzZW5kZXIgbWF5IGRlcGVuZCBvbiBl aXRoZXIgcHJlLWNvbmZpZ3VyYXRpb24NCj4gICBtZWNoYW5pc20gb3IgUHVibGljIEtleSBJbmZy YXN0cnVjdHVyZS4NCj4NCj4NCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+dW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCj4NCj5UaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Jun 20 12:05:05 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9111B28D1; Fri, 20 Jun 2014 12:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffG5PfsfWw8J; Fri, 20 Jun 2014 12:05:01 -0700 (PDT) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B0A1B28CC; Fri, 20 Jun 2014 12:05:00 -0700 (PDT) Received: by mail-yk0-f181.google.com with SMTP id 9so2984749ykp.12 for ; Fri, 20 Jun 2014 12:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=v33LsEjH4Joo1ctKgg7MIn3mOESb9VFfG5kZiIyBvyQ=; b=UWiNDDBxGOliQOI2H5k4Ur1Yh0/aGCHPOb4fvViFjsNprdLcUWGEXZ0dIVY+Wt0kvA 6FKdQTt7ar5jYSiMU37LM4dePZJi1bJu0yMFyPz0eJJcyKD89nMOq9j+IWZP+RLu7/5w NmcsbFECt+oRiONjPtj2KTzTxD5tylww/eAFWPvU40qdpenOQvOzZqidSayt+/F0QjV/ S2aCqDJzjrh9EON2hzXqx2Xp+PAl1elgLpGu29HU+0gJ9+HpyCS0wr5UmjMvlS6Y8LoK UOiALQiLMBTJTRUsccAzEgOGpzSadVkDNe6YmAtpdy3TLp4MUztOiYlnarE5ygIXms1w Q+/w== MIME-Version: 1.0 X-Received: by 10.236.207.33 with SMTP id m21mr7652085yho.71.1403291100345; Fri, 20 Jun 2014 12:05:00 -0700 (PDT) Received: by 10.170.132.134 with HTTP; Fri, 20 Jun 2014 12:05:00 -0700 (PDT) Date: Fri, 20 Jun 2014 14:05:00 -0500 Message-ID: From: Behcet Sarikaya To: "6man@ietf.org" <6man@ietf.org>, "dhcwg@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/oi-d7a_uavLn0Xenkec0aFKLcFE Subject: [dhcwg] New Version Notification for draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 19:05:02 -0000 A new version of I-D, draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-dhc-dhcpv6-raoptions-sadr Revision: 00 Title: DHCPv6 Route Options for Source Address Dependent Routing Document date: 2014-06-20 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-dhc-dhcpv6-raoptions-sadr/ Htmlized: http://tools.ietf.org/html/draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00 Abstract: This document describes DHCPv6 Route Options for provisioning IPv6 routes on DHCPv6 client nodes for source address dependent routing. Using these options, an operator can configure multi-homed nodes where other means of route configuration may be impractical. From nobody Mon Jun 23 07:19:24 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EAF1B2961 for ; Mon, 23 Jun 2014 07:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyBTSgvV7q5D for ; Mon, 23 Jun 2014 07:19:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A9B1B2AF8 for ; Mon, 23 Jun 2014 07:19:21 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s5NEJKQe017346 for ; Mon, 23 Jun 2014 16:19:20 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201406231419.s5NEJKQe017346@givry.fdupont.fr> From: Francis Dupont To: dhcwg@ietf.org Date: Mon, 23 Jun 2014 16:19:20 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/qoI26kkJ5iPKnql0C7UidVZRHyE Subject: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 14:19:23 -0000 Timestamps are not enough for the anti-replay protection and are difficult to implement for clients without a good long term real time clock, so I propose: - to introduce a nonce option which will be processed as an extension of the transaction ID (so there are already 3 octets) - to put the timestamp in its own option (so it can be omitted) - to document a way for an unsynchronized node to get a good time value, for instance sending an Information-Request or a Solicit without rapid-commit asking for a timestamp option in the ORO I propose to require the timestamp option in all messages changing the state (e.g., request, renew, etc) and everything from agents. I don't propose to make nonces mandatory but there is no good reason to not use them as soon as they are supported. A still open problem is what to do with clock mismatch between agents but this has in fact only an impact on optimization (multicast to more than one agent) so IMHO we can live with it. The second point is about (X.509 public key) certificates. They are useless without the trust anchor, the whole chain, CRLs, etc. And if we want to use self-signed certificates they bring nothing compared to raw public keys. And I don't talk about profiles (even SeND had to be completed by RFC 6494). So I really suggest to drop the certificate option and to use the key option to identify the public key. The last point is compatibility with SeND (RFC 3971). Today in red and black (:-) environments it is possible to secure the Neighbor Discovery but not DHCP. I propose to fix this using the secure DHCPv6 for the protection of DHCP and the SeND section 6 Authorization Delegation Discovery for the "certificate part". Regards Francis.Dupont@fdupont.fr From nobody Mon Jun 23 11:59:26 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22921B2C96 for ; Mon, 23 Jun 2014 11:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.751 X-Spam-Level: X-Spam-Status: No, score=-13.751 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7ExK1CUNvS2 for ; Mon, 23 Jun 2014 11:59:20 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADC81B2CEE for ; Mon, 23 Jun 2014 11:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13203; q=dns/txt; s=iport; t=1403549782; x=1404759382; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=TdB9pyLHNQ0K8p3U9jSE4tC6qsJWr1CEUlGrqn0En1I=; b=L0WjzEZey9p4Q92ZHUqGOvQLv4qbtY2U1crUfNMf8wWSL7PQcnHHNtyH 0u+UGbnkr2bOeSsknYGyYtZPHkHS7xPMOzxmrB0cFW3kQuzo9dTLPH9Y5 tdUUoWlnql7sNJDZPjSh59/Y8nZmJjmW0yhup3YJ0wGMpqgEs7aJy1dU4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAAd4qFOtJA2H/2dsb2JhbABZgkZHUlqqQAEBAQEBB5k1AYEPFnWEAwEBAQQtXAIBCBEDAQEBCx0HMhQJCAIEEwgBiDkNxG8XhWOFd4JxIBcBgy2BFgSuL4NCbIFE X-IronPort-AV: E=Sophos;i="5.01,532,1400025600"; d="scan'208,217";a="335115627" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 23 Jun 2014 18:56:21 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5NIuLLx001292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jun 2014 18:56:21 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 23 Jun 2014 13:56:21 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20-25) Thread-Index: AQHPjxTS1vkzZcGyB0iWNVPM9SF3Uw== Date: Mon, 23 Jun 2014 18:56:20 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5D3ADA@xmb-rcd-x04.cisco.com> References: <489D13FBFA9B3E41812EA89F188F018E1B5C38A3@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5C38A3@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.247.100] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1B5D3ADAxmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/miEtZunIZ9niHA3ZoK-0ZvOFklQ Subject: Re: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20-25) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2014 18:59:23 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1B5D3ADAxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reminder to send Agenda items. Our agenda at present is: Date: Wednesday July 23, 0900-1130, Salon B [SUBJECT TO CHANGE] Chairs: Tomek Mrugalski & Bernie Volz Secretary: Sheng Jiang (NEW!) Presentations materials: https://datatracker.ietf.org/meeting/90/materi= als.html#wg-dhc 1. Co-Chairs - Administrativia (WG Status & Agenda Bashing) - 10 minut= es 2. Tomek Mrugalski, RFC-3315bis Issues (draft-dhcwg-dhc-rfc3315bis) - = 20 minutes 3. Ole Troan, Bernie Volz - DHCPv6 Stateful Issues Draft Update - 20 m= inutes 4. Sheng Jiang or Suresh Krishnan - draft-ietf-dhc-addr-registration-0= 5 - 10 minutes 5. Tomek Mrugalsk - draft-ietf-dhc-topo-conf-02 - 5 minutes - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz) Sent: Monday, June 16, 2014 8:40 AM To: dhcwg@ietf.org Subject: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, July 20= -25) Hi: Please send us (dhc-chairs@tools.ietf.org= ) requests for sessions for the DHC WG meeting in Toronto. Include: Name of session: Name of draft(s): Time requested: Presenter name(s): Brief description of what issues need discussing and what you hope to accom= plish by presenting: More details about the Toronto IETF can be found at http://www.ietf.org/mee= ting/90/index.html. - Tomek & Bernie --_000_489D13FBFA9B3E41812EA89F188F018E1B5D3ADAxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Reminder to send Agend= a items.

 

Our agenda at present = is:

 

    Dat= e: Wednesday July 23, 0900-1130, Salon B  [SUBJECT TO CHANGE]

    Cha= irs: Tomek Mrugalski & Bernie Volz

    Sec= retary: Sheng Jiang (NEW!)

    Pre= sentations materials: https://datatracker.ietf.org/meeting/90/materials.htm= l#wg-dhc

 

   &nbs= p; 1. Co-Chairs - Administrativia (WG Status & Agenda Bashing) - 10 min= utes

   &nbs= p; 2. Tomek Mrugalski, RFC-3315bis Issues (draft-dhcwg-dhc-rfc3315bis) - 20= minutes

   &nbs= p; 3. Ole Troan, Bernie Volz - DHCPv6 Stateful Issues Draft Update - 20 min= utes

   &nbs= p; 4. Sheng Jiang or Suresh Krishnan - draft-ietf-dhc-addr-registration-05 = - 10 minutes

   &nbs= p; 5. Tomek Mrugalsk - draft-ietf-dhc-topo-conf-02 - 5 minutes

 

-&nb= sp;         Bernie

 

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Monday, June 16, 2014 8:40 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Reminder - Need Agenda Items for Toronto (IETF-90, = July 20-25)

 

Hi:

 =

Please send us (dhc-chair= s@tools.ietf.org) requests for sessions for the DHC WG meeting i= n Toronto. Include:

 =

Name of session:

Name of draft(s):

Time requested:

Presenter name(s):<= /o:p>

Brief description of wha= t issues need discussing and what you hope to accomplish by presenting:

 =

More details about the T= oronto IETF can be found at http://www.ietf.org/meeting/90/index.html.

 =

- = ;         Tomek & Bern= ie

--_000_489D13FBFA9B3E41812EA89F188F018E1B5D3ADAxmbrcdx04ciscoc_-- From nobody Mon Jun 23 17:57:47 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A1F1A0503 for ; Mon, 23 Jun 2014 17:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHg_BhTPHO8W for ; Mon, 23 Jun 2014 17:57:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24CA1A049C for ; Mon, 23 Jun 2014 17:57:40 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.969.15; Tue, 24 Jun 2014 00:57:39 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.23]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.23]) with mapi id 15.00.0969.007; Tue, 24 Jun 2014 00:57:39 +0000 From: Kent Watsen To: "dhcwg@ietf.org" Thread-Topic: proposal for new global options Thread-Index: AQHPj0dLXOlBjtd4002R4EH7rllsuQ== Date: Tue, 24 Jun 2014 00:57:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02524402D6 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(164054003)(479174003)(199002)(189002)(50986999)(87936001)(54356999)(85306003)(85852003)(106356001)(21056001)(2656002)(83506001)(15395725005)(80022001)(99396002)(83072002)(81542001)(105586002)(31966008)(15975445006)(74662001)(81342001)(16236675004)(101416001)(106116001)(20776003)(83322001)(66066001)(36756003)(19580395003)(64706001)(46102001)(15202345003)(95666004)(99286002)(79102001)(74502001)(77982001)(76482001)(77096002)(92726001)(86362001)(92566001)(4396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CFCE453F78652kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/2TTPZGONfy5Q2sdQQf1NGhDnO7k Subject: [dhcwg] proposal for new global options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 00:57:45 -0000 --_000_CFCE453F78652kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [first timer on this list] The NETCONF WG has recently chartered a draft for ZeroTouch. I'm currently working on draft-ietf-netconf-zerotouch-00, which hasn't been posted yet, but the previous I-D is here: http://datatracker.ietf.org/doc/draft-kwatsen-netconf-zerotouch/. This draft regards devices bootstrapping their management connection to a network management system (NMS). The draft currently states that devices MAY upgrade their software and/or download initial configuration first, but that how to do so is unspecified. The expectation was that DHCPv4 options 60/61/43 or DHCPv6 options 1/16/17 could be used. There was discussion during the presentation in London regarding a desire to have an IETF-defined solution that wasn't vendor-specific, which is what this email regards. The ZeroTouch solution assumes that the devices have an IEEE 802.1AR (Secure Device Identity), essentially an X.509 certificate that uniquely identifies it. Assuming devices from different vendors have said certificates, we can construct a vendor-independent solution as follows: - have DHCP server send in its OFFER message one option encoding two sets of URIs - one for downloading software image - one for downloading configuration file - specify that when device accesses any URI, it first postpends the fingerprint of its IEEE 802.1AR certificate, for instance: - http://example.com/zerotouch/image?device=3D - http://example.com/zerotouch/config?device=3D Thus a vendor-neutral solution. Questions: 1) Is there merit to this approach? - any concerns? 2) Should a separate draft be submitted to DHCWG, or can I put the IANA requests into the NETCONF WG draft? 3) Is it necessary to define options for both IPv4 and IPv6? Thanks, Kent --_000_CFCE453F78652kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <55AC8852BF07DD4DB1ABA13E80BDBFDA@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
[first timer on this list]

The NETCONF WG has recently chartere= d a draft for ZeroTouch.   I'm
currently working on draft-ietf-netc= onf-zerotouch-00, which hasn't been
posted yet, but the previous I-D is = here:
http://datatracker.ietf.org/doc/draf= t-kwatsen-netconf-zerotouch/.

This draft regards devices bootstrap= ping their management connection to a
network management system (NMS). &nb= sp; The draft currently states that devices
MAY upgrade their software and/or do= wnload initial configuration first,
but that how to do so is unspecified= .  The expectation was that DHCPv4
options 60/61/43 or DHCPv6 options 1= /16/17 could be used.   There was
discussion during the presentation i= n London regarding a desire to have an
IETF-defined solution that wasn't ve= ndor-specific, which is what this
email regards.

The ZeroTouch solution assumes that = the devices have an IEEE 802.1AR
(Secure Device Identity), essentiall= y an X.509 certificate that uniquely
identifies it.   Assuming devic= es from different vendors have said
certificates, we can construct a ven= dor-independent solution as follows:

    - have DHCP server sen= d in its OFFER message one option encoding two
      sets of URIs
         - = one for downloading software image
         - = one for downloading configuration file
     - specify that w= hen device accesses any URI, it first postpends the
       fingerpri= nt of its IEEE 802.1AR certificate, for instance:
         - = http://example.com/zerotouch/image?device=3D<fingerprint>
         - = http://example.com/zerotouch/config?device=3D<fingerprint>


Thus a vendor-neutral solution.


Questions:

1) Is there merit to this approach? =  - any concerns?
2) Should a separate draft be submit= ted to DHCWG, or can I put the IANA
requests into the NETCONF WG draft?<= /font>
3) Is it necessary to define options= for both IPv4 and IPv6?


Thanks,
Kent


--_000_CFCE453F78652kwatsenjunipernet_-- From nobody Mon Jun 23 23:13:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA17E1B2839; Mon, 23 Jun 2014 23:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhHGAC7-1V2E; Mon, 23 Jun 2014 23:13:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 316E41B283A; Mon, 23 Jun 2014 23:13:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140624061302.22595.65556.idtracker@ietfa.amsl.com> Date: Mon, 23 Jun 2014 23:13:02 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/NSxI42mE15gSNJgappBa5CkpqCs Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-addr-registration-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 06:13:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Registering Self-generated IPv6 Addresses in DNS using DHCPv6 Authors : Sheng Jiang Gang Chen Suresh Krishnan Rajiv Asati Filename : draft-ietf-dhc-addr-registration-05.txt Pages : 8 Date : 2014-06-23 Abstract: In networks that are centrally managed, self-generated addresses cause some traceability issues due to their decentralized nature. One of the most important issues in this regard is the inability to register such addresses in DNS. This document defines a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-addr-registration-05 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 nobody Mon Jun 23 23:16:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A131B283A for ; Mon, 23 Jun 2014 23:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7dWqQz7VoK6 for ; Mon, 23 Jun 2014 23:16:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE6AD1B2839 for ; Mon, 23 Jun 2014 23:16:42 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJD00035; Tue, 24 Jun 2014 06:16:41 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Jun 2014 07:15:38 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0158.001; Tue, 24 Jun 2014 14:15:35 +0800 From: Sheng Jiang To: "dhcwg@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dhc-addr-registration-05.txt Thread-Index: AQHPj3NvBf4tyNHnxkyDrQ6e74mlpJt/yBiA Date: Tue, 24 Jun 2014 06:15:33 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AEB5A83@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/fcWc4JTVR76rIM61sbrH4QfvKYk Subject: [dhcwg] FW: New Version Notification for draft-ietf-dhc-addr-registration-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 06:16:45 -0000 SGksIGFsbCwNCg0KVGhlIGF1dGhvcnMgaGF2ZSBzdWJtaXR0ZWQgYW4gdXBkYXRlIHZlcnNpb24u IFdlIGJlbGlldmUgYWxsIHJlY2VpdmVkIGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQuIE1v ZGlmaWNhdGlvbnMgYXJlIHN1bW1hcml6ZWQgYXMgYmVsb3c6DQoNCiAtIE1hbmRhdGVkIHNlcnZl cidzIHJlc3BvbnNlIGZvciBlcnJvciBjb2RlLg0KIC0gQWRkZWQgcmVjb21tZW5kYXRpb24gZm9y IG9ubHkgb25lIHJlZ2lzdHJhdGlvbiBzZXJ2ZXIgb3V0IG9mIG11bHRpcGxlIERIQ1B2NiBzZXJ2 ZXJzLg0KIC0gQWRkZWQgc3BlY2lmaWNhdGlvbiB0aGF0IHRoZSByZWdpc3RyYXRpb24gc2VydmVy IHNob3VsZCByZWNvcmQgdGhlIGJpbmRpbmcgaW5mb3JtYXRpb24uDQogLSBBbGxvd2VkIG11bHRp cGxlIElBX05BLg0KIC0gQ2xhcmlmaWVkIHRoYXQgdGhlIEFERFItUkVHSVNUUkFUSU9OLVJFUVVF U1QgbWVzc2FnZSBpcyBkZWRpY2F0ZWQgZm9yIGNsaWVudHMgdG8gaW5pdGlhdGUgYW4gYWRkcmVz cyByZWdpc3RyYXRpb24gcmVxdWVzdC4gU28sIGNsaWVudHMgTVVTVCBOT1QgaW5jbHVkZSBhbnkg T1JPLg0KDQpNb3JlIHJldmlld3MgYW5kIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4NCg0KQmVz dCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmddDQo+U2VudDogVHVlc2RheSwgSnVuZSAyNCwgMjAxNCAyOjEzIFBNDQo+VG86IFN1cmVzaCBL cmlzaG5hbjsgUmFqaXYgQXNhdGk7IEdhbmcgQ2hlbjsgU2hlbmcgSmlhbmc7IFN1cmVzaCBLcmlz aG5hbjsNCj5TaGVuZyBKaWFuZzsgR2FuZyBDaGVuOyBSYWppdiBBc2F0aQ0KPlN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRp b24tMDUudHh0DQo+DQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtZGhjLWFk ZHItcmVnaXN0cmF0aW9uLTA1LnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgU2hlbmcgSmlhbmcgYW5kIHBvc3RlZCB0byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+ TmFtZToJCWRyYWZ0LWlldGYtZGhjLWFkZHItcmVnaXN0cmF0aW9uDQo+UmV2aXNpb246CTA1DQo+ VGl0bGU6CQlSZWdpc3RlcmluZyBTZWxmLWdlbmVyYXRlZCBJUHY2IEFkZHJlc3NlcyBpbiBETlMg dXNpbmcgREhDUHY2DQo+RG9jdW1lbnQgZGF0ZToJMjAxNC0wNi0yMw0KPkdyb3VwOgkJZGhjDQo+ UGFnZXM6CQk4DQo+VVJMOg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtZGhjLWFkZHItcmVnaXN0cmF0aW9uLTA1LnR4dA0KPlN0YXR1czoNCj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRoYy1hZGRyLXJlZ2lzdHJhdGlv bi8NCj5IdG1saXplZDoNCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRo Yy1hZGRyLXJlZ2lzdHJhdGlvbi0wNQ0KPkRpZmY6DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1kaGMtYWRkci1yZWdpc3RyYXRpb24tMDUNCj4NCj5BYnN0cmFj dDoNCj4gICBJbiBuZXR3b3JrcyB0aGF0IGFyZSBjZW50cmFsbHkgbWFuYWdlZCwgc2VsZi1nZW5l cmF0ZWQgYWRkcmVzc2VzDQo+ICAgY2F1c2Ugc29tZSB0cmFjZWFiaWxpdHkgaXNzdWVzIGR1ZSB0 byB0aGVpciBkZWNlbnRyYWxpemVkIG5hdHVyZS4NCj4gICBPbmUgb2YgdGhlIG1vc3QgaW1wb3J0 YW50IGlzc3VlcyBpbiB0aGlzIHJlZ2FyZCBpcyB0aGUgaW5hYmlsaXR5IHRvDQo+ICAgcmVnaXN0 ZXIgc3VjaCBhZGRyZXNzZXMgaW4gRE5TLiAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbWVjaGFu aXNtIHRvDQo+ICAgcmVnaXN0ZXIgc2VsZi1nZW5lcmF0ZWQgYW5kIHN0YXRpY2FsbHkgY29uZmln dXJlZCBhZGRyZXNzZXMgaW4gRE5TDQo+ICAgdGhyb3VnaCBhIERIQ1B2NiBzZXJ2ZXIuDQo+DQo+ DQo+DQo+DQo+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+VGhlIElFVEYg U2VjcmV0YXJpYXQNCg0K From nobody Tue Jun 24 11:51:38 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C711B27CD for ; Tue, 24 Jun 2014 11:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA9LA2Mi0AUi for ; Tue, 24 Jun 2014 11:51:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 769A51A039C for ; Tue, 24 Jun 2014 11:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19790; q=dns/txt; s=iport; t=1403635892; x=1404845492; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DFv4/XF0tL3dcTuj4qPiXyROOQX50vLZEW8cmLWooHg=; b=DEQtTVjAsT3yYNnOOm5WkPL+azPli2OXDG7/lPElFo5B2D1aLkIDHA+c p7j7XiTL8KByYcNqvXNLCyYTYJoP3hFKqGGC9IWXxEFJ0+X+ZSuo/gE9z UXc8OKWUeLeeIjRetmesrw+ndtfNuhEqrjSOq7VRfRUSm0IPJ9IqDHMRy 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcJAB/IqVOtJA2K/2dsb2JhbABRCYJGR1JaqkAFAYMPjRaJFQGBChZ1hAMBAQEELVwCAQgOAwQBAQsWBwcyFAkIAgQBEggTiCcNyjYXhWOINwcHAwEfNwEGgyeBFgWcF5Ilg0KBdzk X-IronPort-AV: E=Sophos;i="5.01,539,1400025600"; d="scan'208,217";a="335327214" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jun 2014 18:51:31 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5OIpV5b007567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jun 2014 18:51:31 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.231]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 24 Jun 2014 13:51:31 -0500 From: "Bernie Volz (volz)" To: Kent Watsen , "dhcwg@ietf.org" Thread-Topic: proposal for new global options Thread-Index: AQHPj0dLXOlBjtd4002R4EH7rllsuZuAmbcQ Date: Tue, 24 Jun 2014 18:51:30 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5D692C@xmb-rcd-x04.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.70.115] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1B5D692Cxmbrcdx04ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/2lm-mtw74yClu7AWypRK2bdhfis Subject: Re: [dhcwg] proposal for new global options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 18:51:35 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1B5D692Cxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here's my personal answer (DHC WG co-chair hat off): 1) Is there merit to this approach? - any concerns? I will punt on this one for now. 2) Should a separate draft be submitted to DHCWG, or can I put the IANA requests into the NETCONF WG draft? As these are just 'data options' (not protocol options), you can do this in= the NETCONF WG draft. Please look at RFC 7227, Guidelines for Creating New= DHCPv6 Options. These guidelines also generally apply to DHCPv4. 3) Is it necessary to define options for both IPv4 and IPv6? Yes. If you want to support both DHCPv4 and DHCPv6, you would have to defin= e separate DHCPv4 and DHCPv6 options. Note that for downloading images, DHCPv4 and DHCPv6 already have options to= support this. For example, the DHCPv6 document is RFC 5970. (The DHCPv4 is= covered in RFC 2132 and isn't a URI.) - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Monday, June 23, 2014 8:58 PM To: dhcwg@ietf.org Subject: [dhcwg] proposal for new global options [first timer on this list] The NETCONF WG has recently chartered a draft for ZeroTouch. I'm currently working on draft-ietf-netconf-zerotouch-00, which hasn't been posted yet, but the previous I-D is here: http://datatracker.ietf.org/doc/draft-kwatsen-netconf-zerotouch/. This draft regards devices bootstrapping their management connection to a network management system (NMS). The draft currently states that devices MAY upgrade their software and/or download initial configuration first, but that how to do so is unspecified. The expectation was that DHCPv4 options 60/61/43 or DHCPv6 options 1/16/17 could be used. There was discussion during the presentation in London regarding a desire to have an IETF-defined solution that wasn't vendor-specific, which is what this email regards. The ZeroTouch solution assumes that the devices have an IEEE 802.1AR (Secure Device Identity), essentially an X.509 certificate that uniquely identifies it. Assuming devices from different vendors have said certificates, we can construct a vendor-independent solution as follows: - have DHCP server send in its OFFER message one option encoding two sets of URIs - one for downloading software image - one for downloading configuration file - specify that when device accesses any URI, it first postpends the fingerprint of its IEEE 802.1AR certificate, for instance: - http://example.com/zerotouch/image?device=3D> - http://example.com/zerotouch/config?device=3D> Thus a vendor-neutral solution. Questions: 1) Is there merit to this approach? - any concerns? 2) Should a separate draft be submitted to DHCWG, or can I put the IANA requests into the NETCONF WG draft? 3) Is it necessary to define options for both IPv4 and IPv6? Thanks, Kent --_000_489D13FBFA9B3E41812EA89F188F018E1B5D692Cxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here’s my personal = answer (DHC WG co-chair hat off):

 <= /p>

1) Is there merit to this approach?  - any concerns= ?

 

I will punt on this one f= or now.

 

2) Should a separate draft be submitted to DHCWG, or can= I put the IANA

requests into the NETCONF WG draft?

 

As these are just ‘= data options’ (not protocol options), you can do this in the NETCONF = WG draft. Please look at RFC 7227, Guidelines for Creating New DHCPv6 Options. These guidelines also generally apply to DHCPv4.

 

3) Is it necessary to define options for both IPv4 and I= Pv6?

 

Yes. If you want to suppo= rt both DHCPv4 and DHCPv6, you would have to define separate DHCPv4 and DHC= Pv6 options.

 <= /p>

Note that for downloading= images, DHCPv4 and DHCPv6 already have options to support this. For exampl= e, the DHCPv6 document is RFC 5970. (The DHCPv4 is covered in RFC 2132 and isn’t a URI.)

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Monday, June 23, 2014 8:58 PM
To: dhcwg@ietf.org
Subject: [dhcwg] proposal for new global options

 

[first timer on this list]

 

The NETCONF WG has recently chartered a draft for ZeroTo= uch.   I'm

currently working on draft-ietf-netconf-zerotouch-00, wh= ich hasn't been

posted yet, but the previous I-D is here:

 

This draft regards devices bootstrapping their managemen= t connection to a

network management system (NMS).   The draft curren= tly states that devices

MAY upgrade their software and/or download initial confi= guration first,

but that how to do so is unspecified.  The expectat= ion was that DHCPv4

options 60/61/43 or DHCPv6 options 1/16/17 could be used= .   There was

discussion during the presentation in London regarding a= desire to have an

IETF-defined solution that wasn't vendor-specific, which= is what this

email regards.

 

The ZeroTouch solution assumes that the devices have an = IEEE 802.1AR

(Secure Device Identity), essentially an X.509 certifica= te that uniquely

identifies it.   Assuming devices from different ve= ndors have said

certificates, we can construct a vendor-independent solu= tion as follows:

 

    - have DHCP server send in its OFFER messa= ge one option encoding two

      sets of URIs

         - one for downloading = software image

         - one for downloading = configuration file

     - specify that when device accesses = any URI, it first postpends the

       fingerprint of its IEEE 802.1= AR certificate, for instance:

 

 

Thus a vendor-neutral solution.

 

 

Questions:

 

1) Is there merit to this approach?  - any concerns= ?

2) Should a separate draft be submitted to DHCWG, or can= I put the IANA

requests into the NETCONF WG draft?

3) Is it necessary to define options for both IPv4 and I= Pv6?

 

 

Thanks,

Kent

 

 

--_000_489D13FBFA9B3E41812EA89F188F018E1B5D692Cxmbrcdx04ciscoc_-- From nobody Wed Jun 25 01:16:55 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6981B2B09 for ; Wed, 25 Jun 2014 01:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOHz6dLGlSYA for ; Wed, 25 Jun 2014 01:16:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D9B1B2AFB for ; Wed, 25 Jun 2014 01:16:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BGL18413; Wed, 25 Jun 2014 08:16:47 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Jun 2014 09:16:46 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Wed, 25 Jun 2014 16:16:38 +0800 From: Sheng Jiang To: Francis Dupont , "dhcwg@ietf.org" Thread-Topic: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt Thread-Index: AQHPju4mG27LeCnUK0SEcxzM0SNIlpuBeh4g Date: Wed, 25 Jun 2014 08:16:37 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AEBC702@nkgeml512-mbx.china.huawei.com> References: <201406231419.s5NEJKQe017346@givry.fdupont.fr> In-Reply-To: <201406231419.s5NEJKQe017346@givry.fdupont.fr> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/EuUXW6xYYt8di5kSV3u6N0hNK-Q Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 08:16:51 -0000 SGksIEZyYW5jaXMsDQoNClBsZWFzZSBzZWUgcmVwbGllcyBpbiBsaW5lcy4NCg0KPlRpbWVzdGFt cHMgYXJlIG5vdCBlbm91Z2ggZm9yIHRoZSBhbnRpLXJlcGxheSBwcm90ZWN0aW9uIGFuZA0KPmFy ZSBkaWZmaWN1bHQgdG8gaW1wbGVtZW50IGZvciBjbGllbnRzIHdpdGhvdXQgYSBnb29kIGxvbmcg dGVybQ0KPnJlYWwgdGltZSBjbG9jaywgc28gSSBwcm9wb3NlOg0KPiAtIHRvIGludHJvZHVjZSBh IG5vbmNlIG9wdGlvbiB3aGljaCB3aWxsIGJlIHByb2Nlc3NlZCBhcyBhbiBleHRlbnNpb24NCj4g IG9mIHRoZSB0cmFuc2FjdGlvbiBJRCAoc28gdGhlcmUgYXJlIGFscmVhZHkgMyBvY3RldHMpDQo+ IC0gdG8gcHV0IHRoZSB0aW1lc3RhbXAgaW4gaXRzIG93biBvcHRpb24gKHNvIGl0IGNhbiBiZSBv bWl0dGVkKQ0KDQpXZSBjb3VsZCBhcHBseSB0aGlzIHRvIG5leHQgdmVyc2lvbi4NCg0KPiAtIHRv IGRvY3VtZW50IGEgd2F5IGZvciBhbiB1bnN5bmNocm9uaXplZCBub2RlIHRvIGdldCBhIGdvb2Qg dGltZSB2YWx1ZSwNCj4gIGZvciBpbnN0YW5jZSBzZW5kaW5nIGFuIEluZm9ybWF0aW9uLVJlcXVl c3Qgb3IgYSBTb2xpY2l0IHdpdGhvdXQNCj4gIHJhcGlkLWNvbW1pdCBhc2tpbmcgZm9yIGEgdGlt ZXN0YW1wIG9wdGlvbiBpbiB0aGUgT1JPDQoNClRoaXMgaGFzIHRvIGJlIGEgc2VwYXJhdGVkIGRv Y3VtZW50LiBJdCByZW1haW5zIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkb2N1bWVudC4gSW4gbW9z dCBvZiBjYXNlcywgaXQgaXMgb2sgdG8gYXNzdW1lIGEgbm9kZSBoYXZlIGEgdGltZSB3aGljaCBo YXMgbGVzcyA1LW1pbiB0aW1lIGRyaWZ0LiBBIGJyYW5kIG5ldyBub2RlIHdpdGhvdXQgYW55IGtu b3dsZWRnZSBvZiB0aW1lIGlzIGFuIGVkZ2UgY2FzZS4NCg0KPkkgcHJvcG9zZSB0byByZXF1aXJl IHRoZSB0aW1lc3RhbXAgb3B0aW9uIGluIGFsbCBtZXNzYWdlcyBjaGFuZ2luZyB0aGUNCj5zdGF0 ZSAoZS5nLiwgcmVxdWVzdCwgcmVuZXcsIGV0YykgYW5kIGV2ZXJ5dGhpbmcgZnJvbSBhZ2VudHMu DQo+SSBkb24ndCBwcm9wb3NlIHRvIG1ha2Ugbm9uY2VzIG1hbmRhdG9yeSBidXQgdGhlcmUgaXMg bm8gZ29vZCByZWFzb24NCj50byBub3QgdXNlIHRoZW0gYXMgc29vbiBhcyB0aGV5IGFyZSBzdXBw b3J0ZWQuDQoNCkl0J3MgcmVhc29uYWJsZS4NCg0KPlRoZSBzZWNvbmQgcG9pbnQgaXMgYWJvdXQg KFguNTA5IHB1YmxpYyBrZXkpIGNlcnRpZmljYXRlcy4gVGhleSBhcmUgdXNlbGVzcw0KPndpdGhv dXQgdGhlIHRydXN0IGFuY2hvciwgdGhlIHdob2xlIGNoYWluLCBDUkxzLCBldGMuIEFuZCBpZiB3 ZSB3YW50DQo+dG8gdXNlIHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlcyB0aGV5IGJyaW5nIG5vdGhp bmcgY29tcGFyZWQgdG8gcmF3DQo+cHVibGljIGtleXMuIEFuZCBJIGRvbid0IHRhbGsgYWJvdXQg cHJvZmlsZXMgKGV2ZW4gU2VORCBoYWQgdG8gYmUNCj5jb21wbGV0ZWQgYnkgUkZDIDY0OTQpLiBT byBJIHJlYWxseSBzdWdnZXN0IHRvIGRyb3AgdGhlIGNlcnRpZmljYXRlDQo+b3B0aW9uIGFuZCB0 byB1c2UgdGhlIGtleSBvcHRpb24gdG8gaWRlbnRpZnkgdGhlIHB1YmxpYyBrZXkuDQoNCkFjdHVh bGx5LCBjZXJ0aWZpY2F0ZSB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bCBmb3Igc2VydmVyIHRvIGF1dGhv cml6ZSB0aGUgY2xpZW50LiBJdCBpcyBtdWNoIGxlc3MgdXNlZnVsIG9uIGEgY2xpZW50LCB3aG8g aGF2ZSBub3QgYmVlbiBhbGxvd2VkIHRvIGNvbm5lY3Qgb24gbGluZS4gSW4gc3VjaCBjYXNlLCBj ZXJ0aWZpY2F0ZSBjYW4gYmUgdXNlZCB3aXRoIExvRiwgd2hpY2ggaXMgZXF1YWwgdXNhZ2UgYXMg aWRlbnRpZnkgdGhlIHB1YmxpYyBrZXkuDQoNCj5UaGUgbGFzdCBwb2ludCBpcyBjb21wYXRpYmls aXR5IHdpdGggU2VORCAoUkZDIDM5NzEpLiBUb2RheSBpbiByZWQgYW5kDQo+YmxhY2sgKDotKSBl bnZpcm9ubWVudHMgaXQgaXMgcG9zc2libGUgdG8gc2VjdXJlIHRoZSBOZWlnaGJvciBEaXNjb3Zl cnkNCj5idXQgbm90IERIQ1AuIEkgcHJvcG9zZSB0byBmaXggdGhpcyB1c2luZyB0aGUgc2VjdXJl IERIQ1B2NiBmb3INCj50aGUgcHJvdGVjdGlvbiBvZiBESENQIGFuZCB0aGUgU2VORCBzZWN0aW9u IDYgQXV0aG9yaXphdGlvbiBEZWxlZ2F0aW9uDQo+RGlzY292ZXJ5IGZvciB0aGUgImNlcnRpZmlj YXRlIHBhcnQiLg0KDQpDb3VsZCB5b3UgYmUgbW9yZSBjbGVhciBob3cgdGhpcyBtYXkgd29yaz8g SSBhbSBub3Qgc3VyZSBJIGZ1bGx5IHVuZGVyc3RhbmQgeW91ciBwcm9wb3NhbC4gU28gZmFyLCBT ZURIQ1B2NiBoYXMgbm8gY29tcGF0aWJpbGl0eSBpc3N1ZXMgd2l0aCBTZU5ELCBiZWNhdXNlIHRo ZXkgYXJlIHR3byBzb2x1dGlvbnMgaW5kZXBlbmRlbnQgZnJvbSBlYWNoIG90aGVyLiBXZSBkb24n dCB3YW50IHRvIGludHJvZHVjZSBhbnkgZGVwZW5kZW5jeSBiZXR3ZWVuIHRoZW0sIHdoaWNoIHdv dWxkIG1ha2UgdGhlIGRlcGxveW1lbnQgbXVjaCBtb3JlIGNvbXBsaWNhdGVkLg0KDQpCZXN0IHJl Z2FyZHMsDQoNClNoZW5nDQoNCj5SZWdhcmRzDQo+DQo+RnJhbmNpcy5EdXBvbnRAZmR1cG9udC5m cg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ZGhjd2cgbWFpbGluZyBsaXN0DQo+ZGhjd2dAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= From nobody Wed Jun 25 04:51:27 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0CC1B2BC3 for ; Wed, 25 Jun 2014 04:51:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wzmd4yNaAoB for ; Wed, 25 Jun 2014 04:51:23 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BED1B2AF3 for ; Wed, 25 Jun 2014 04:51:22 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s5PBoAh6083205; Wed, 25 Jun 2014 13:50:10 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201406251150.s5PBoAh6083205@givry.fdupont.fr> From: Francis Dupont To: Sheng Jiang In-reply-to: Your message of Wed, 25 Jun 2014 08:16:37 -0000. <5D36713D8A4E7348A7E10DF7437A4B923AEBC702@nkgeml512-mbx.china.huawei.com> Date: Wed, 25 Jun 2014 13:50:10 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/xzRdKW7Rfx-XqCFf2_rIrymEKy0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 11:51:24 -0000 In your previous mail you wrote: > > - to document a way for an unsynchronized node to get a good time value, > > for instance sending an Information-Request or a Solicit without > > rapid-commit asking for a timestamp option in the ORO > > This has to be a separated document. It remains out of scope for this docume > nt. In most of cases, it is ok to assume a node have a time which has less 5 > -min time drift. A brand new node without any knowledge of time is an edge c > ase. => to make timestamps more efficient for security you have to allow only small drift, so a pre-synchronization procedure should help to solve the unsecure/large vs secure/hard-to-implement drift. Note about the first statement I agree it is "not normative". Regards Francis.Dupont@fdupont.fr From nobody Wed Jun 25 05:06:13 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71C81B2AF3 for ; Wed, 25 Jun 2014 05:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RxKIbqXwURh for ; Wed, 25 Jun 2014 05:06:08 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9741B2BD1 for ; Wed, 25 Jun 2014 05:06:08 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s5PC61Ak084308; Wed, 25 Jun 2014 14:06:01 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201406251206.s5PC61Ak084308@givry.fdupont.fr> gFrom: Francis Dupont To: Sheng Jiang In-reply-to: Your message of Wed, 25 Jun 2014 08:16:37 -0000. <5D36713D8A4E7348A7E10DF7437A4B923AEBC702@nkgeml512-mbx.china.huawei.com> Date: Wed, 25 Jun 2014 14:06:01 +0200 From: Francis Dupont Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/XtJNJs8p_TKHs_53cmkKaWYx7YU Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 12:06:11 -0000 In your previous mail you wrote: > >The second point is about (X.509 public key) certificates. They are useless > >without the trust anchor, the whole chain, CRLs, etc. And if we want > >to use self-signed certificates they bring nothing compared to raw > >public keys. And I don't talk about profiles (even SeND had to be > >completed by RFC 6494). So I really suggest to drop the certificate > >option and to use the key option to identify the public key. > > Actually, certificate would be very useful for server to authorize the clien > t. It is much less useful on a client, who have not been allowed to connect > on line. In such case, certificate can be used with LoF, which is equal usag > e as identify the public key. => for the first point something like the URI and hash from IKEv2 is IMHO far more usable than to put the certificate inside the message. And I disagree about the second statement: there is no reason to give up about the server authorization. It is a hard problem but not an untrackable one (as SeND proved). For the last a public key option is simpler and more efficient so it is not an argument for keeping the certificate option. > >The last point is compatibility with SeND (RFC 3971). Today in red and > >black (:-) environments it is possible to secure the Neighbor Discovery > >but not DHCP. I propose to fix this using the secure DHCPv6 for > >the protection of DHCP and the SeND section 6 Authorization Delegation > >Discovery for the "certificate part". > > Could you be more clear how this may work? I am not sure I fully understand > your proposal. So far, SeDHCPv6 has no compatibility issues with SeND, becau > se they are two solutions independent from each other. We don't want to intr > oduce any dependency between them, which would make the deployment much more > complicated. => I don't want to introduce dependency but to make them to be able to work not only together but in complement, exactly as DHCPv6 and ND are (even it took a very long time to finalize all details). The missing part in SeDHCPv6 is the authorization, i.e., all the higher order thing about certificates. This is already handled in SeND, perhaps not in the best way, so the idea is to say for SeDHCPv6 + SeND we don't need to reinvent the wheel. This could leave two use cases for SeDHCPv6: LoF or statically pre-configured SeDHCPv6 using raw public keys, and SeDHCPv6 + SeND for strongly secured environments. Perhaps not the whole thing we want but enough to "sell" a first version. Regards Francis.Dupont@fdupont.fr From nobody Wed Jun 25 05:50:35 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF541B2C07 for ; Wed, 25 Jun 2014 05:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51yqNI-1STjh for ; Wed, 25 Jun 2014 05:50:33 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 688DD1B2C05 for ; Wed, 25 Jun 2014 05:50:33 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id D0FD919356; Wed, 25 Jun 2014 14:49:58 +0200 (CEST) Message-ID: <53AAC576.7070609@s-carlsen.dk> Date: Wed, 25 Jun 2014 14:49:58 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Francis Dupont , Sheng Jiang References: <201406251150.s5PBoAh6083205@givry.fdupont.fr> In-Reply-To: <201406251150.s5PBoAh6083205@givry.fdupont.fr> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/5RkTG-Vj9DYuBpVEGxL-34RRh-Q Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 12:50:35 -0000 On 25/06/14 13:50, Francis Dupont wrote: > In your previous mail you wrote: > >> > - to document a way for an unsynchronized node to get a good time value, >> > for instance sending an Information-Request or a Solicit without >> > rapid-commit asking for a timestamp option in the ORO >> >> This has to be a separated document. It remains out of scope for this docume >> nt. In most of cases, it is ok to assume a node have a time which has less 5 >> -min time drift. A brand new node without any knowledge of time is an edge c >> ase. > > => to make timestamps more efficient for security you have to allow only > small drift, so a pre-synchronization procedure should help to solve > the unsecure/large vs secure/hard-to-implement drift. To me it seems that a pre-synchronisation procedure is a great help for intruders? Now you can make sure the target is in time sync with the attack just by synchronising with it first, really opens the window for attacks. > Note about the > first statement I agree it is "not normative". > > Regards > > Francis.Dupont@fdupont.fr > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" From nobody Wed Jun 25 20:49:26 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618371B2A52 for ; Wed, 25 Jun 2014 20:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JS5QmbK6sAow for ; Wed, 25 Jun 2014 20:49:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD061B29D2 for ; Wed, 25 Jun 2014 20:49:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJG75493; Thu, 26 Jun 2014 03:49:20 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Jun 2014 04:49:20 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.249]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Thu, 26 Jun 2014 11:49:14 +0800 From: Sheng Jiang To: Francis Dupont Thread-Topic: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt Thread-Index: AQHPkG3UBUSDTjbqqU20e69v5+PLyZuCtwQw Date: Thu, 26 Jun 2014 03:49:13 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AEBEC88@nkgeml512-mbx.china.huawei.com> References: Your message of Wed, 25 Jun 2014 08:16:37 -0000. <5D36713D8A4E7348A7E10DF7437A4B923AEBC702@nkgeml512-mbx.china.huawei.com> <201406251206.s5PC61Ak084308@givry.fdupont.fr> In-Reply-To: <201406251206.s5PC61Ak084308@givry.fdupont.fr> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/wF8t_QTVSmE6lOpdpRGCtKnmG8Y Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 03:49:25 -0000 Pj4gID5UaGUgc2Vjb25kIHBvaW50IGlzIGFib3V0IChYLjUwOSBwdWJsaWMga2V5KSBjZXJ0aWZp Y2F0ZXMuIFRoZXkgYXJlIHVzZWxlc3MNCj4+ICA+d2l0aG91dCB0aGUgdHJ1c3QgYW5jaG9yLCB0 aGUgd2hvbGUgY2hhaW4sIENSTHMsIGV0Yy4gQW5kIGlmIHdlIHdhbnQNCj4+ICA+dG8gdXNlIHNl bGYtc2lnbmVkIGNlcnRpZmljYXRlcyB0aGV5IGJyaW5nIG5vdGhpbmcgY29tcGFyZWQgdG8gcmF3 DQo+PiAgPnB1YmxpYyBrZXlzLiBBbmQgSSBkb24ndCB0YWxrIGFib3V0IHByb2ZpbGVzIChldmVu IFNlTkQgaGFkIHRvIGJlDQo+PiAgPmNvbXBsZXRlZCBieSBSRkMgNjQ5NCkuIFNvIEkgcmVhbGx5 IHN1Z2dlc3QgdG8gZHJvcCB0aGUgY2VydGlmaWNhdGUNCj4+ICA+b3B0aW9uIGFuZCB0byB1c2Ug dGhlIGtleSBvcHRpb24gdG8gaWRlbnRpZnkgdGhlIHB1YmxpYyBrZXkuDQo+Pg0KPj4gIEFjdHVh bGx5LCBjZXJ0aWZpY2F0ZSB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bCBmb3Igc2VydmVyIHRvIGF1dGhv cml6ZSB0aGUgY2xpZW4NCj4+ICB0LiBJdCBpcyBtdWNoIGxlc3MgdXNlZnVsIG9uIGEgY2xpZW50 LCB3aG8gaGF2ZSBub3QgYmVlbiBhbGxvd2VkIHRvIGNvbm5lY3QNCj4+ICBvbiBsaW5lLiBJbiBz dWNoIGNhc2UsIGNlcnRpZmljYXRlIGNhbiBiZSB1c2VkIHdpdGggTG9GLCB3aGljaCBpcyBlcXVh bCB1c2FnDQo+PiAgZSBhcyBpZGVudGlmeSB0aGUgcHVibGljIGtleS4NCj4NCj49PiBmb3IgdGhl IGZpcnN0IHBvaW50IHNvbWV0aGluZyBsaWtlIHRoZSBVUkkgYW5kIGhhc2ggZnJvbSBJS0V2MiBp cw0KPklNSE8gZmFyIG1vcmUgdXNhYmxlIHRoYW4gdG8gcHV0IHRoZSBjZXJ0aWZpY2F0ZSBpbnNp ZGUgdGhlIG1lc3NhZ2UuDQoNCldlIGRpZCBkaXNjdXNzIFVSSSBmb3IgY2VydGlmaWNhdGUgaW4g REhDIFdHIGJlZm9yZS4gSXQgaXMgdGhlIFdHIGNvbnNlbnN1cyBub3QgdG8gdXNlIFVSSSwgYmVj YXVzZSBpdCBpbnRyb2R1Y2VzIGFkZGl0aW9uYWwgb3ZlcmhlYWQgYW5kIHRpbWUgZGVsYXkgdG8g c2VydmVyIHRvIGRvd25sb2FkIHRoZSBjZXJ0aWZpY2F0ZS4gSXQgaXMgYWxzbyBpbnRyb2R1Y2Ug c29tZSBERE9TIHJpc2tzLg0KDQo+QW5kIEkgZGlzYWdyZWUgYWJvdXQgdGhlIHNlY29uZCBzdGF0 ZW1lbnQ6IHRoZXJlIGlzIG5vIHJlYXNvbiB0bw0KPmdpdmUgdXAgYWJvdXQgdGhlIHNlcnZlciBh dXRob3JpemF0aW9uLiANCj5JdCBpcyBhIGhhcmQgcHJvYmxlbSBidXQNCj5ub3QgYW4gdW50cmFj a2FibGUgb25lIChhcyBTZU5EIHByb3ZlZCkuIEZvciB0aGUgbGFzdCBhIHB1YmxpYyBrZXkNCj5v cHRpb24gaXMgc2ltcGxlciBhbmQgbW9yZSBlZmZpY2llbnQgc28gaXQgaXMgbm90IGFuIGFyZ3Vt ZW50IGZvcg0KPmtlZXBpbmcgdGhlIGNlcnRpZmljYXRlIG9wdGlvbi4NCj4NCj4+ICA+VGhlIGxh c3QgcG9pbnQgaXMgY29tcGF0aWJpbGl0eSB3aXRoIFNlTkQgKFJGQyAzOTcxKS4gVG9kYXkgaW4g cmVkIGFuZA0KPj4gID5ibGFjayAoOi0pIGVudmlyb25tZW50cyBpdCBpcyBwb3NzaWJsZSB0byBz ZWN1cmUgdGhlIE5laWdoYm9yIERpc2NvdmVyeQ0KPj4gID5idXQgbm90IERIQ1AuIEkgcHJvcG9z ZSB0byBmaXggdGhpcyB1c2luZyB0aGUgc2VjdXJlIERIQ1B2NiBmb3INCj4+ICA+dGhlIHByb3Rl Y3Rpb24gb2YgREhDUCBhbmQgdGhlIFNlTkQgc2VjdGlvbiA2IEF1dGhvcml6YXRpb24gRGVsZWdh dGlvbg0KPj4gID5EaXNjb3ZlcnkgZm9yIHRoZSAiY2VydGlmaWNhdGUgcGFydCIuDQo+Pg0KPj4g IENvdWxkIHlvdSBiZSBtb3JlIGNsZWFyIGhvdyB0aGlzIG1heSB3b3JrPyBJIGFtIG5vdCBzdXJl IEkgZnVsbHkNCj51bmRlcnN0YW5kDQo+PiAgeW91ciBwcm9wb3NhbC4gU28gZmFyLCBTZURIQ1B2 NiBoYXMgbm8gY29tcGF0aWJpbGl0eSBpc3N1ZXMgd2l0aCBTZU5ELA0KPmJlY2F1DQo+PiAgc2Ug dGhleSBhcmUgdHdvIHNvbHV0aW9ucyBpbmRlcGVuZGVudCBmcm9tIGVhY2ggb3RoZXIuIFdlIGRv bid0IHdhbnQgdG8NCj5pbnRyDQo+PiAgb2R1Y2UgYW55IGRlcGVuZGVuY3kgYmV0d2VlbiB0aGVt LCB3aGljaCB3b3VsZCBtYWtlIHRoZSBkZXBsb3ltZW50DQo+bXVjaCBtb3JlDQo+PiAgY29tcGxp Y2F0ZWQuDQo+DQo+PT4gSSBkb24ndCB3YW50IHRvIGludHJvZHVjZSBkZXBlbmRlbmN5IGJ1dCB0 byBtYWtlIHRoZW0gdG8gYmUgYWJsZSB0bw0KPndvcmsgbm90IG9ubHkgdG9nZXRoZXIgYnV0IGlu IGNvbXBsZW1lbnQsIGV4YWN0bHkgYXMgREhDUHY2IGFuZCBORCBhcmUNCj4oZXZlbiBpdCB0b29r IGEgdmVyeSBsb25nIHRpbWUgdG8gZmluYWxpemUgYWxsIGRldGFpbHMpLg0KPlRoZSBtaXNzaW5n IHBhcnQgaW4gU2VESENQdjYgaXMgdGhlIGF1dGhvcml6YXRpb24sIGkuZS4sIGFsbCB0aGUgaGln aGVyDQo+b3JkZXIgdGhpbmcgYWJvdXQgY2VydGlmaWNhdGVzLiBUaGlzIGlzIGFscmVhZHkgaGFu ZGxlZCBpbiBTZU5ELCBwZXJoYXBzDQo+bm90IGluIHRoZSBiZXN0IHdheSwgc28gdGhlIGlkZWEg aXMgdG8gc2F5IGZvciBTZURIQ1B2NiArIFNlTkQgd2UgZG9uJ3QNCj5uZWVkIHRvIHJlaW52ZW50 IHRoZSB3aGVlbC4NCj5UaGlzIGNvdWxkIGxlYXZlIHR3byB1c2UgY2FzZXMgZm9yIFNlREhDUHY2 OiBMb0Ygb3Igc3RhdGljYWxseQ0KPnByZS1jb25maWd1cmVkIFNlREhDUHY2IHVzaW5nIHJhdyBw dWJsaWMga2V5cywgYW5kIFNlREhDUHY2ICsgU2VORA0KPmZvciBzdHJvbmdseSBzZWN1cmVkIGVu dmlyb25tZW50cy4gUGVyaGFwcyBub3QgdGhlIHdob2xlIHRoaW5nIHdlIHdhbnQNCj5idXQgZW5v dWdoIHRvICJzZWxsIiBhIGZpcnN0IHZlcnNpb24uDQoNCk1heSB3ZSByZWFjaCBhZ3JlZW1lbnQg b24gdGhlIGJlbG93IHN0YXRlbWVudDoNCg0KMS4gRnJvbSB0aGUgYWJvdmUgZGlzY3Vzc2lvbiwg dGhlIGNlcnRpZmljYXRlIG9wdGlvbiBpcyBhbHJlYWR5IGRlZmluZWQgZm9yIGNsaWVudC10by1z ZXJ2ZXIuIFVzaW5nIHRoZSBjZXJ0aWZpY2F0aW9uIG9wdGlvbiBvbiB0aGUgc2VydmVyLXRvLWNs aWVudCBjYW4gYXJjaGl2ZSB0aGUgc2FtZSBmdW5jdGlvbiBhcyBwdWJsaWMga2V5LCBpbiBMb0Yg bW9kZS4gU28sIGtlZXBpbmcgY2VydGlmaWNhdGUgYXMgYW4gYWx0ZXJuYXRpdmUgd2lsbCBub3Qg aW50cm9kdWNlIGFueSBoYXJtLg0KDQoyLiBUaGUgY2xpZW50IG1heSBnZXQgc3VwcG9ydCBmcm9t IGFub3RoZXIgbWVjaGFuaXNtIHRvIGJlIGFibGUgdG8gdmFsaWRhdGUgdGhlIHNlcnZlciBjZXJ0 aWZpY2F0ZSAodHJhbnNtaXR0ZWQgYnkgdGhlIGNlcnRpZmljYXRlIG9wdGlvbiksIHN1Y2ggYXMg b2J0YWluaW5nIGNlcnRpZmljYXRlIGNoYWluIGZyb20gU0VORC4NCg0KUmVnYXJkcywNCg0KU2hl bmcNCg0KPlJlZ2FyZHMNCj4NCj5GcmFuY2lzLkR1cG9udEBmZHVwb250LmZyDQo= From nobody Thu Jun 26 09:30:45 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04B81B29AE for ; Thu, 26 Jun 2014 09:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaC1_BgSPzAe for ; Thu, 26 Jun 2014 09:30:38 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15771B2EA7 for ; Thu, 26 Jun 2014 09:11:17 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s5QGBBl8086343; Thu, 26 Jun 2014 18:11:11 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201406261611.s5QGBBl8086343@givry.fdupont.fr> From: Francis Dupont To: Sten Carlsen In-reply-to: Your message of Wed, 25 Jun 2014 14:49:58 +0200. <53AAC576.7070609@s-carlsen.dk> Date: Thu, 26 Jun 2014 18:11:11 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/28SmgXvTUaIlLte27Mk98MiQhjQ Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:30:40 -0000 In your previous mail you wrote: > > => to make timestamps more efficient for security you have to allow only > > small drift, so a pre-synchronization procedure should help to solve > > the unsecure/large vs secure/hard-to-implement drift. > To me it seems that a pre-synchronisation procedure is a great help for > intruders? => I can't see why you say that or do you mean timestamps have another role than anti-replay? > Now you can make sure the target is in time sync with the attack just by > synchronising with it first, really opens the window for attacks. => which attacks? messages are signed so a synchronized attacker has no advantages... Regards Francis.Dupont@fdupont.fr From nobody Thu Jun 26 10:00:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FAB1B2C04 for ; Thu, 26 Jun 2014 10:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVWm8uvponIn for ; Thu, 26 Jun 2014 10:00:43 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id CB96C1B2BF9 for ; Thu, 26 Jun 2014 09:48:40 -0700 (PDT) Received: from [10.215.18.70] (0x3e2c8647.mobile.telia.dk [62.44.134.71]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 1BA701A9D6; Thu, 26 Jun 2014 18:48:07 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sten Carlsen X-Mailer: iPhone Mail (11D201) In-Reply-To: <201406261611.s5QGBBl8086343@givry.fdupont.fr> Date: Thu, 26 Jun 2014 18:47:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0285FA77-8314-4909-A69B-60296423D4F8@s-carlsen.dk> References: <201406261611.s5QGBBl8086343@givry.fdupont.fr> To: Francis Dupont Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/-JeeW7H3QcL5z9DUCBh4Y-xpnao Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:00:44 -0000 > On 26 Jun 2014, at 18:11, Francis Dupont wrote= : >=20 > In your previous mail you wrote: >=20 >>> =3D> to make timestamps more efficient for security you have to allow on= ly >>> small drift, so a pre-synchronization procedure should help to solve >>> the unsecure/large vs secure/hard-to-implement drift.=20 >> To me it seems that a pre-synchronisation procedure is a great help for >> intruders? >=20 > =3D> I can't see why you say that or do you mean timestamps have another > role than anti-replay? My point is that giving the attacker the means to synchronise the replay att= ack with the target will give replay attacks a considerable time window in w= hich to play. >=20 >> Now you can make sure the target is in time sync with the attack just by >> synchronising with it first, really opens the window for attacks. >=20 > =3D> which attacks? messages are signed so a synchronized attacker has > no advantages... If signing messages in itself protects against replays, why bother with sync= hronising time? >=20 > Regards >=20 > Francis.Dupont@fdupont.fr From nobody Thu Jun 26 10:04:47 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4BA1B27B9 for ; Thu, 26 Jun 2014 10:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USg_KuoGLEF4 for ; Thu, 26 Jun 2014 10:04:42 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 527E61B2B6B for ; Thu, 26 Jun 2014 09:56:11 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s5QGu1uQ089140; Thu, 26 Jun 2014 18:56:01 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201406261656.s5QGu1uQ089140@givry.fdupont.fr> From: Francis Dupont To: Sheng Jiang In-reply-to: Your message of Thu, 26 Jun 2014 03:49:13 -0000. <5D36713D8A4E7348A7E10DF7437A4B923AEBEC88@nkgeml512-mbx.china.huawei.com> Date: Thu, 26 Jun 2014 18:56:01 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/l-ZVECVH4Cw1yaroWfn8y-oGAu0 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:04:43 -0000 In your previous mail you wrote: > >=> for the first point something like the URI and hash from IKEv2 is > >IMHO far more usable than to put the certificate inside the message. > > We did discuss URI for certificate in DHC WG before. It is the WG consensus > not to use URI, because it introduces additional overhead and time delay to > server to download the certificate. => I don't buy this argument as the certicate alone is useless (i.e., you need the validation path/chain, CRLs, etc). > It is also introduce some DDOS risks. => it is the use of certificates which introduces some DDoS risks... > May we reach agreement on the below statement: > > 1. From the above discussion, the certificate option is already defined for > client-to-server. => but nothing more than the certificate option so IMHO this part of the current proposal is strickly NOT applicable. > So, keeping certificate as an alternative will not introduce any harm. => it is just useless complexity so it introduces harm. > 2. The client may get support from another mechanism to be able to validate > the server certificate (transmitted by the certificate option), such as obta > ining certificate chain from SEND. => this argument is based on the wrong assumption the whole certificate is needed to recognize it. It is fully wrong: an X.509 public key certificate is only a signed public key with attributes. Note you can argue you can get more than one certificate sharing the same public (and private) key. IMHO this is more than bad practice so there is no need to support it (i.e., looking for the first matching certificate is enough). To summary the choice is between dropping the certificate stuff or to fix it with for instance a profile, etc. It could take years to get seDHCPv6 so please keep it simple... Regards Francis.Dupont@fdupont.fr From nobody Thu Jun 26 10:29:40 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5101B2C7A for ; Thu, 26 Jun 2014 10:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnrgpnIxIUbM for ; Thu, 26 Jun 2014 10:29:37 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4602F1B2C49 for ; Thu, 26 Jun 2014 10:28:31 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s5QHSP1A091330; Thu, 26 Jun 2014 19:28:25 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201406261728.s5QHSP1A091330@givry.fdupont.fr> From: Francis Dupont To: Sten Carlsen In-reply-to: Your message of Thu, 26 Jun 2014 18:47:59 +0200. <0285FA77-8314-4909-A69B-60296423D4F8@s-carlsen.dk> Date: Thu, 26 Jun 2014 19:28:25 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/on6DHBQrERThAikwwSo8PrXWNxo Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:29:39 -0000 In your previous mail you wrote: > > => I can't see why you say that or do you mean timestamps have another > > role than anti-replay? > My point is that giving the attacker the means to synchronise the > replay attack with the target will give replay attacks a considerable > time window in which to play. => synchronization allows to offer a smaller window. I have two other arguments: - IMHO it is better to consider clients will be synchronize than to allow a large window and expect attackers to be never synchronized - it is clear timestamps by themselves are not enough, this is why I proposed to add nonces (note transaction IDs already provides 24 bit of unpredictable data but 24 bits are not enough for high speed LANs) > If signing messages in itself protects against replays, why bother > with synchronising time? => signing is for origin and integrity, timestamps and/or nonces are for anti-replay. Note it seems we need more analysis about the usefulness of the anti-replay (I thought about the obvious RELEASE replayed after a long delay but anyway a good security threat analysis is (*again*) hardly needed... argh!) Regards Francis.Dupont@fdupont.fr From nobody Thu Jun 26 10:38:25 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411D21B2C75 for ; Thu, 26 Jun 2014 10:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGg84plIHM3V for ; Thu, 26 Jun 2014 10:38:23 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96AEA1B2B41 for ; Thu, 26 Jun 2014 10:34:13 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id bs8so1491642wib.7 for ; Thu, 26 Jun 2014 10:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=okgp4ssG+/W+fHXTm2GCVQJvELkW7H/8JB+nPql8n1Y=; b=FYBfYPLxPmELx94wrkxGEvC9W1aJVYrD7VoL3sf1AoK8iI4Oc1m0fGdaeTcWCXP90i 0jgk+cvM/P41jN62bqwDLIFSZ0rxSw/QbcR9NaRSyReFRjDL9xRS65a7e5zxtq2pvB3E 9KOBJMON2/pyhxplrSfINVyH+Kh/rDvdgnhWuqY9mb27gbb/eUyISSAQCZf032g2HDcO /+8GCzUxRilWWvNky7UF395gbd5yIrTNvf/YKv0IYXDogBgb4FQmXxdNfhOCVkDKI8hv gVp9dezUvjLCKWODEAno90mK2BYQhJKclGbuzyb2FXaLDNvzwnhJ7rqdgwmxGrn19zeR woRA== MIME-Version: 1.0 X-Received: by 10.194.8.102 with SMTP id q6mr19693702wja.74.1403804050065; Thu, 26 Jun 2014 10:34:10 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.222.7 with HTTP; Thu, 26 Jun 2014 10:34:09 -0700 (PDT) In-Reply-To: <201406261656.s5QGu1uQ089140@givry.fdupont.fr> References: <5D36713D8A4E7348A7E10DF7437A4B923AEBEC88@nkgeml512-mbx.china.huawei.com> <201406261656.s5QGu1uQ089140@givry.fdupont.fr> Date: Thu, 26 Jun 2014 10:34:09 -0700 X-Google-Sender-Auth: QVN1k__Zt-kIPxc4zpv5hWHY_iU Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: Francis Dupont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/I2OWU2Q9Fg9_fw8Nq-fMWA5BA2o Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 17:38:24 -0000 At Thu, 26 Jun 2014 18:56:01 +0200, Francis Dupont wrote: > > We did discuss URI for certificate in DHC WG before. It is the WG consensus > > not to use URI, because it introduces additional overhead and time delay to > > server to download the certificate. > > => I don't buy this argument as the certicate alone is useless (i.e., > you need the validation path/chain, CRLs, etc). > > > It is also introduce some DDOS risks. > > => it is the use of certificates which introduces some DDoS risks... > > > May we reach agreement on the below statement: [...] > > So, keeping certificate as an alternative will not introduce any harm. > > => it is just useless complexity so it introduces harm. [...] > To summary the choice is between dropping the certificate stuff > or to fix it with for instance a profile, etc. It could take years > to get seDHCPv6 so please keep it simple... I tend to agree with Francis. I see we'll need more work to make the use of certificates in the DHCP authentication workable. I previously heard that this work tried to provide what people have been requesting. I wonder whether the request includes the ability of using certificates as a mandatory component. If not, it seems to make more sense to focus on the public key usage and publish it sooner. -- JINMEI, Tatuya From nobody Thu Jun 26 11:36:34 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC721B2CC3 for ; Thu, 26 Jun 2014 11:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfbT4q29_nnV for ; Thu, 26 Jun 2014 11:36:28 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 89BBD1B2FC3 for ; Thu, 26 Jun 2014 11:14:07 -0700 (PDT) Received: from [IPv6:2001:16d8:dd00:81ac:1c73:991a:1fed:b58b] (unknown [IPv6:2001:16d8:dd00:81ac:1c73:991a:1fed:b58b]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 72DFC154C3; Thu, 26 Jun 2014 20:13:35 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Sten Carlsen X-Mailer: iPhone Mail (11D201) In-Reply-To: <201406261728.s5QHSP1A091330@givry.fdupont.fr> Date: Thu, 26 Jun 2014 20:13:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2F80E61F-10A9-4CC1-A0A4-1545E453766A@s-carlsen.dk> References: <201406261728.s5QHSP1A091330@givry.fdupont.fr> To: Francis Dupont Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/n0G5hd68arQsIL680mBpmHbTQKk Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 18:36:32 -0000 > On 26 Jun 2014, at 19:28, Francis Dupont wrote= : >=20 > In your previous mail you wrote: >=20 >>> =3D> I can't see why you say that or do you mean timestamps have another= >>> role than anti-replay? >> My point is that giving the attacker the means to synchronise the >> replay attack with the target will give replay attacks a considerable >> time window in which to play. >=20 > =3D> synchronization allows to offer a smaller window. On the contrary. Synchronisation allows me(the attacker) to change the victi= m's time to suit my replay. > I have two other arguments: > - IMHO it is better to consider clients will be synchronize than > to allow a large window and expect attackers to be never synchronized Attackers will synchronise but to their liking, in effect the attacker will a= lways be synchronised. > - it is clear timestamps by themselves are not enough, this is why > I proposed to add nonces (note transaction IDs already provides > 24 bit of unpredictable data but 24 bits are not enough for high > speed LANs) >=20 >> If signing messages in itself protects against replays, why bother >> with synchronising time? >=20 > =3D> signing is for origin and integrity, timestamps and/or nonces > are for anti-replay. Note it seems we need more analysis about > the usefulness of the anti-replay (I thought about the obvious > RELEASE replayed after a long delay but anyway a good security > threat analysis is (*again*) hardly needed... argh!) >=20 > Regards >=20 > Francis.Dupont@fdupont.fr From nobody Fri Jun 27 04:20:37 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299D51B306F for ; Thu, 26 Jun 2014 21:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtrJ3m3Lv7Mr for ; Thu, 26 Jun 2014 21:32:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B77671B2A7F for ; Thu, 26 Jun 2014 21:32:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CEA0C1801C1; Thu, 26 Jun 2014 21:31:02 -0700 (PDT) To: dhankins@google.com, tomasz.mrugalski@gmail.com, msiodelski@gmail.com, jiangsheng@huawei.com, suresh.krishnan@ericsson.com, brian@innovationslab.net, ted.lemon@nominum.com, volz@cisco.com, tomasz.mrugalski@gmail.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140627043102.CEA0C1801C1@rfc-editor.org> Date: Thu, 26 Jun 2014 21:31:02 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/_r4LBaplm4BXo531AkYwHomU6cM X-Mailman-Approved-At: Fri, 27 Jun 2014 04:20:03 -0700 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] [Editorial Errata Reported] RFC7227 (4028) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 04:32:46 -0000 The following errata report has been submitted for RFC7227, "Guidelines for Creating New DHCPv6 Options". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7227&eid=4028 -------------------------------------- Type: Editorial Reported by: Dan Wing Section: 5.1 Original Text ------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ipv6-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ipv6-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Option with IPv6 Addresses Corrected Text -------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ipv6-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Option with IPv6 Addresses Notes ----- Original text shows two IPv6 addresses are required in an option. However, it should be possible to send just one IPv6 address. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7227 (draft-ietf-dhc-option-guidelines-17) -------------------------------------- Title : Guidelines for Creating New DHCPv6 Options Publication Date : May 2014 Author(s) : D. Hankins, T. Mrugalski, M. Siodelski, S. Jiang, S. Krishnan Category : BEST CURRENT PRACTICE Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From nobody Fri Jun 27 04:20:40 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBC71B2A92; Thu, 26 Jun 2014 21:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PD5Ix09HFrMB; Thu, 26 Jun 2014 21:36:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id E6F3C1B2A7F; Thu, 26 Jun 2014 21:36:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 197761801C1; Thu, 26 Jun 2014 21:34:30 -0700 (PDT) To: dwing@cisco.com, dhankins@google.com, tomasz.mrugalski@gmail.com, msiodelski@gmail.com, jiangsheng@huawei.com, suresh.krishnan@ericsson.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140627043430.197761801C1@rfc-editor.org> Date: Thu, 26 Jun 2014 21:34:30 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/phgIi5xHWwrfWcY3yZf9YaWSKV8 X-Mailman-Approved-At: Fri, 27 Jun 2014 04:20:17 -0700 Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org, ted.lemon@nominum.com, iesg@ietf.org Subject: [dhcwg] [Errata Verified] RFC7227 (4028) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 04:36:13 -0000 The following errata report has been verified for RFC7227, "Guidelines for Creating New DHCPv6 Options". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7227&eid=4028 -------------------------------------- Status: Verified Type: Editorial Reported by: Dan Wing Date Reported: 2014-06-26 Verified by: Ted Lemon (IESG) Section: 5.1 Original Text ------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ipv6-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ipv6-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Option with IPv6 Addresses Corrected Text -------------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-code | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ipv6-address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Option with IPv6 Addresses Notes ----- Original text shows two IPv6 addresses are required in an option. However, it should be possible to send just one IPv6 address. -------------------------------------- RFC7227 (draft-ietf-dhc-option-guidelines-17) -------------------------------------- Title : Guidelines for Creating New DHCPv6 Options Publication Date : May 2014 Author(s) : D. Hankins, T. Mrugalski, M. Siodelski, S. Jiang, S. Krishnan Category : BEST CURRENT PRACTICE Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG From nobody Fri Jun 27 05:25:48 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998B01B2CF5 for ; Fri, 27 Jun 2014 05:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iT0mgZqbStTb for ; Fri, 27 Jun 2014 05:25:44 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DC021B2B44 for ; Fri, 27 Jun 2014 05:25:39 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s5RCPX4a060270; Fri, 27 Jun 2014 14:25:33 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201406271225.s5RCPX4a060270@givry.fdupont.fr> From: Francis Dupont To: Sten Carlsen In-reply-to: Your message of Thu, 26 Jun 2014 20:13:35 +0200. <2F80E61F-10A9-4CC1-A0A4-1545E453766A@s-carlsen.dk> Date: Fri, 27 Jun 2014 14:25:33 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/9uvalLH_xf94WKVeP9349Ml-OKo Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 12:25:46 -0000 In your previous mail you wrote: > > => synchronization allows to offer a smaller window. > On the contrary. Synchronisation allows me(the attacker) to change > the victim's time to suit my replay. => I don't follow you again. What is the victim (client or server)? And BTW can you detail one attack example? Regards Francis.Dupont@fdupont.fr From nobody Fri Jun 27 05:55:46 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A0F1B3180 for ; Fri, 27 Jun 2014 05:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DK=1.009, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5q9FdXpRh4K for ; Fri, 27 Jun 2014 05:55:40 -0700 (PDT) Received: from mail2.s-carlsen.dk (0134100024.0.fullrate.dk [90.185.128.210]) by ietfa.amsl.com (Postfix) with ESMTP id 909FE1B2F4D for ; Fri, 27 Jun 2014 05:55:40 -0700 (PDT) Received: from silver4-wire.s-carlsen.dk (unknown [IPv6:2001:16d8:dd00:81ac:cabc:c8ff:fe91:1152]) by mail2.s-carlsen.dk (Postfix) with ESMTPA id 3CF7219356; Fri, 27 Jun 2014 14:55:08 +0200 (CEST) Message-ID: <53AD69AD.1000500@s-carlsen.dk> Date: Fri, 27 Jun 2014 14:55:09 +0200 From: Sten Carlsen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Francis Dupont References: <201406271225.s5RCPX4a060270@givry.fdupont.fr> In-Reply-To: <201406271225.s5RCPX4a060270@givry.fdupont.fr> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/-bvvW9YC2C72_Wb6H0luU9qUDWU Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 12:55:41 -0000 On 27/06/14 14:25, Francis Dupont wrote: > In your previous mail you wrote: > >> > => synchronization allows to offer a smaller window. >> On the contrary. Synchronisation allows me(the attacker) to change >> the victim's time to suit my replay. > > => I don't follow you again. What is the victim (client or server)? > And BTW can you detail one attack example? Ok, let me be more explicit (or try). The way I understand this is: - In order to make communication more secure, time settings in the two ends need to be "close enough" - To make sure the time settings are synchronised, you want to introduce a synchronisation step at the beginning of the communication, then time settings will be close enough - Now communication can proceed using time as part of the transaction If I want to attack the end that needs to be synced, here is my plan: - Start the synchronisation procedure, but set time to fit the replay attack I have in mind. This could be weeks away from today's time (depending on the synchronising procedure) - After this step, the remote end has a completely different time than what it should be. - Now I should have a much easier task making a replay attack, any reference to the time set will be correct as I have set the clock in the victim to match my attack. This is not a specific attack as I don't have one at hand, what I see is that the fact that I can set the time in my victim to be exactly what I like it to be, must offer me a broader choice of attack options. This is what I don't like about the proposal. I possibly missed something here, please help me understand why it helps communication but does not help attacks to be able to set any "appropriate" time in the victim. I would see this as one more tool in my hand. > > Regards > > Francis.Dupont@fdupont.fr > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" From nobody Fri Jun 27 06:34:58 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78741B2BBE for ; Fri, 27 Jun 2014 06:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjtg7TjbNGTy for ; Fri, 27 Jun 2014 06:34:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1830A1B2B9E for ; Fri, 27 Jun 2014 06:34:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9622; q=dns/txt; s=iport; t=1403876094; x=1405085694; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=7utk10x45tqI/hqnisOeYBs7DucXUT0wWp6CWwvuyak=; b=IapatX+wvh7Wq8BlLsTUwbbfBUr2aO6VlUNlVY+QvekT4ODJN1mrHh7W S5LUfjo9BsWiJKoruadwAPJhIqjqs+ziW3bVVgsMASD7xFXzAPDQ3ybax bqRmiqb6wBCLiY+1XKgIkLG0+EPMqee+oCHGjAG1xSb5IEmW8NUQAPCPO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswHAFhyrVOtJA2G/2dsb2JhbABagw1SUweqNAEBAQEBAQUBbZE9h0ABgQkWdYQDAQEBBAEBATc0CQ4EAgEIEQQBAQsUCQcnCxQJCAIEARIIAYg5CAXDUBeFZIhFJiYSBoMngRYFnB+SL4NCgW9B X-IronPort-AV: E=Sophos;i="5.01,560,1400025600"; d="scan'208";a="336081157" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 27 Jun 2014 13:34:38 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5RDYchO028475 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 13:34:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.131]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 08:34:37 -0500 From: "Bernie Volz (volz)" To: Sheng Jiang , "dhcwg@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dhc-addr-registration-05.txt Thread-Index: AQHPj3NvBf4tyNHnxkyDrQ6e74mlpJt/yBiAgAUbM+A= Date: Fri, 27 Jun 2014 13:34:37 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5DB79F@xmb-rcd-x04.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AEB5A83@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AEB5A83@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.243.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/FwcJOSdeqQGvCwQvWmqx68On95Q Subject: Re: [dhcwg] New Version Notification for draft-ietf-dhc-addr-registration-05.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 13:34:56 -0000 Hi: Some individual (wg co-chair hat off) comments regarding this update: 1. I don't think it is wise for the server to only send a Reply AFTER updat= ing DNS. We don't do this for normal DHCPv6 operations (Solicit/A/R/Reply),= so why do this here. The Reply should be sent by the server when it has 'a= ccepted' the request. Note that the "success" Reply means that the server h= as accepted the request (per what is was requested in the received FQDN opt= ion and is in the reply's FQDN) to update DNS. That DNS is up-to-date is NO= T a consideration for sending the Reply. The main reasons for this are: - It is in keeping with how FQDN has been handled in DHCP servers to date. - It provides a much more predictable timing for the Reply to be returned (= i.e., it could be minutes or even longer for the update to complete if the = DNS service has an interruption). - It avoids tying up additional resources on the server (i.e., holding onto= the request until the reply can be sent). This raises a second issue in that there are NO recommendations for retrans= mission of the request if no reply is received within some interval. You ne= ed to specify the RFC 3315 IRT, MRT, MRC, and MRD values to be used. For example: The client transmits the message according to section 14 of RFC 3315, us= ing the following parameters: IRT ADDR_REG_TIMEOUT MRT 0 MRC ADDR_REG_MAX_RC MRD 0 Where ADDR_REG_TIMEOUT might be 1 second and ADDR_REG_MAX_RC might be 5. (T= hose values were taken from the Release values in RFC 3315). There may be = reasons NOT to limit the number of retransmissions as the client could cont= inue to send the request 'forever', obviously though we'd want a fairly lar= ge backoff time to reduce the load on the network (perhaps 30 or 60 minutes= as the MRT). Though this does raise another question as to WHEN clients should even send= ADDR_REG requests? YIKES - an M and O bit discussion?? Should the document= say anything about this - i.e., this should be used when there is some ind= ication that DHCPv6 services may be available? Or ... as the address regist= ration server may be separate from a 'normal' DHCPv6 server, may be a good = reason to stay away from 'normal' DHCPv6 services? But, I also wonder how r= ealistic that view is (I would expect this to be co-located with DHCPv6 sta= teless support in most cases). Also, the text in section 3 should be updated: An acknowledgeme= nt MAY be sent back to the end host to indicate whether or not the registration operation succeeded. MAY? No - a server that accepts this request MUST send a Reply back. And, the same goes for Figure 1. The "optional acknowledgement" MUST NOT be= optional (whether a client cares to wait for it and retransmit periodicall= y is a separate issue). But the server must always send it. Note also the text in 5.3: Upon receiving a RegistrationDenied error status code, the client MAY resend the message following normal retransmission routines defined in [RFC3315]. Needs these values because that is what is needed for the "normal retransmi= ssions routines defined in [RFC3315]." Though in this case, I would think t= hat: - Different values might be appropriate. - Or, receipt of this status code means not to 'reset' any retransmission t= imes (i.e., the backoff times are not 'reset' so that future retransmission= s continue at the longer and longer intervals, up to the max). If the clien= t started over, it would cause a storm (at the "request/reply" rate) - whic= h would be bad. 2. The text at the end of section 4 about when a client or server must disc= ard the packet should be a bulleted list, more like what is in the Section = 15 of RFC 3315. This is much easier to 'parse'. So: Clients MUST discard any received ADDR-REGISTRATION-REQUEST messages. Servers MUST discard any received ADDR-REGISTRATION-REQUEST messages tha= t meet any of the following conditions: =20 - the message does not include a Client Identifier option. - the message includes a Server Identifier option. - the message does not include at least one IA_NA option. - the message does not include an IAADDR option encapsulated within the I= A_NA option(s). - the message does not include a FQDN option (or includes multiple FQDN o= ptions). - the message includes an Option Request Option. 3. I wonder if in section 3, more should be said about multiple address reg= istration servers? - While multiple address registration servers does potentially increase the= load on DNS, because of how RFC 4704 and 4703 work, this should NOT be an = issue - the servers should work correctly in updating DNS (either adding or= removing the entries). - The broken part with multiple servers is the 'extension' of the registrat= ion. If we have two servers and both receive the initial registration and (= correctly) update DNS, the problem comes when the client extends this but o= ne of the servers does not receive this extension. Then, the server that mi= ssed the extension removes the entry prematurely (i.e., when it expired ori= ginally). The above is more for 'independent' servers, as servers that may communicat= e with each other (perhaps using a failover like protocol) may be able to r= educe (or eliminate) these issues. I don't think we want to go into those d= etails in this document (which you already have - The coordination of multi= ple address registration servers is out of scope). 4. Are there any recommendations we might give for when a client should 're= fresh' its registration? The document just says before it expires. What about suggesting that either the Renewal (50%) or Rebind (85%) times b= e used. I suspect that in this case, using 85% of the "valid-lifetime" woul= d be reasonable to use since this is broadcast. This might just be something like "It is recommended that clients initiate = a refresh at about 85% of the valid-lifetime. Because RAs may periodically = 'reset' the valid-lifetime, clients should set a refresh timer to 85% of th= e valid-lifetime when they complete a registration operation and only updat= e this timer if 85% of any updated valid-lifetime would be sooner than the = timer." 5. Have you confirmed that the I-D.ietf-dhc-sedhcpv6 can indeed be used for= this set of requests? (That actually points out an interesting issue in th= at the sedhcpv6 document mentions nothing Solicit w/Rapid Commit and whethe= r it can or can't be used. And, there's text in section 6.1 of that documen= t that says " If the sender is a DHCPv6 client, in the failure cases, it re= ceives a Reply message with an error status code." ... what about a Solicit= (w/o Rapid Commit) and an Advertise reply.) - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Tuesday, June 24, 2014 2:16 AM To: dhcwg@ietf.org Subject: [dhcwg] FW: New Version Notification for draft-ietf-dhc-addr-regis= tration-05.txt Hi, all, The authors have submitted an update version. We believe all received comme= nts have been addressed. Modifications are summarized as below: - Mandated server's response for error code. - Added recommendation for only one registration server out of multiple DH= CPv6 servers. - Added specification that the registration server should record the bindi= ng information. - Allowed multiple IA_NA. - Clarified that the ADDR-REGISTRATION-REQUEST message is dedicated for cl= ients to initiate an address registration request. So, clients MUST NOT inc= lude any ORO. More reviews and comments are appreciated. Best regards, Sheng >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Tuesday, June 24, 2014 2:13 PM >To: Suresh Krishnan; Rajiv Asati; Gang Chen; Sheng Jiang; Suresh=20 >Krishnan; Sheng Jiang; Gang Chen; Rajiv Asati >Subject: New Version Notification for=20 >draft-ietf-dhc-addr-registration-05.txt > > >A new version of I-D, draft-ietf-dhc-addr-registration-05.txt >has been successfully submitted by Sheng Jiang and posted to the IETF=20 >repository. > >Name: draft-ietf-dhc-addr-registration >Revision: 05 >Title: Registering Self-generated IPv6 Addresses in DNS using DHCPv6 >Document date: 2014-06-23 >Group: dhc >Pages: 8 >URL: >http://www.ietf.org/internet-drafts/draft-ietf-dhc-addr-registration-05 >.txt >Status: >https://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/ >Htmlized: >http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-05 >Diff: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-addr-registration-05 > >Abstract: > In networks that are centrally managed, self-generated addresses > cause some traceability issues due to their decentralized nature. > One of the most important issues in this regard is the inability to > register such addresses in DNS. This document defines a mechanism to > register self-generated and statically configured addresses in DNS > through a DHCPv6 server. > > > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at tools.ietf= .org. > >The IETF Secretariat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Sat Jun 28 01:52:30 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FAB1A0328 for ; Sat, 28 Jun 2014 01:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5dbkTkdpVQr for ; Sat, 28 Jun 2014 01:52:28 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344A71A0327 for ; Sat, 28 Jun 2014 01:52:28 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id s5S8qKFL034672; Sat, 28 Jun 2014 10:52:20 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201406280852.s5S8qKFL034672@givry.fdupont.fr> From: Francis Dupont To: Sten Carlsen In-reply-to: Your message of Fri, 27 Jun 2014 14:55:09 +0200. <53AD69AD.1000500@s-carlsen.dk> Date: Sat, 28 Jun 2014 10:52:20 +0200 Sender: Francis.Dupont@fdupont.fr Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/AB1pZ0lRwtgDVzP-8SAWsZnpxOo Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] more thoughts about draft-ietf-dhc-sedhcpv6-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2014 08:52:29 -0000 In your previous mail you wrote: > The way I understand this is: > > - In order to make communication more secure, time settings in the two > ends need to be "close enough" => yes > - To make sure the time settings are synchronised, you want to introduce > a synchronisation step at the beginning of the communication, then time > settings will be close enough => no, I only propose for nodes without a good real time clock and which believe they could be out of synchro to recover first. > - Now communication can proceed using time as part of the transaction => it was already the case: the trade-off is between secure/small window or reliable/large window, and I only propose a way to choose the first (i.e., more secure) at a minimal cost with the hardware we have today... > If I want to attack the end that needs to be synced, here is my plan: > - Start the synchronisation procedure, but set time to fit the replay > attack I have in mind. This could be weeks away from today's time > (depending on the synchronising procedure) => this is possible only when you have a rogue but trusted server. In this case a replay is not the problem. > - After this step, the remote end has a completely different time than > what it should be. => DHCP is not peer-to-peer but client-server. > I possibly missed something here => DHCP is not a general protocol (and BTW your concern is not in fact about synchronization but timestamps, and seDHCPv6 is based first on signature, not on timestamps, so unsigned messages are simply considered as unsecure and should be dropped if the policy requires secure messages). Regards Francis.Dupont@fdupont.fr From nobody Mon Jun 30 09:33:55 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302381A03BE; Mon, 30 Jun 2014 09:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmQvWY3E40HE; Mon, 30 Jun 2014 09:33:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 268C51A03BB; Mon, 30 Jun 2014 09:33:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> Date: Mon, 30 Jun 2014 09:33:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/htZxJZDrO8rbBArAWS0quqwl7ng Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 16:33:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Issues with multiple stateful DHCPv6 options Authors : Ole Troan Bernie Volz Marcin Siodelski Filename : draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Pages : 20 Date : 2014-06-30 Abstract: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in RFC 7084 has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. This document updates RFC 3315 and RFC 3633. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-dhcpv6-stateful-issues-06 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 nobody Mon Jun 30 09:56:31 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADE51A03C9 for ; Mon, 30 Jun 2014 09:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJNj0m8jc73y for ; Mon, 30 Jun 2014 09:56:24 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D9171A03F8 for ; Mon, 30 Jun 2014 09:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8030; q=dns/txt; s=iport; t=1404147363; x=1405356963; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=BVI5WRukX4FWY0mVJIr0K/RqqPMuf6mCYtKf5U8ZmtI=; b=THlatQ0VPBtKjErqX1sBjcdoHNVamI59A0oDUktvDuJo8f0OqCjCwTDU x7dBOGxwCdj2ebyYdc1p0D4n+3msx+EtwzPniY2tG+388tVxJ8RMuZ6zD QozH/q2RO5TqVE9IiNWBwFz5/5n4RrrkOupw0HFGml5pdjSqzM2kSsrZu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskNAHCWsVOtJA2F/2dsb2JhbABagw1SUwerGgEBAQEBAQUBbgFRkTWHQAGBDhZ1hAMBAQEEAQEBNy0HFwQCAQgRBAEBCxQJBycLFAkIAgQTCAESiCcIBcdwF4VkiFIBAR4PFxIGgyeBFgWcJJI3g0KBdzk X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="57178593" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP; 30 Jun 2014 16:56:00 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s5UGu04u026157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 30 Jun 2014 16:56:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 11:56:00 -0500 From: "Bernie Volz (volz)" To: "dhcwg@ietf.org" Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Thread-Index: AQHPlIEus6CA5H78HkuHLmw+Sv8Eh5uJ3xfA Date: Mon, 30 Jun 2014 16:55:59 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> In-Reply-To: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/DjHba8oPGPrH2eGPVOHOT2ZJN64 Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 16:56:27 -0000 Hi: A new version of this document has been posted. Sorry for the long delay bu= t there were some significant changes to make and thanks to Marcin for join= ing the authors to make some of those changes. The major differences are: 1. Sections 4.1 and 4.2 (Advertise Message and Placement of Status Code) we= re swapped. The reason for this is because we decided to use the Reply form= atting for the status codes in Advertise too. It turns out that there are s= erver implementations that did already use this formatting and there have b= een no reported issues. So, client implementations must be handling this ac= ceptable. This is a better long term solution since it doesn't special case= the IA_NA/IA_TA handling in Advertise. 2. The 4.4 Renew and 4.5 Rebind sections have had major changes and rework = (that to Marcin). 3. The 4.6 Confirm section was changed to remove use of Confirm for IA_PD (= Rebind is mandated). For IA_NA and/or IA_TA only, Confirm can be used. If I= A_PD exists, Rebind should be used (not Confirm). 4. Replaced 4.7. Release Message with a 4.7 Decline Should Not Necessaril= y Trigger a Release (an issue reported by Tim Winters). 5. There are other minor edits (such as referencing RFC 7084 instead of RFC= 6204). There is one outstanding issue that we'd like to get feedback on from folks= (as well as of course the other changes made). We can discuss on the maili= ng list but will also discuss at the Toronto IETF DHC WG Session. This is the issue of which status codes Renew and Rebind should use when a = server is unable to provide "leases" for a binding. Presently the text says= to use NoBinding and part of that reason was that this is consistent with = what is currently written in RFC 3315. But it may be better to use NoAddrsA= vail/NoPrefixAvail instead of NoBinding. Marcin and I debated this some and= here is some data regarding this issue: 1. A Request never returns NoBinding. It uses NoAddrsAvail/NoPrefixAvail. S= o, if we wanted to make Renew (and Rebind) more closely aligned ... 2. Existing servers (that follow 3315) will return NoBinding. Thus, returni= ng this would provide a client no information as to whether the server was = new or not - and whether to initiate a Solicit/... cycle. On the flip side,= existing clients handle NoBinding so that could avoid issues with unexpect= ed status results? 3. We have 4 possible responses for an IA for a Renew/Rebind when no 'resou= rces' are assigned: 3.a. Return NoBinding. 3.b. Return NoAddrsAvail/NoPrefixAvail. 3.c. Return an 'empty' IA (no IAADDR or IAPREFIX options). 3.d. Don't return the IA. (I'm not a fan of this one as it might imply to t= he client that the server doesn't know that IA.) 4. Is there any value in r= eturning additional information to a client for a Rebind? For a Rebind, the= re are two possibilities as to why the server didn't assign addresses/prefi= xes: 4.a. The server has no resources available at the present time. 4.b. The server is not able to assign resources because it is not configure= d to support "rapid commit". So, should we consider whether these should be handled differently? For 4.a= ., if the client retries (i.e., Renew, Solicit) it may get a resource but m= ay not - depends on why it isn't available and whether something has happen= ed to make a resource available. For 4.b, if the client retries (i.e., Rene= w, Solicit) it would likely get the resource. 5. There is one other condition to consider - my original assumption for Re= new was that the server could 'refuse' to service the client if the server = had no record of the client (i.e., no bindings). In this case, returning No= Binding for all of the IA_* would be appropriate - to force the client to S= olicit/... (If we do 'drop' NoBinding from Renew/Rebind, then this status code would o= nly be used for Release/Decline Replies.) My feeling is that for Renew/Rebind: - We should return NoAddrsAvail/NoPrefixAvail when the server cannot provid= e the requested resources but would if it 'could'. - We should reserve NoBinding to trigger the client to go back to Solicit/.= .. or Request. Therefore, this should only be used in conditions where the = server wants (needs) the client to do that. If would be nice if the status codes (or empty or missing IA) had consisten= t meanings for 'all' messages and thus triggered consistent client actions. Putting NoAddrsAvail into the IA carried in the Reply to Renew/Rebind shoul= dn't cause problems in the clients that really follow the current RFC3315 a= s in the section 18.1.8 it clearly specifies what to do with IAs that conta= in NoAddrsAvail in the Reply message and it doesn't differentiate between = the types of messages in response to which the Reply has been received. The= following paragraph: "When the client receives a Reply message in response to a Renew or Rebind message, the client examines each IA independently. For each IA in the original Renew or Rebind message, the client: - sends a Request message if the IA contained a Status Code option with the NoBinding status (and does not send any additional Renew/Rebind messages) - sends a Renew/Rebind if the IA is not in the Reply message - otherwise accepts the information in the IA " may be a source of trouble for clients which implementers ignored the prece= ding paragraph and simply made an assumption that NoAddrsAvail is not retur= ned for Renew/Rebind. On the other hand the client shouldn't fall over just= because it gets the unexpected status code. So in principle it seems to be fine to use NoAddrsAvail/NoPrefixAvail in th= e Reply messages sent as a response to Renew/Rebind. Anyway, give the current draft a read and if there are concerns or question= s (or you have a view on the issue), please send mail to the list ASAP. - Bernie -----Original Message----- From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Monday, June 30, 2014 12:34 PM To: i-d-announce@ietf.org Cc: dhcwg@ietf.org Subject: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Dynamic Host Configuration Working Group = of the IETF. Title : Issues with multiple stateful DHCPv6 options Authors : Ole Troan Bernie Volz Marcin Siodelski Filename : draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Pages : 20 Date : 2014-06-30 Abstract: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in RFC 7084 has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. This document updates RFC 3315 and RFC 3633. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dhc-dhcpv6-stateful-issues-06 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From nobody Mon Jun 30 11:04:33 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F06B1A03D0 for ; Mon, 30 Jun 2014 11:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U_L_m2ZxV7d for ; Mon, 30 Jun 2014 11:04:21 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080111A03E5 for ; Mon, 30 Jun 2014 11:04:18 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so8472097wgh.23 for ; Mon, 30 Jun 2014 11:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=peQOc+Byk+DvvdJo+5pXt6KFrVcw6C7Mmxcn29Gm+Gg=; b=0BQ+Nel6S5hWha4Ubn4nVaplSmbCDy82Moc0OHu4wwpDoO+ZXxY0UJ4SNnNPnJBh2g FrJ6iXEUEaN/FDWBIkZ0QZVH32mfY/Hja5PkrXXqSPNXFDBOkqghzhSdUXTT9lyovFSM mj16BKuVdzbbGyTd+RfWc1TVtmn0o+X85JtEsvNhK1bF3MN4jV5H7wh38XK4LEj+dtkX ChXmWSfmO275xeEywhwHYOb9T5A34oKT8lwjEPVuNgTQ4YehoRdnTwvyt9DhcccVBrVJ NuG2SyAAcLQoFxrwEifBR1J5mJ+A5+XmD/O3C2reXyIRLWzLLGB1plm6bG0M0QAre0pZ PF5Q== MIME-Version: 1.0 X-Received: by 10.194.89.138 with SMTP id bo10mr6391212wjb.22.1404151457472; Mon, 30 Jun 2014 11:04:17 -0700 (PDT) Sender: jinmei.tatuya@gmail.com Received: by 10.194.222.7 with HTTP; Mon, 30 Jun 2014 11:04:17 -0700 (PDT) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> Date: Mon, 30 Jun 2014 11:04:17 -0700 X-Google-Sender-Auth: pTsJihUD47Zqg3-TnHmsXDSKVKk Message-ID: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= To: "Bernie Volz (volz)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/4os387fT50jLJs7fsb3-AI_mrCc Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:04:27 -0000 At Mon, 30 Jun 2014 16:55:59 +0000, "Bernie Volz (volz)" wrote: > A new version of this document has been posted. Sorry for the long > delay but there were some significant changes to make and thanks to > Marcin for joining the authors to make some of those changes. I've just made a quick scan of the 06 version. I'm going to take a closer look at it later, but please let me check one high level thing first, based on my own comments on the previous version: http://www.ietf.org/mail-archive/web/dhcwg/current/msg15284.html Can I assume that this draft tries to provide a generalized specification for all current and possible IA_xx, even if the original motivation was (in my understanding from the previous discussion) to clarify the usage of IA_NA and IA_PA in the same DHCPv6 session? And, if so, does it try to provide a well-defined specification for the usage with IA_TA and other IA_xx's? The overall tone of the new version from a quick read seemed to suggest that the answer is "yes" to both questions, but in some specific cases the draft still seems to focus on /assume specific usage (not just as an example). Also, as for IA_TA, the 4th paragraph of Section 1, especially its second sentence, could read as if IA_TA is an out of scope of this specification: [...] IA_TA also has limited value when DHCPv6 is used for address assignment, as the privacy issues identified for IPv6 stateless address assignment ([RFC4941]) do not apply to DHCPv6 assignments. If the intent is to also cover the usage of IA_TA, I don't see the need for this sentence in the context of this document. I'd like to be sure about the author's intent of these, as that would affect how I should read the draft and possibly make comments on it. -- JINMEI, Tatuya From nobody Mon Jun 30 11:19:43 2014 Return-Path: X-Original-To: dhcwg@ietfa.amsl.com Delivered-To: dhcwg@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05C3B1A040D for ; Mon, 30 Jun 2014 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.852 X-Spam-Level: X-Spam-Status: No, score=-14.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecgTGLUxdIpN for ; Mon, 30 Jun 2014 11:19:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5FF61A03B6 for ; Mon, 30 Jun 2014 11:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5136; q=dns/txt; s=iport; t=1404152379; x=1405361979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+Dl3hiLdsYkVWBS0CYoHvw+SJl+Co49zj1aSiYIQDK0=; b=CSEFYFN5CaeS5xrcgqkNPoBoWA1OXpcI1RoNtSs2IhZ/AKdNEQCCzyCN Hta/WQkh24o3te7Hb3pSYl086OIiF2kAnEJZRpx/nZeCTgwc22/cuW8Su hhbDnGFznolOaB6Jlk68s1lbM1XO9pJvRsGgeJmsQII7/7f7ch4icLXSz 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0HACupsVOtJV2P/2dsb2JhbABagw1SWoJuqCwBAQEBAQEFAW4BmUYBGXkWdYQDAQEBAwEjEUUFBwQCAQgRBAEBAwIGHQMCAgIfERQBCAgCBA4FCAGIJQMJCA2rXZVkDYZSF4ErhDmGfIFPBwEBHhYQCwcGgnE2gRYFmGCPaYYSg0JsgQIJFyI X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="333665956" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jun 2014 18:19:38 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5UIJbx9019822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 18:19:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.176]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 13:19:37 -0500 From: "Bernie Volz (volz)" To: =?utf-8?B?56We5piO6YGU5ZOJ?= Thread-Topic: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt Thread-Index: AQHPlIEus6CA5H78HkuHLmw+Sv8Eh5uJ3xfAgABnIoD//6zhMA== Date: Mon, 30 Jun 2014 18:19:37 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1B5E170B@xmb-rcd-x04.cisco.com> References: <20140630163351.4191.69719.idtracker@ietfa.amsl.com> <489D13FBFA9B3E41812EA89F188F018E1B5E03D1@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.240.62] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/sAHlVS5VkpoGqJPele3HnQmAF24 Cc: "dhcwg@ietf.org" Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-stateful-issues-06.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jun 2014 18:19:41 -0000 VGhlIGNvcmUgZm9jdXMgb2YgdGhpcyB3b3JrIGlzIGdldHRpbmcgSUFfTkEgJiBJQV9QRCB0byB3 b3JrIHdlbGwgdG9nZXRoZXIsIHNpbmNlIHRoYXQgaXMgd2hhdCBpcyB1c2VkIGluIFJGQyA3MDg0 Lg0KDQpCdXQgYmVjYXVzZSB3ZSdyZSBtYWtpbmcgY2hhbmdlcyB0byB0aGUgc3BlY2lmaWNhdGlv bnMgKGkuZS4sIHJldmlzZWQgc2VjdGlvbnMgb2YgMzMxNSwgMzYzMywgYW5kIGV2ZW4gaW4gc29t ZSBjYXNlcyBwcm92aWRpbmcgdGV4dCBmb3IgcG9zc2libGUgdXNlIGluIHRoZSAzMzE1YmlzIHdv cmspLCB3ZSBhcmUgaW5kZWVkIHRyeWluZyB0byBjb3ZlciBhbGwgSUFfKiBvcHRpb25zICh3aGls ZSB3ZSBob3BlIGl0IGluY2x1ZGVzIGZ1dHVyZSBwb3NzaWJsZSBJQV8qIG9wdGlvbnMsIHRoYXQg aXMgbW9yZSBkaWZmaWN1bHQgdG8gYWNoaWV2ZSBhcyB3ZSBkb24ndCBrbm93IHdoYXQgdGhvc2Ug bWlnaHQgYmUpLg0KDQo+Q2FuIEkgYXNzdW1lIHRoYXQgdGhpcyBkcmFmdCB0cmllcyB0byBwcm92 aWRlIGEgZ2VuZXJhbGl6ZWQgc3BlY2lmaWNhdGlvbiBmb3IgYWxsIGN1cnJlbnQgYW5kIHBvc3Np YmxlIElBX3h4DQoNClNvIHllcy4NCg0KTm90ZSBob3dldmVyIHRoYXQgSUFfVEFzIGFyZSBwcm9i YWJseSBub3Qgd2lkZWx5IHVzZWQgLi4uIGFuZCB3ZSBtaWdodCBldmVuIHdhbnQgdG8gZGViYXRl IGZvciBSRkMgMzMxNWJpcyB3aGV0aGVyIHRvIGRlcHJlY2F0ZSB0aGVtLiAzMzE1IHdvcmsgd2Fz IG9jY3VycmluZyB3aGVuIHRoZSBwcml2YWN5IGlzc3VlcyBmb3IgSVB2NiBleHBsb2RlZCBhbmQg c28gdGhlIHRlYW0gdGhlbiB0cmllZCB0byBhY2NvbW1vZGF0ZSB0aGlzIGlzc3VlLiBCdXQgaXQg aXMgaGFyZCB0byBzZWUgaG93IERIQ1B2NiBzZXJ2ZXJzIHdvdWxkIGFzc2lnbiB0aGUgc2FtZSAn aW50ZXJmYWNlLWlkZW50aWZpZXInIHBvcnRpb24gb2YgdGhlIGFkZHJlc3Mgd2hlbiBhIGNsaWVu dCBtb3ZlcyB0byBkaWZmZXJlbnQgc2VydmVycy4gU28sIGlzIElBX1RBIHJlYWxseSB0aGF0IG5l Y2Vzc2FyeT8gU3VyZSwgaWYgeW91IGhhdmUgYSBmaXhlZCBub2RlIHRoYXQgbWlnaHQgY29udGlu dWUgdG8gcmVuZXcgaXRzIElBX05BIGFkZHJlc3MgJ2ZvcmV2ZXInLCBwZXJoYXBzIHRoZXJlIG1h eSBiZSBzb21lIGRlc2lyZSB0byB1c2UgYSBkaWZmZXJlbnQgYWRkcmVzcyBmb3IgYnJvd3Npbmcg b3Igb3RoZXIgYXBwbGljYXRpb25zIGFuZCBpZiBzdGF0ZWxlc3MgaXMgcHJvaGliaXRlZCwgdGhl biBoYXZpbmcgSUFfVEEgbWlnaHQgaGF2ZSBzb21lIHZhbHVlLg0KDQoNCkJvdHRvbSBsaW5lIGlz IHRoYXQgeWVzIHdlIGFyZSB0cnlpbmcgdG8gYWNjb21tb2RhdGUgYWxsIChleGlzdGluZykgSUFf KiB0eXBlcy4gQW5kLCBpbiBnZW5lcmFsIHdlJ3ZlIGFzc3VtZWQgdGhhdCAzMzE1IGhhcyBoYW5k bGVkIElBX05BL0lBX1RBIGNvLWV4aXN0ZW5jZSBzdWZmaWNpZW50bHksIHNvIHRoZSByZXZpc2Vk IHRleHQgZm9jdXNlcyBvbiBpbmNsdWRlZCBJQV9QRCBoYW5kbGluZy4NCg0KSWYgeW91IGZpbmQg YXJlYXMgd2hlcmUgd2UgZ290IHNvbWV0aGluZyB3cm9uZyAob3IgcGVyaGFwcyAzMzE1IGRpZCkg cmVnYXJkaW5nIElBX1RBIChvciBhbnkgSUFfKiksIHBsZWFzZSBkbyBsZXQgdXMga25vdy4NCg0K LSBCZXJuaWUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGppbm1laS50YXR1 eWFAZ21haWwuY29tIFttYWlsdG86amlubWVpLnRhdHV5YUBnbWFpbC5jb21dIE9uIEJlaGFsZiBP ZiA/Pz8/DQpTZW50OiBNb25kYXksIEp1bmUgMzAsIDIwMTQgMjowNCBQTQ0KVG86IEJlcm5pZSBW b2x6ICh2b2x6KQ0KQ2M6IGRoY3dnQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2RoY3dnXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtc3RhdGVmdWwtaXNzdWVzLTA2LnR4dA0KDQpB dCBNb24sIDMwIEp1biAyMDE0IDE2OjU1OjU5ICswMDAwLA0KIkJlcm5pZSBWb2x6ICh2b2x6KSIg PHZvbHpAY2lzY28uY29tPiB3cm90ZToNCg0KPiBBIG5ldyB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1l bnQgaGFzIGJlZW4gcG9zdGVkLiBTb3JyeSBmb3IgdGhlIGxvbmcgDQo+IGRlbGF5IGJ1dCB0aGVy ZSB3ZXJlIHNvbWUgc2lnbmlmaWNhbnQgY2hhbmdlcyB0byBtYWtlIGFuZCB0aGFua3MgdG8gDQo+ IE1hcmNpbiBmb3Igam9pbmluZyB0aGUgYXV0aG9ycyB0byBtYWtlIHNvbWUgb2YgdGhvc2UgY2hh bmdlcy4NCg0KSSd2ZSBqdXN0IG1hZGUgYSBxdWljayBzY2FuIG9mIHRoZSAwNiB2ZXJzaW9uLiAg SSdtIGdvaW5nIHRvIHRha2UgYSBjbG9zZXIgbG9vayBhdCBpdCBsYXRlciwgYnV0IHBsZWFzZSBs ZXQgbWUgY2hlY2sgb25lIGhpZ2ggbGV2ZWwgdGhpbmcgZmlyc3QsIGJhc2VkIG9uIG15IG93biBj b21tZW50cyBvbiB0aGUgcHJldmlvdXMgdmVyc2lvbjoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9kaGN3Zy9jdXJyZW50L21zZzE1Mjg0Lmh0bWwNCg0KQ2FuIEkgYXNzdW1l IHRoYXQgdGhpcyBkcmFmdCB0cmllcyB0byBwcm92aWRlIGEgZ2VuZXJhbGl6ZWQgc3BlY2lmaWNh dGlvbiBmb3IgYWxsIGN1cnJlbnQgYW5kIHBvc3NpYmxlIElBX3h4LCBldmVuIGlmIHRoZSBvcmln aW5hbCBtb3RpdmF0aW9uIHdhcyAoaW4gbXkgdW5kZXJzdGFuZGluZyBmcm9tIHRoZSBwcmV2aW91 cyBkaXNjdXNzaW9uKSB0byBjbGFyaWZ5IHRoZSB1c2FnZSBvZiBJQV9OQSBhbmQgSUFfUEEgaW4g dGhlIHNhbWUgREhDUHY2IHNlc3Npb24/ICBBbmQsIGlmIHNvLCBkb2VzIGl0IHRyeSB0byBwcm92 aWRlIGEgd2VsbC1kZWZpbmVkIHNwZWNpZmljYXRpb24gZm9yIHRoZSB1c2FnZSB3aXRoIElBX1RB IGFuZCBvdGhlciBJQV94eCdzPw0KDQpUaGUgb3ZlcmFsbCB0b25lIG9mIHRoZSBuZXcgdmVyc2lv biBmcm9tIGEgcXVpY2sgcmVhZCBzZWVtZWQgdG8gc3VnZ2VzdCB0aGF0IHRoZSBhbnN3ZXIgaXMg InllcyIgdG8gYm90aCBxdWVzdGlvbnMsIGJ1dCBpbiBzb21lIHNwZWNpZmljIGNhc2VzIHRoZSBk cmFmdCBzdGlsbCBzZWVtcyB0byBmb2N1cyBvbiAvYXNzdW1lIHNwZWNpZmljIHVzYWdlIChub3Qg anVzdCBhcyBhbiBleGFtcGxlKS4gIEFsc28sIGFzIGZvciBJQV9UQSwgdGhlIDR0aCBwYXJhZ3Jh cGggb2YgU2VjdGlvbiAxLCBlc3BlY2lhbGx5IGl0cyBzZWNvbmQgc2VudGVuY2UsIGNvdWxkIHJl YWQgYXMgaWYgSUFfVEEgaXMgYW4gb3V0IG9mIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbjoN Cg0KICAgWy4uLl0gSUFfVEEgYWxzbyBoYXMgbGltaXRlZCB2YWx1ZSB3aGVuIERIQ1B2NiBpcyB1 c2VkIGZvciBhZGRyZXNzDQogICBhc3NpZ25tZW50LCBhcyB0aGUgcHJpdmFjeSBpc3N1ZXMgaWRl bnRpZmllZCBmb3IgSVB2NiBzdGF0ZWxlc3MNCiAgIGFkZHJlc3MgYXNzaWdubWVudCAoW1JGQzQ5 NDFdKSBkbyBub3QgYXBwbHkgdG8gREhDUHY2IGFzc2lnbm1lbnRzLg0KDQpJZiB0aGUgaW50ZW50 IGlzIHRvIGFsc28gY292ZXIgdGhlIHVzYWdlIG9mIElBX1RBLCBJIGRvbid0IHNlZSB0aGUgbmVl ZCBmb3IgdGhpcyBzZW50ZW5jZSBpbiB0aGUgY29udGV4dCBvZiB0aGlzIGRvY3VtZW50Lg0KDQpJ J2QgbGlrZSB0byBiZSBzdXJlIGFib3V0IHRoZSBhdXRob3IncyBpbnRlbnQgb2YgdGhlc2UsIGFz IHRoYXQgd291bGQgYWZmZWN0IGhvdyBJIHNob3VsZCByZWFkIHRoZSBkcmFmdCBhbmQgcG9zc2li bHkgbWFrZSBjb21tZW50cyBvbiBpdC4NCg0KLS0NCkpJTk1FSSwgVGF0dXlhDQo=