From ajs@anvilwalrusden.com Thu Nov 1 07:05:22 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD2021F8CB7 for ; Thu, 1 Nov 2012 07:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.874 X-Spam-Level: X-Spam-Status: No, score=-0.874 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf3Rb+iMmucV for ; Thu, 1 Nov 2012 07:05:22 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 76A2021F8CB1 for ; Thu, 1 Nov 2012 07:05:22 -0700 (PDT) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 78E688A031 for ; Thu, 1 Nov 2012 14:05:12 +0000 (UTC) Date: Thu, 1 Nov 2012 10:05:30 -0400 From: Andrew Sullivan To: dnsext@ietf.org Message-ID: <20121101140530.GC64654@mx1.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnsext] [nomcom-chair@ietf.org: CORRECTION: Help the NomCom] X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 14:05:23 -0000 Dear colleagues, The NomCom is looking for feedback about candidates. Please provide it to them. Best, A ----- Forwarded message from NomCom Chair ----- Date: Thu, 01 Nov 2012 05:17:22 -0700 From: NomCom Chair To: Working Group Chairs Subject: CORRECTION: Help the NomCom List-Id: Working Group Chairs I sent a message several hours ago requesting that you help and make your working group aware that the NomCom is looking for input from the community. This message had a minor error. The NomCom needs to receive community input by November 11, 2012. The full text of the corrected message is below --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11. The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org ----- End forwarded message ----- -- Andrew Sullivan ajs@anvilwalrusden.com From rafiee@hpi.uni-potsdam.de Thu Nov 1 15:05:46 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D576321F94B1 for ; Thu, 1 Nov 2012 15:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxFMstxhOekx for ; Thu, 1 Nov 2012 15:05:45 -0700 (PDT) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 518D621F95A9 for ; Thu, 1 Nov 2012 15:05:45 -0700 (PDT) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 21FA2169E98; Thu, 1 Nov 2012 23:05:42 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Thu, 1 Nov 2012 23:05:41 +0100 From: "Rafiee, Hosnieh" To: "marka@isc.org" , Mohan Parthasarathy Date: Thu, 1 Nov 2012 23:05:36 +0100 Thread-Topic: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2yO8rhBNPcMpAhTe6DYCNxzT7UsAGPkJHw Message-ID: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> <20121024081757.GB17765@miek.nl> <20121024230315.D90D82A3951A@drugs.dv.isc.org> In-Reply-To: <20121024230315.D90D82A3951A@drugs.dv.isc.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: Re: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 22:05:47 -0000 > What do you mean by "its own RRs" ? A/AAAA and PTR records ? I doubt=20 > any DNS server would accept update from any client just because it can=20 > verify the CGA. All I have to do is to generate a CGA (using random=20 > subnet prefix if there is no ingress filtering) , send an update and=20 > keep repeating this forever. >Mark >I can see PTR being updated based on CGA. Named can be configured t= o update PTR if the request comes in over TCP from the matching address. I= t can also be configures to update NS and DNAME records if >the request com= es in over TCP from a address within the matching /48 (and is is trivial to= extend the code to support other nibble boundaries). I forgot to mention this in my last answer. Sorry for late response! In IPv6, the subnet prefix is not random. The random part of the address is= the interface ID, which is the 64 rightmost bits of the IPv6 address gener= ated by CGA (if SEND is being used). Thus filtering will have no effect on = CGA, as the host will not regularly change the router prefix, when it is in= the same network. So there is no need to extend the filtering to support o= ther boundaries. -----Original Message----- From: Mark Andrews [mailto:marka@isc.org]=20 Sent: Thursday, October 25, 2012 1:03 AM To: Mohan Parthasarathy Cc: Rafiee, Hosnieh; dnsext@ietf.org Subject: Re: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-c= ga-tsig-00.txt In message , Mohan Parthasarathy writes: >=20 > What do you mean by "its own RRs" ? A/AAAA and PTR records ? I doubt=20 > any DNS server would accept update from any client just because it can=20 > verify the CGA. All I have to do is to generate a CGA (using random=20 > subnet prefix if there is no ingress filtering) , send an update and=20 > keep repeating this forever. I can see PTR being updated based on CGA. Named can be configured to updat= e PTR if the request comes in over TCP from the matching address. It can a= lso be configures to update NS and DNAME records if the request comes in ov= er TCP from a address within the matching /48 (and is is trivial to extend = the code to support other nibble boundaries). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From zhanghaikuo@cnnic.cn Mon Nov 5 11:15:20 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8FD21F84D8 for ; Mon, 5 Nov 2012 11:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.655 X-Spam-Level: ** X-Spam-Status: No, score=2.655 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVsRozUwRT84 for ; Mon, 5 Nov 2012 11:15:18 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 161C921F8432 for ; Mon, 5 Nov 2012 11:15:13 -0800 (PST) Received: from 74.95.157.54 by mail.cnnic.cn with HTTP; Tue, 06 Nov 2012 03:15:09 +0800 X-WebMAIL-MUA: [74.95.157.54] X-eYou-Client: 74.95.157.54 From: "=?gb2312?B?1cW6o8Cr?=" To: dnsext@ietf.org Date: Tue, 06 Nov 2012 03:15:09 +0800 Message-ID: X-Priority: 3 X-Mailer: eYou MUA Subsystem 4.1.7 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_854960_1352142909_13969.html" Subject: [dnsext] this is a dnssec draft about compromised key X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: =?gb2312?B?1cW6o8Cr?= List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:15:20 -0000 ------=_854960_1352142909_13969.html Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGVsbG8gZXZlcnlvbmUgaGVyZSwNCkkgd3JvdGUgZG93biBhbmQgc3VibWl0dGVkIGEgZHJh ZnQgYWJvdXQgY29tcHJvbWlzZWQga2V5IHJvbGxlciBvdmVyIG1ldGhvZCwgYW5kIGhvcGUg aXQgaXMgdXNlZnVsIHRvIEROU1NFQyANCnByb3Bvc2FsDQouDQpJIGFtIGF0IEF0bGFudGEg Zm9yIHRoZSBJRVRGIDg1IG5vdywgYW5kIEkgYW0gd2lsbGluZyB0byBzaXQgZG93biANCmFu ZCB0YWxrIHdpdGggcGVvcGxlIHdobyBhcmUgaW50ZXJlc3RlZCBpbiBteSBkcmFmdC4NCkkg aG9wZSBwZW9wbGUgY291bGQgcGF5IG1vcmUgYXR0ZW50aW9ucyB0byB0aGUgcHJvYmxlbSBv ZiBjdXJyZW50IGVtZXJnZW5jeSByb2xsLW92ZXIgc29sdXRpb24gZm9yIGNvbXByb21pc2Vk IGtleSwNCmJlY2F1c2UgbWFueSBvdGhlciBwcm90b2NvbHMgZGVwZW5kIG9uIHRoZSBETlNT RUMsIGxpa2UgVExTQSBhbmQgc28gb24uIA0KVGhlIA0KYWJzdHJhY3QNCiBvZiB0aGlzIGRy YWZ0IGlzOg0KICAgRE5TIFNlY3VyaXR5IEV4dGVuc2lvbnMgKEROU1NFQykgaXMgd2lkZWx5 IGRlcGxveWVkIGF0IFRMRCBhbmQgb3RoZXINCiAgIGltcG9ydGFudCBkb21haW4gbmFtZXMg Y3VycmVudGx5LiAgRE5TU0VDIGlzIGFuIGVmZmVjdGl2ZSBtZXRob2QgdG8NCiAgIHByb3Zp ZGUgc2VjdXJpdHkgcHJvdGVjdGlvbiBmb3IgZW5kIHVzZXJzIGluIHRoZSBuZXR3b3JrLiAg RE5TU0VDDQogICBuZWVkcyBhIGxvdCBvZiBvcGVyYXRpb25zIHRvIG1haW50YWluIHRoZSBj aGFpbiBvZiB0cnVzdCwgbGlrZSBETlNLRVkNCiAgIHJvbGxvdmVyIG9wZXJhdGlvbnMgcGVy aW9kaWNhbGx5LiAgQnV0IHRoZSBjaGFpbiBvZiB0cnVzdCBjb3VsZCBiZQ0KICAgYnJva2Vu IGlmIHRoZSBvcGVyYXRvciBvZiBkb21haW4gcmVwbGFjZXMgdGhlIG9sZCBrZXkgaW1tZWRp YXRlbHkgaW4NCiAgIGEgZW1lcmdlbmN5IHJvbGxvdmVyIG9wZXJhdGlvbiB3aGVuIHRoZSBr ZXkgaXMgY29tcHJvbWlzZWQuICBUaGUNCiAgIGJyZWFrIHdpbGwgbWFrZSB0aGUgZG9tYWlu IGFuZCBoaXMgc3ViLWRvbWFpbnMgaW52aXNpYmxlIGluIGEgc2hvcnQNCiAgIHRpbWUgaWYg dGhlIGRhdGEgaW4gdGhlIGNhY2hlIG9mIHJlc29sdmVyIGlzIHJpZ2h0LCBvbiB0aGUgY29u dHJhcnksDQogICB0aGUgZmFrZSBSUiBpbiB0aGUgY2FjaGUgb2YgcmVzb2x2ZXIgbWF5IGJl ICJ2YWxpZCIgaWYgdGhlIHJlc29sdmVyDQogICBpcyB1bmRlciB0aGUgYXR0YWNrIGZyb20g aGFja2Vycy4gIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUNCiAgIGNvbXByb21pc2Vk LWtleSBkaWdlc3Qgc2lnbmF0dXJlIChDS0RTKSByZXNvdXJjZSByZWNvcmQgdG8gbWl0aWdh dGUNCiAgIHRoZSBpbXBhY3Qgb2YgaW52YWxpZGF0aW9uIHdoaWNoIGlzIGR1ZSB0byBlbWVy Z2VuY3kgcm9sbG92ZXIgZnJvbQ0KICAgdGhlIGF1dGhvcml0YXRpdmUgbmFtZSBzZXJ2ZXIu DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhhaWt1by1ja2Rz LTAxLnR4dAo= ------=_854960_1352142909_13969.html Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 aGVsbG8gZXZlcnlvbmUgaGVyZSw8ZGl2Pjxicj48L2Rpdj48ZGl2Pkkgd3JvdGUgZG93biBh bmQmbmJzcDtzdWJtaXR0ZWQmbmJzcDthIGRyYWZ0IGFib3V0IGNvbXByb21pc2VkIGtleSBy b2xsZXIgb3ZlciBtZXRob2QsIGFuZCBob3BlIGl0IGlzIHVzZWZ1bCB0byBETlNTRUMmbmJz cDs8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAi PnByb3Bvc2FsPC9zcGFuPi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgYW0gYXQmbmJz cDtBdGxhbnRhJm5ic3A7Zm9yIHRoZSZuYnNwO0lFVEYgODUgbm93LCBhbmQgSSBhbSB3aWxs aW5nIHRvIHNpdCBkb3duJm5ic3A7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJn YigyNTUsIDI1NSwgMjU1KTsgIj5hbmQgdGFsayB3aXRoIHBlb3BsZSB3aG8gYXJlIGludGVy ZXN0ZWQgaW4gbXkgZHJhZnQuPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tn cm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgIj48YnI+PC9zcGFuPjwvZGl2Pjxk aXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsg Ij5JIGhvcGUgcGVvcGxlIGNvdWxkIHBheSBtb3JlIGF0dGVudGlvbnMgdG8gdGhlIHByb2Js ZW0gb2YgY3VycmVudCBlbWVyZ2VuY3kgcm9sbC1vdmVyIHNvbHV0aW9uIGZvciBjb21wcm9t aXNlZCBrZXksPC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgIj5iZWNhdXNlIG1hbnkgb3RoZXImbmJzcDtwcm90 b2NvbHMgZGVwZW5kIG9uIHRoZSBETlNTRUMsIGxpa2UgVExTQSBhbmQgc28gb24uJm5ic3A7 PC9zcGFuPjwvZGl2PjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1NSwgMjU1KTsgIj48YnI+PC9zcGFuPjwvZGl2PjxkaXY+VGhlJm5ic3A7PHNwYW4g c3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgIj5hYnN0cmFj dDwvc3Bhbj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyAiPiZuYnNwO29mIHRoaXMgZHJhZnQgaXM6PC9zcGFuPjwvZGl2PjxkaXY+PHByZSBz dHlsZT0ibGluZS1oZWlnaHQ6IDEuMmVtOyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0 b206IDBweDsgZm9udC1zaXplOiAxM3B4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAy NTUsIDI1NSk7ICI+ICAgRE5TIFNlY3VyaXR5IEV4dGVuc2lvbnMgKEROU1NFQykgaXMgd2lk ZWx5IGRlcGxveWVkIGF0IFRMRCBhbmQgb3RoZXINCiAgIGltcG9ydGFudCBkb21haW4gbmFt ZXMgY3VycmVudGx5LiAgRE5TU0VDIGlzIGFuIGVmZmVjdGl2ZSBtZXRob2QgdG8NCiAgIHBy b3ZpZGUgc2VjdXJpdHkgcHJvdGVjdGlvbiBmb3IgZW5kIHVzZXJzIGluIHRoZSBuZXR3b3Jr LiAgRE5TU0VDDQogICBuZWVkcyBhIGxvdCBvZiBvcGVyYXRpb25zIHRvIG1haW50YWluIHRo ZSBjaGFpbiBvZiB0cnVzdCwgbGlrZSBETlNLRVkNCiAgIHJvbGxvdmVyIG9wZXJhdGlvbnMg cGVyaW9kaWNhbGx5LiAgQnV0IHRoZSBjaGFpbiBvZiB0cnVzdCBjb3VsZCBiZQ0KICAgYnJv a2VuIGlmIHRoZSBvcGVyYXRvciBvZiBkb21haW4gcmVwbGFjZXMgdGhlIG9sZCBrZXkgaW1t ZWRpYXRlbHkgaW4NCiAgIGEgZW1lcmdlbmN5IHJvbGxvdmVyIG9wZXJhdGlvbiB3aGVuIHRo ZSBrZXkgaXMgY29tcHJvbWlzZWQuICBUaGUNCiAgIGJyZWFrIHdpbGwgbWFrZSB0aGUgZG9t YWluIGFuZCBoaXMgc3ViLWRvbWFpbnMgaW52aXNpYmxlIGluIGEgc2hvcnQNCiAgIHRpbWUg aWYgdGhlIGRhdGEgaW4gdGhlIGNhY2hlIG9mIHJlc29sdmVyIGlzIHJpZ2h0LCBvbiB0aGUg Y29udHJhcnksDQogICB0aGUgZmFrZSBSUiBpbiB0aGUgY2FjaGUgb2YgcmVzb2x2ZXIgbWF5 IGJlICJ2YWxpZCIgaWYgdGhlIHJlc29sdmVyDQogICBpcyB1bmRlciB0aGUgYXR0YWNrIGZy b20gaGFja2Vycy4gIFRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyB0aGUNCiAgIGNvbXByb21p c2VkLWtleSBkaWdlc3Qgc2lnbmF0dXJlIChDS0RTKSByZXNvdXJjZSByZWNvcmQgdG8gbWl0 aWdhdGUNCiAgIHRoZSBpbXBhY3Qgb2YgaW52YWxpZGF0aW9uIHdoaWNoIGlzIGR1ZSB0byBl bWVyZ2VuY3kgcm9sbG92ZXIgZnJvbQ0KICAgdGhlIGF1dGhvcml0YXRpdmUgbmFtZSBzZXJ2 ZXIuPC9wcmU+PHByZSBzdHlsZT0ibGluZS1oZWlnaHQ6IDEuMmVtOyBtYXJnaW4tdG9wOiAw cHg7IG1hcmdpbi1ib3R0b206IDBweDsgZm9udC1zaXplOiAxM3B4OyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7ICI+PGJyPjwvcHJlPjxwcmUgc3R5bGU9ImxpbmUt aGVpZ2h0OiAxLjJlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IGZv bnQtc2l6ZTogMTNweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyAi PjxkaXY+VGhlJm5ic3A7SUVURiZuYnNwO2RhdGF0cmFja2VyJm5ic3A7c3RhdHVzJm5ic3A7 cGFnZSZuYnNwO2ZvciZuYnNwO3RoaXMmbmJzcDtkcmFmdCZuYnNwO2lzOjwvZGl2PjxwcmUg c3R5bGU9IndoaXRlLXNwYWNlOiBwcmUtd3JhcDsgd29yZC13cmFwOiBicmVhay13b3JkOyB3 aWR0aDogMTEyMi4zMDAwNDg4MjgxMjVweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgIj48YSBy ZWw9Im5vZm9sbG93IiBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1oYWlrdW8tY2tkcy0wMS50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWhhaWt1by1ja2RzLTAxLnR4dDwvYT48L3ByZT4NCjwvcHJlPjwv ZGl2Pg== ------=_854960_1352142909_13969.html-- From rafiee@hpi.uni-potsdam.de Mon Nov 5 11:42:38 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8CA21F86DA; Mon, 5 Nov 2012 11:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RK0XVyzF51i; Mon, 5 Nov 2012 11:42:37 -0800 (PST) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id 1D99621F86A0; Mon, 5 Nov 2012 11:42:37 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id 36C00D2CD6; Mon, 5 Nov 2012 20:42:34 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Mon, 5 Nov 2012 20:42:33 +0100 From: "Rafiee, Hosnieh" To: "Suresh Krishnan (suresh.krishnan@ericsson.com)" Date: Mon, 5 Nov 2012 20:42:31 +0100 Thread-Topic: Answer to one of comments Thread-Index: Ac27iUCWILit/ZfgSUWub6+Hwucfww== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D4465B8B8MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "Int-area@ietf.org" , "dnsext@ietf.org" Subject: [dnsext] Answer to one of comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:42:38 -0000 --_000_EA738325B0580041A50A364F5F76B68924D4465B8B8MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Suresh, Would you please update the audience with this answer Question : We can save public key and do not need to use CGA-TSIG Answer : An attacker can also copy that public key to his own packet and th= en update the legitimate host Resource Records on DNS. But CGA provides th= is binding with the IP address thus preventing an attacker from doing that = because the verification will fail. And if we plan to save the public/priva= te keys manually, for each hosts that joins to the network, we return back = to using TSIG with its manual process that this draft is supposed to solve. Question: Just one IP is bound to one host name. What if the host has more = than one IP address? Answer: I will add a flag to CGA-TSIG that shows the number of IP addresses= this host has. For example, if hosta wants to update its RRs related to th= e first IP address, then it sets that flag to 1 but if there is no matching= hostname on the DNS RR, it accepts that. Finally I would like to ask for adoption of this draft in Intarea working g= roup. Thank you Hosnieh --_000_EA738325B0580041A50A364F5F76B68924D4465B8B8MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Suresh,

Would you please update the audience with t= his answer

Question : We can save publi= c key and do not need to use CGA-TSIG

An= swer : An attacker can also copy that public key to his own packet and then= update the legitimate host Resource Records on DNS.  But CGA provides= this binding with the IP address thus preventing an attacker from doing th= at because the verification will fail. And if we plan to save the public/pr= ivate keys manually, for each hosts that joins to the network, we return ba= ck to using TSIG with its manual process that this draft is supposed to sol= ve.

 

Question: Just one IP is bound to one host name. What if the host has= more than one IP address?

Answer: I wil= l add a flag to CGA-TSIG that shows the number of IP addresses this host ha= s. For example, if hosta wants to update its RRs related to the first IP ad= dress, then it sets that flag to 1 but if there is no matching hostname on = the DNS RR, it accepts that.

 =

Finally I would like to ask for adoption of = this draft in Intarea working group.

 

Thank you

Hosnieh

 

=

 

= --_000_EA738325B0580041A50A364F5F76B68924D4465B8B8MXMA1Rhpiuni_-- From rafiee@hpi.uni-potsdam.de Mon Nov 5 16:23:51 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090311F0C54; Mon, 5 Nov 2012 16:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkXhxRDiHXvn; Mon, 5 Nov 2012 16:23:50 -0800 (PST) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD271F0C67; Mon, 5 Nov 2012 16:23:45 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 021C8169E76; Tue, 6 Nov 2012 01:23:40 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Tue, 6 Nov 2012 01:23:39 +0100 From: "Rafiee, Hosnieh" To: "Int-area@ietf.org" , "dnsext@ietf.org" Date: Tue, 6 Nov 2012 01:23:36 +0100 Thread-Topic: Please send me your comments (CGA-TSIG) Thread-Index: Ac27tM/MIixZzFIrQByhjXNeyUtywA== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D4465B8F8MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "Suresh Krishnan \(suresh.krishnan@ericsson.com\)" Subject: [dnsext] Please send me your comments (CGA-TSIG) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 00:23:51 -0000 --_000_EA738325B0580041A50A364F5F76B68924D4465B8F8MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Would you please send me your comments on our draft (presentation today) to= my email address, so that I can review them and provide you with answers. Thank you, Hosnieh --_000_EA738325B0580041A50A364F5F76B68924D4465B8F8MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

<= span style=3D'font-size:10.0pt;font-family:"Times New Roman","serif"'>Would= you please send me your comments on our draft (presentation today) to my e= mail address, so that I can review them and provide you with answers.<= /o:p>

 

Hosnieh

= --_000_EA738325B0580041A50A364F5F76B68924D4465B8F8MXMA1Rhpiuni_-- From rafiee@hpi.uni-potsdam.de Wed Nov 7 07:28:11 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5872921F8BF1; Wed, 7 Nov 2012 07:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eH-OjkioA21j; Wed, 7 Nov 2012 07:28:09 -0800 (PST) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 7461021F8BF0; Wed, 7 Nov 2012 07:28:07 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id E5256169E9B; Wed, 7 Nov 2012 16:28:05 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Wed, 7 Nov 2012 16:28:05 +0100 From: "Rafiee, Hosnieh" To: "Suresh Krishnan (suresh.krishnan@ericsson.com)" , "julien.ietf@gmail.com" Date: Wed, 7 Nov 2012 16:28:02 +0100 Thread-Topic: (CGA-TSIG) answers to some of the comments Thread-Index: Ac285dnqWsyLqCHNR5+px/yGKKx0JQ== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D4465C768MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "Int-area@ietf.org" , "dnsext@ietf.org" , "martin@v.loewis.de" Subject: [dnsext] (CGA-TSIG) answers to some of the comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:28:11 -0000 --_000_EA738325B0580041A50A364F5F76B68924D4465C768MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to Julian, Suresh and others for all their comments on my presentati= on. Following are the answers to the questions raised and, hopefully, this = will clarify the main purpose of this draft: - A comment was made that DHCP can update the clients' DNS records on behal= f of the clients so they see any no reason for this draft as DHCPv6 can upd= ate the DNS records for the clients on behalf of them. Here we are talking about another IPv6 addressing mechanism, i.e., Neighbor= Discovery Protocol (RFC 4861) and not DHCPv6. NDP is a new addressing mechanism included in the IPv6 suite that functions= like ARP, discovering other neighbor nodes, ICMP, and address configuratio= n automatically. By default, all operating systems support this functionali= ty and, for windows, it is the default method of addressing. - Why do some administrators prefer to use NDP instead of DHCPv6? With NDP no DHCP server configuration is required. - Usage of NDP protocol All kinds of networks like campus, companies whether they are public and pr= ivate - How can a client or a server in IPv6 networks set its IP address using ND= P When you connect your computer to an IPv6 network, your computer generates = its IP address automatically and then processes duplicate address detection= by using 5 types of ICMPv6 messages. Your computer also sets its global ad= dress by using the router advertisement. The administrator just needs to en= able NDP on his router and configure it to advertise his available prefixes= . It is a great way to manage the network. - The problem with NDP WAS (solved now) Before, it did not support the DNS option and it took the DNS information f= rom the DHCP server, BUT NOW, according to a new extension to NDP, in RFC 6= 106, the router advertisement contains the DNS information also so there is= no need for DHCP server configuration. What is the problem now in this local network - what gap CGA-TSIG fills Briefly: It provides local security in IPv6 networks without the need for extra conf= iguration as it uses the current security parameters and mechanism availabl= e on this network, i.e., SEND. When node addresses change over time in IPv= 6 networks for privacy reasons, CGA-TSIG provides the necessary security in= IPv6 networks for the DNS authentication process. This solution works very= well in local networks, but also is applicable in global networks. - Local security is an important issue: In IPv6 networks that use NDP, ther= e is no central server available to perform the updates to DNS records on b= ehalf of the client. As local security is important, as well as global secu= rity, CGA-TSIG provides a solution for the automation of this process and a= llows for client authentication with DNS servers as well as the ability to = update their own records. The question that might arise here is, why local security is important?: The answer here is the same as that provided for the use of SEcure Neighbor= Discovery in IPv6 networks. Many attacks are internal and not via the Inte= rnet. When, because of flaws or viruses or..., a host in a network is infec= ted that gives the attacker control of that host the role of local security= is highlighted. In this case the attacker is inside your network and using= the legitimate nodes inside your network for their malicious purposes. The= refore, if you just think about global security, you have just partly secur= ed your network! If we also consider the case where the host's generates their IP address an= d keep it as long as it is connected to the same network. When this legitim= ate node, for the first time, join to a network, if TSIG or other security = mechanisms are used, the administrator needs to generate this shared secret= so that it is only shared between this host and the DNS server. Thus CGA-T= SIG reduces this task, while at the same time, provides the security necess= ary for DNS servers and clients. - Privacy is the second or another important issue: In Europe, privacy is a= very important issue. An example of that is in Germany that the ISPs are f= orced to change their range of IP addresses frequently. In this case, for e= very change, the administrators of the sub-networks, using these ISPs, need= to reconfigure their clients and servers to again use the security mechani= sm for authentication purposes. CGA-TSIG is the solution. It can provide th= is authentication without the need for more configuration - Global security: the same approach is applicable for authentication purpo= ses among the DNS servers on the Internet if they are under the privacy rul= es that force them to change their ISP's prefix, as was explained in my fir= st point Finally : DNS serves or clients only need use the cached CGA data and do no= t need to regenerate CGA! This is an important point because only a few cha= nges need be made to the current implementation of DNS server. I will provide you with the list of more attacks later. Some of the attack= s that CGA-TSIG can prevent are found in Security consideration section at = the following link: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-00#section-4 I welcome all questions and comments that can help to clear up the purpose = of this draft. Thank you all for your help. It is greatly appreciated. Thank you again, Hosnieh --_000_EA738325B0580041A50A364F5F76B68924D4465C768MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to Julian, Suresh and others for all = their comments on my presentation. Following are the answers to the questio= ns raised and, hopefully, this will  clarify the main purpose of this = draft:

- A comment was made that DHCP can update the cl= ients' DNS records on behalf of the clients so they see any no reason for t= his draft as DHCPv6 can update the DNS records for the clients on behalf of= them.

Here we are talking about another IPv6 addres= sing mechanism, i.e., Neighbor Discovery Protocol (RFC 4861) and not DHCPv6= .

NDP is a new addressing mechanism included in the IPv6 suit= e that functions like ARP, discovering other neighbor nodes, ICMP, and addr= ess configuration automatically. By default, all operating systems support = this functionality and, for windows, it is the default method of addressing= .

- Why do some administrators prefer to use NDP instea= d of DHCPv6?

With NDP no DHCP server configuration is= required.

- Usage of NDP protocol

All kinds of networks like campus, companies whether they are public and= private

- How can a client or a server in IPv6 network= s set its IP address using NDP

When you connect you= r computer to an IPv6 network, your computer generates its IP address autom= atically and then processes duplicate address detection by using 5 types of= ICMPv6 messages. Your computer also sets its global address by using the r= outer advertisement. The administrator just needs to enable NDP on his rout= er and configure it to advertise his available prefixes. It is a great way = to manage the network.

- The problem with NDP WAS (sol= ved now)

Before, it did not support the DNS option an= d it took the DNS information from the DHCP server, BUT NOW, according to a= new extension to NDP, in RFC 6106, the router advertisement contains the D= NS information also so there is no need for DHCP server configuration.=

What is the problem now in this local network – what gap= CGA-TSIG fills

Briefly:

It provides= local security in IPv6 networks without the need for extra configuration a= s it uses the current security parameters and mechanism available on this n= etwork, i.e., SEND.  When node addresses change over time in IPv6 netw= orks for privacy reasons, CGA-TSIG provides the necessary security in IPv6 = networks for the DNS authentication process. This solution works very well = in local networks, but also is applicable in global networks.<= /span>

- Local security is an important issue: In IPv6 networks that use= NDP, there is no central server available to perform the updates to DNS re= cords on behalf of the client. As local security is important, as well as g= lobal security, CGA-TSIG provides a solution for the automation of this pro= cess and allows for client authentication with DNS servers as well as the a= bility to update their own records.

The question that might = arise here is, why local security is important?:

The answer h= ere is the same as that provided for the use of SEcure Neighbor Discovery i= n IPv6 networks. Many attacks are internal and not via the Internet. When, = because of flaws or viruses or…, a host in a network is infected that= gives the attacker control of that host the role of local security is high= lighted. In this case the attacker is inside your network and using the leg= itimate nodes inside your network for their malicious purposes. Therefore, = if you just think about global security, you have just partly secured your = network!

If we also consider the case where the host's gener= ates their IP address and keep it as long as it is connected to the same ne= twork. When this legitimate node, for the first time, join to a network, if= TSIG or other security mechanisms are used, the administrator needs to gen= erate this shared secret so that it is only shared between this host and th= e DNS server. Thus CGA-TSIG reduces this task, while at the same time, prov= ides the security necessary for DNS servers and clients.<= /p>

- Privacy is the second or another important issue: In Europe, privacy i= s a very important issue. An example of that is in Germany that the ISPs ar= e forced to change their range of IP addresses frequently. In this case, fo= r every change, the administrators of the sub-networks, using these ISPs, n= eed to reconfigure their clients and servers to again use the security mech= anism for authentication purposes. CGA-TSIG is the solution. It can provide= this authentication without the need for more configuration

= - Global security: the same approach is applicable for authenticatio= n purposes among the DNS servers on the Internet if they are under the priv= acy rules that force them to change their ISP's prefix, as was explained in= my first point

Finally : DNS serves or clients only nee= d use the cached CGA data and do not need to regenerate CGA! This is an imp= ortant point because only a few changes need be made  to the current i= mplementation of DNS server.

I will provide you with the list= of more attacks later.  Some of the attacks that CGA-TSIG can prevent= are found in Security consideration section at the following link:

http://tools.iet= f.org/html/draft-rafiee-intarea-cga-tsig-00#section-4

I welcome all questions and comments = that can help to clear up the purpose of this draft. Thank you all for your= help. It is greatly appreciated.

Thank you again,

Hosnieh

 =

 

<= /div>= --_000_EA738325B0580041A50A364F5F76B68924D4465C768MXMA1Rhpiuni_-- From rafiee@hpi.uni-potsdam.de Thu Nov 8 06:35:50 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B4421F8A78; Thu, 8 Nov 2012 06:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DGO+lzZAVdt; Thu, 8 Nov 2012 06:35:45 -0800 (PST) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 5295821F85E2; Thu, 8 Nov 2012 06:35:44 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 7AF44169E9A; Thu, 8 Nov 2012 15:35:43 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Thu, 8 Nov 2012 15:35:43 +0100 From: "Rafiee, Hosnieh" To: "dnsext@ietf.org" Date: Thu, 8 Nov 2012 15:35:38 +0100 Thread-Topic: (CGA-TSIG) answers to some of the comments Thread-Index: Ac29vlJpDwbxbx0jQ3OwHMTGE8GlsA== Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D4465CF88MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "dane@ietf.org" Subject: Re: [dnsext] (CGA-TSIG) answers to some of the comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:35:50 -0000 --_000_EA738325B0580041A50A364F5F76B68924D4465CF88MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, 1) Having the DHCP server do dynamic update is not necessarily just for add= resses allocated by DHCP. See http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is= a DHC WG draft. Thanks a lot for your answer. Please check the consideration section of the= draft you referred to. The stated approach is prone to attacks as it is so= lely about an extra management efforts and not security approaches. To prev= ent the attacks it also stated using SEND. Now the question is, when you want to use SEND to secure your local network= , my approach is also applicable and better fits than TSIG itself as you do= not need to generate public private keys, CGA and you use the same value a= vailable there. DHCPv6 is only useful when you would like to have more management and admin= istration control on your network. But, if you only want to know who used w= hich address, you do not need to go to extra configuration , you need just = a passive monitoring system in the network to sniff all ICMPv6 unsolicited = Neighbor advertisement packets and delete them from the monitoring database= if receive no more NA messages from that node. (frequently nodes update th= eir cache and send NA) 2- Is not true. DNS information is not the only information obtained thro= ugh DHCP, it's a general purpose mechanism through which many things are, and can be, obtained. It is a bad idea to = try to pollute RAs with such information (for one, you're limited to the MTU in RAs). See RFC 5505 section 2.3 for = some more discussion. DNS information is just an information missing in NDP. For addressing not m= ore option is required for a node. I am not quite understand and convinced = that why every time you change the talk to DHCPv6. I am talking about the n= etworks where SEND is used and not DHCPv6. I do not have any discussion abo= ut whether or not the DNS options in RAs is the best. 3- RFC 6434 section 6 even states "Hosts will need to decide which mechanism (or whether both) should be implemented." The fact that we actually have two mechanisms is a bad thing. This is why based on the network requirements, administrator can choose whi= ch one to use. 3) The main feedback some of us provided is that the proposal would be far = more widely applicable and useful if it just passed a public key and used the le= ap of faith model like SSH, rather than narrowing the use case significantly and depend= ing on implementation of CGA, which isn't really implemented/deployed in practice = today. It is not true. Please check this website http://en.wikipedia.org/wiki/Secu= re_Neighbor_Discovery_Protocol . And about using SSH, It might be a good solution to this problem (but so ge= neral) that if you like we can work on that on a separate draft together. The CGA-TSIG focused on a solution to this problem in IPv6 network when usi= ng SEND in local security. I am not agree with you in this sentence " it is= far applicable ", because when for the local security you use SEND you can= easily use this approach without any configuration for your clients side. Thank you, Hosnieh P.S. I also included DANE WG. From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Wednesday, November 07, 2012 8:40 PM To: Rafiee, Hosnieh; Suresh Krishnan (suresh.krishnan@ericsson.com); julien.ietf@gmail.com Cc: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de Subject: RE: (CGA-TSIG) answers to some of the comments Quick response... 1) Having the DHCP server do dynamic update is not necessarily just for add= resses allocated by DHCP. See http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is= a DHC WG draft. 2) "RFC 6106, the router advertisement contains the DNS information also so= there is no need for DHCP server configuration" Is not true. DNS information is not the only information obtained through= DHCP, it's a general purpose mechanism through which many things are, and can be, obtained. It is a bad idea to = try to pollute RAs with such information (for one, you're limited to the MTU in RAs). See RFC 5505 section 2.3 for = some more discussion. RFC 6434 section 6 even states "Hosts will need to decide which mechanism (or whether both) should be implemented." The fact that we actually have two mechanisms is a bad thing. 3) The main feedback some of us provided is that the proposal would be far = more widely applicable and useful if it just passed a public key and used the le= ap of faith model like SSH, rather than narrowing the use case significantly and depend= ing on implementation of CGA, which isn't really implemented/deployed in practice = today. -Dave From: int-area-bounces@ietf.org [mailto:i= nt-area-bounces@ietf.org] On Behalf Of Rafiee, Hosnieh Sent: Wednesday, November 7, 2012 10:28 AM To: Suresh Krishnan (suresh.krishnan@ericsson.com); julien.ietf@gmail.com Cc: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de Subject: [Int-area] (CGA-TSIG) answers to some of the comments Thanks to Julian, Suresh and others for all their comments on my presentati= on. Following are the answers to the questions raised and, hopefully, this = will clarify the main purpose of this draft: - A comment was made that DHCP can update the clients' DNS records on behal= f of the clients so they see any no reason for this draft as DHCPv6 can upd= ate the DNS records for the clients on behalf of them. Here we are talking about another IPv6 addressing mechanism, i.e., Neighbor= Discovery Protocol (RFC 4861) and not DHCPv6. NDP is a new addressing mechanism included in the IPv6 suite that functions= like ARP, discovering other neighbor nodes, ICMP, and address configuratio= n automatically. By default, all operating systems support this functionali= ty and, for windows, it is the default method of addressing. - Why do some administrators prefer to use NDP instead of DHCPv6? With NDP no DHCP server configuration is required. - Usage of NDP protocol All kinds of networks like campus, companies whether they are public and pr= ivate - How can a client or a server in IPv6 networks set its IP address using ND= P When you connect your computer to an IPv6 network, your computer generates = its IP address automatically and then processes duplicate address detection= by using 5 types of ICMPv6 messages. Your computer also sets its global ad= dress by using the router advertisement. The administrator just needs to en= able NDP on his router and configure it to advertise his available prefixes= . It is a great way to manage the network. - The problem with NDP WAS (solved now) Before, it did not support the DNS option and it took the DNS information f= rom the DHCP server, BUT NOW, according to a new extension to NDP, in RFC 6= 106, the router advertisement contains the DNS information also so there is= no need for DHCP server configuration. What is the problem now in this local network - what gap CGA-TSIG fills Briefly: It provides local security in IPv6 networks without the need for extra conf= iguration as it uses the current security parameters and mechanism availabl= e on this network, i.e., SEND. When node addresses change over time in IPv= 6 networks for privacy reasons, CGA-TSIG provides the necessary security in= IPv6 networks for the DNS authentication process. This solution works very= well in local networks, but also is applicable in global networks. - Local security is an important issue: In IPv6 networks that use NDP, ther= e is no central server available to perform the updates to DNS records on b= ehalf of the client. As local security is important, as well as global secu= rity, CGA-TSIG provides a solution for the automation of this process and a= llows for client authentication with DNS servers as well as the ability to = update their own records. The question that might arise here is, why local security is important?: The answer here is the same as that provided for the use of SEcure Neighbor= Discovery in IPv6 networks. Many attacks are internal and not via the Inte= rnet. When, because of flaws or viruses or..., a host in a network is infec= ted that gives the attacker control of that host the role of local security= is highlighted. In this case the attacker is inside your network and using= the legitimate nodes inside your network for their malicious purposes. The= refore, if you just think about global security, you have just partly secur= ed your network! If we also consider the case where the host's generates their IP address an= d keep it as long as it is connected to the same network. When this legitim= ate node, for the first time, join to a network, if TSIG or other security = mechanisms are used, the administrator needs to generate this shared secret= so that it is only shared between this host and the DNS server. Thus CGA-T= SIG reduces this task, while at the same time, provides the security necess= ary for DNS servers and clients. - Privacy is the second or another important issue: In Europe, privacy is a= very important issue. An example of that is in Germany that the ISPs are f= orced to change their range of IP addresses frequently. In this case, for e= very change, the administrators of the sub-networks, using these ISPs, need= to reconfigure their clients and servers to again use the security mechani= sm for authentication purposes. CGA-TSIG is the solution. It can provide th= is authentication without the need for more configuration - Global security: the same approach is applicable for authentication purpo= ses among the DNS servers on the Internet if they are under the privacy rul= es that force them to change their ISP's prefix, as was explained in my fir= st point Finally : DNS serves or clients only need use the cached CGA data and do no= t need to regenerate CGA! This is an important point because only a few cha= nges need be made to the current implementation of DNS server. I will provide you with the list of more attacks later. Some of the attack= s that CGA-TSIG can prevent are found in Security consideration section at = the following link: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-00#section-4 I welcome all questions and comments that can help to clear up the purpose = of this draft. Thank you all for your help. It is greatly appreciated. Thank you again, Hosnieh --_000_EA738325B0580041A50A364F5F76B68924D4465CF88MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dave,

1) Having the DHCP server do dynamic update is not ne= cessarily just for addresses allocated by DHCP.
See http://tools.ietf.or= g/html/draft-ietf-dhc-addr-registration-01 which is a DHC WG draft.

Thanks a lot for your answer. Please= check the consideration section of the draft you referred to. The stated a= pproach is prone to attacks as it is solely about an extra management effor= ts and not security approaches. To prevent the attacks it also stated using= SEND.

Now the question is, when= you want to use SEND to secure your local network, my approach is also app= licable and better fits than TSIG itself as you do not need to generate pub= lic private keys, CGA and you use the same value available there.

DHCPv6 is only useful when you would like to have= more management and administration control on your network. But, if you on= ly want to know who used which address, you do not need to go to extra conf= iguration , you need just a passive monitoring system in the network to sni= ff all ICMPv6 unsolicited Neighbor advertisement packets and delete them fr= om the monitoring database if receive no more NA messages from that node. (= frequently nodes update their cache and send NA)

2- Is not true.   DNS information = is not the only information obtained through DHCP, it’s a general pur= pose mechanism
through which many things are, and can be, obtained. = ;  It is a bad idea to try to pollute RAs with such information
(fo= r one, you’re limited to the MTU in RAs).  See RFC 5505 section = 2.3 for some more discussion.

DNS information is just an information missing in NDP. For addressing = not more option is required for a node. I am not quite understand and convi= nced that why every time you change the talk to DHCPv6. I am talking about = the networks where SEND is used and not DHCPv6. I do not have any discussio= n about whether or not the DNS options in RAs is the best.

3- RFC 6434 section 6 eve=
n states
“Hosts will need to decide which mechanism (or whether both) =
should be

implemented.”
The fact that we actually have tw= o mechanisms is a bad thing.

This is why based on the network requirements, administrator ca= n choose which one to use.

3) The main feedback some of us provided = is that the proposal would be far more
widely applicable and useful if i= t just passed a public key and used the leap of faith
model like SSH, ra= ther than narrowing the use case significantly and depending on
implemen= tation of CGA, which isn’t really implemented/deployed in practice to= day.

It is not = true. Please check this website http://en.wikipedia.org/wiki/Secure_Neighb= or_Discovery_Protocol .

And about using SSH, It might be a good solution to this prob= lem (but so general) that if you like we can work on that on a separate dra= ft together.

Th= e CGA-TSIG focused on a solution to this problem in IPv6 network when using= SEND in local security. I am not agree with you in this sentence “ i= t is far applicable “, because when for the local security you use SE= ND you can easily use this approach without any configuration for your clie= nts side.

Thank you,=

Hosnieh

=

P.S. I also included DANE WG.

 

 

 

=

 =

From: Dave Thaler [mailto:dthaler@microsoft.com]
Sent: Wednesda= y, November 07, 2012 8:40 PM
To: Rafiee, Hosnieh; Suresh Krishnan= (suresh.krishnan@ericsson.= com); julien.ietf@gmail.com
Cc: Int-area@ietf.org;= dnsext@ietf.org; martin@v.loewis.de
Subject: RE: (CGA-TSIG= ) answers to some of the comments

 

Quick response…

<= span style=3D'color:#1F497D'>1) Having the DHCP server do dynamic update is= not necessarily just for addresses allocated by DHCP.
See http:/= /tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is a DHC WG draft.

2) “RFC 6106, th= e router advertisement contains the DNS information also so there is no nee= d for DHCP server configuration”

Is not true.   DNS information is not the only info= rmation obtained through DHCP, it’s a general purpose mechanism
th= rough which many things are, and can be, obtained.   It is a bad = idea to try to pollute RAs with such information
(for one, you’re = limited to the MTU in RAs).  See RFC 5505 section 2.3 for some more di= scussion.

RFC 6434 sect=
ion 6 even states
“=
Hosts will need to decide which mechanism (or whether both) shoul=
d be

implemente= d.”
The fact that we actually have two mechanisms is a bad thing.<= o:p>

3) The main feedb= ack some of us provided is that the proposal would be far more
widely ap= plicable and useful if it just passed a public key and used the leap of fai= th
model like SSH, rather than narrowing the use case significantly and = depending on
implementation of CGA, which isn’t really implemented= /deployed in practice today.

-Dave

= From: int-area-bounces@= ietf.org [mailto:int-area-= bounces@ietf.org] On Behalf Of Rafiee, Hosnieh
Sent: W= ednesday, November 7, 2012 10:28 AM
To: Suresh Krishnan (suresh.krishnan@ericsson.com);= julien.ietf@gmail.com
C= c: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de
Subject: [Int-area] (CGA-TSIG)= answers to some of the comments

 

Thanks to Julian, Suresh and others for all their commen= ts on my presentation. Following are the answers to the questions raised an= d, hopefully, this will  clarify the main purpose of this draft:<= /o:p>

- A comment was made that DHCP can update the clients' DNS r= ecords on behalf of the clients so they see any no reason for this draft as= DHCPv6 can update the DNS records for the clients on behalf of them. =

Here we are talking about another IPv6 addressing mechani= sm, i.e., Neighbor Discovery Protocol (RFC 4861) and not DHCPv6.=

NDP is a new addressing mechanism included in the IPv6 suite that funct= ions like ARP, discovering other neighbor nodes, ICMP, and address configur= ation automatically. By default, all operating systems support this functio= nality and, for windows, it is the default method of addressing.=

- Why do some administrators prefer to use NDP instead of DHCPv6?=

With NDP no DHCP server configuration is required. <= o:p>

- Usage of NDP protocol

= All kinds= of networks like campus, companies whether they are public and private

- How can a client or a server in IPv6 networks set its IP= address using NDP

When you connect your computer to= an IPv6 network, your computer generates its IP address automatically and = then processes duplicate address detection by using 5 types of ICMPv6 messa= ges. Your computer also sets its global address by using the router adverti= sement. The administrator just needs to enable NDP on his router and config= ure it to advertise his available prefixes. It is a great way to manage the= network.

- The problem with NDP WAS (solved now)=

Before, it did not support the DNS option and it took the= DNS information from the DHCP server, BUT NOW, according to a new extensio= n to NDP, in RFC 6106, the router advertisement contains the DNS informatio= n also so there is no need for DHCP server configuration.=

= What is the problem now in this local network – what gap CGA-TSIG fil= ls

Briefly:

It provides local securi= ty in IPv6 networks without the need for extra configuration as it uses the= current security parameters and mechanism available on this network, i.e.,= SEND.  When node addresses change over time in IPv6 networks for priv= acy reasons, CGA-TSIG provides the necessary security in IPv6 networks for = the DNS authentication process. This solution works very well in local netw= orks, but also is applicable in global networks.

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>- Local= security is an important issue: In IPv6 networks that use NDP, there i= s no central server available to perform the updates to DNS records on beha= lf of the client. As local security is important, as well as global securit= y, CGA-TSIG provides a solution for the automation of this process and allo= ws for client authentication with DNS servers as well as the ability to upd= ate their own records.

The question that might arise here is= , why local security is important?:

The answer here is the sa= me as that provided for the use of SEcure Neighbor Discovery in IPv6 networ= ks. Many attacks are internal and not via the Internet. When, because of fl= aws or viruses or…, a host in a network is infected that gives the at= tacker control of that host the role of local security is highlighted. In t= his case the attacker is inside your network and using the legitimate nodes= inside your network for their malicious purposes. Therefore, if you just t= hink about global security, you have just partly secured your network!

If we also consider the case where the host's generates their IP= address and keep it as long as it is connected to the same network. When t= his legitimate node, for the first time, join to a network, if TSIG or othe= r security mechanisms are used, the administrator needs to generate this sh= ared secret so that it is only shared between this host and the DNS server.= Thus CGA-TSIG reduces this task, while at the same time, provides the secu= rity necessary for DNS servers and clients.

- Privacy is= the second or another important issue: In Europe, privacy is a very im= portant issue. An example of that is in Germany that the ISPs are forced to= change their range of IP addresses frequently. In this case, for every cha= nge, the administrators of the sub-networks, using these ISPs, need to reco= nfigure their clients and servers to again use the security mechanism for a= uthentication purposes. CGA-TSIG is the solution. It can provide this authe= ntication without the need for more configuration

- Global= security: the same approach is applicable for authentication purposes = among the DNS servers on the Internet if they are under the privacy rules t= hat force them to change their ISP's prefix, as was explained in my first p= oint

Finally : DNS serves or clients only need use the c= ached CGA data and do not need to regenerate CGA! This is an important poin= t because only a few changes need be made  to the current implementati= on of DNS server.

I will provide you with the list of more at= tacks later.  Some of the attacks that CGA-TSIG can prevent are found = in Security consideration section at the following link:<= /p>

http://tools.ietf.org/html/draft-rafiee-intarea-cga-ts= ig-00#section-4

<= b>I welco= me all questions and comments that can help to clear up the purpose of this= draft. Thank you all for your help. It is greatly appreciated.<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>

Thank you again,

Hosnieh

 

 

= --_000_EA738325B0580041A50A364F5F76B68924D4465CF88MXMA1Rhpiuni_-- From rafiee@hpi.uni-potsdam.de Thu Nov 8 06:22:53 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC4A21F8AD7; Thu, 8 Nov 2012 06:22:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am8Ee3HfMj1i; Thu, 8 Nov 2012 06:22:42 -0800 (PST) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC221F8B97; Thu, 8 Nov 2012 06:22:40 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id 9FFA4169E4D; Thu, 8 Nov 2012 15:22:39 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Thu, 8 Nov 2012 15:22:39 +0100 From: "Rafiee, Hosnieh" To: Dave Thaler Date: Thu, 8 Nov 2012 15:22:35 +0100 Thread-Topic: (CGA-TSIG) answers to some of the comments Thread-Index: Ac285dnqWsyLqCHNR5+px/yGKKx0JQAOEzPQACP1VOA= Message-ID: References: <9B57C850BB53634CACEC56EF4853FF653B90869E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B90869E@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D4465CF08MXMA1Rhpiuni_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 12 Nov 2012 08:33:52 -0800 Cc: "Suresh Krishnan \(suresh.krishnan@ericsson.com\)" Subject: Re: [dnsext] (CGA-TSIG) answers to some of the comments X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:22:53 -0000 --_000_EA738325B0580041A50A364F5F76B68924D4465CF08MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, 1) Having the DHCP server do dynamic update is not necessarily just for add= resses allocated by DHCP. See http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is= a DHC WG draft. Thanks a lot for your answer. Please check the consideration section of the= draft you referred to. The stated approach is prone to attacks as it is so= lely about an extra management efforts and not security approaches. To prev= ent the attacks it also stated using SEND. Now the question is, when you want to use SEND to secure your local network= , my approach is also applicable and better fits than TSIG itself as you do= not need to generate public private keys, CGA and you use the same value a= vailable there. DHCPv6 is only useful when you would like to have more management and admin= istration control on your network. But, if you only want to know who used w= hich address, you do not need to go to extra configuration , you need just = a passive monitoring system in the network to sniff all ICMPv6 unsolicited = Neighbor advertisement packets and delete them from the monitoring database= if receive no more NA messages from that node. (frequently nodes update th= eir cache and send NA) 2- Is not true. DNS information is not the only information obtained thro= ugh DHCP, it's a general purpose mechanism through which many things are, and can be, obtained. It is a bad idea to = try to pollute RAs with such information (for one, you're limited to the MTU in RAs). See RFC 5505 section 2.3 for = some more discussion. DNS information is just an information missing in NDP. For addressing not m= ore option is required for a node. I am not quite understand and convinced = that why every time you change the talk to DHCPv6. I am talking about the n= etworks where SEND is used and not DHCPv6. I do not have any discussion abo= ut whether or not the DNS options in RAs is the best. 3- RFC 6434 section 6 even states "Hosts will need to decide which mechanism (or whether both) should be implemented." The fact that we actually have two mechanisms is a bad thing. This is why based on the network requirements, administrator can choose whi= ch one to use. 3) The main feedback some of us provided is that the proposal would be far = more widely applicable and useful if it just passed a public key and used the le= ap of faith model like SSH, rather than narrowing the use case significantly and depend= ing on implementation of CGA, which isn't really implemented/deployed in practice = today. It is not true. Please check this website http://en.wikipedia.org/wiki/Secu= re_Neighbor_Discovery_Protocol . And about using SSH, It might be a good solution to this problem (but so ge= neral) that if you like we can work on that on a separate draft together. The CGA-TSIG focused on a solution to this problem in IPv6 network when usi= ng SEND in local security. I am not agree with you in this sentence " it is= far applicable ", because when for the local security you use SEND you can= easily use this approach without any configuration for your clients side. Thank you, Hosnieh P.S. I also included DANE WG. From: Dave Thaler [mailto:dthaler@microsoft.com] Sent: Wednesday, November 07, 2012 8:40 PM To: Rafiee, Hosnieh; Suresh Krishnan (suresh.krishnan@ericsson.com); julien.ietf@gmail.com Cc: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de Subject: RE: (CGA-TSIG) answers to some of the comments Quick response... 1) Having the DHCP server do dynamic update is not necessarily just for add= resses allocated by DHCP. See http://tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is= a DHC WG draft. 2) "RFC 6106, the router advertisement contains the DNS information also so= there is no need for DHCP server configuration" Is not true. DNS information is not the only information obtained through= DHCP, it's a general purpose mechanism through which many things are, and can be, obtained. It is a bad idea to = try to pollute RAs with such information (for one, you're limited to the MTU in RAs). See RFC 5505 section 2.3 for = some more discussion. RFC 6434 section 6 even states "Hosts will need to decide which mechanism (or whether both) should be implemented." The fact that we actually have two mechanisms is a bad thing. 3) The main feedback some of us provided is that the proposal would be far = more widely applicable and useful if it just passed a public key and used the le= ap of faith model like SSH, rather than narrowing the use case significantly and depend= ing on implementation of CGA, which isn't really implemented/deployed in practice = today. -Dave From: int-area-bounces@ietf.org [mailto:i= nt-area-bounces@ietf.org] On Behalf Of Rafiee, Hosnieh Sent: Wednesday, November 7, 2012 10:28 AM To: Suresh Krishnan (suresh.krishnan@ericsson.com); julien.ietf@gmail.com Cc: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de Subject: [Int-area] (CGA-TSIG) answers to some of the comments Thanks to Julian, Suresh and others for all their comments on my presentati= on. Following are the answers to the questions raised and, hopefully, this = will clarify the main purpose of this draft: - A comment was made that DHCP can update the clients' DNS records on behal= f of the clients so they see any no reason for this draft as DHCPv6 can upd= ate the DNS records for the clients on behalf of them. Here we are talking about another IPv6 addressing mechanism, i.e., Neighbor= Discovery Protocol (RFC 4861) and not DHCPv6. NDP is a new addressing mechanism included in the IPv6 suite that functions= like ARP, discovering other neighbor nodes, ICMP, and address configuratio= n automatically. By default, all operating systems support this functionali= ty and, for windows, it is the default method of addressing. - Why do some administrators prefer to use NDP instead of DHCPv6? With NDP no DHCP server configuration is required. - Usage of NDP protocol All kinds of networks like campus, companies whether they are public and pr= ivate - How can a client or a server in IPv6 networks set its IP address using ND= P When you connect your computer to an IPv6 network, your computer generates = its IP address automatically and then processes duplicate address detection= by using 5 types of ICMPv6 messages. Your computer also sets its global ad= dress by using the router advertisement. The administrator just needs to en= able NDP on his router and configure it to advertise his available prefixes= . It is a great way to manage the network. - The problem with NDP WAS (solved now) Before, it did not support the DNS option and it took the DNS information f= rom the DHCP server, BUT NOW, according to a new extension to NDP, in RFC 6= 106, the router advertisement contains the DNS information also so there is= no need for DHCP server configuration. What is the problem now in this local network - what gap CGA-TSIG fills Briefly: It provides local security in IPv6 networks without the need for extra conf= iguration as it uses the current security parameters and mechanism availabl= e on this network, i.e., SEND. When node addresses change over time in IPv= 6 networks for privacy reasons, CGA-TSIG provides the necessary security in= IPv6 networks for the DNS authentication process. This solution works very= well in local networks, but also is applicable in global networks. - Local security is an important issue: In IPv6 networks that use NDP, ther= e is no central server available to perform the updates to DNS records on b= ehalf of the client. As local security is important, as well as global secu= rity, CGA-TSIG provides a solution for the automation of this process and a= llows for client authentication with DNS servers as well as the ability to = update their own records. The question that might arise here is, why local security is important?: The answer here is the same as that provided for the use of SEcure Neighbor= Discovery in IPv6 networks. Many attacks are internal and not via the Inte= rnet. When, because of flaws or viruses or..., a host in a network is infec= ted that gives the attacker control of that host the role of local security= is highlighted. In this case the attacker is inside your network and using= the legitimate nodes inside your network for their malicious purposes. The= refore, if you just think about global security, you have just partly secur= ed your network! If we also consider the case where the host's generates their IP address an= d keep it as long as it is connected to the same network. When this legitim= ate node, for the first time, join to a network, if TSIG or other security = mechanisms are used, the administrator needs to generate this shared secret= so that it is only shared between this host and the DNS server. Thus CGA-T= SIG reduces this task, while at the same time, provides the security necess= ary for DNS servers and clients. - Privacy is the second or another important issue: In Europe, privacy is a= very important issue. An example of that is in Germany that the ISPs are f= orced to change their range of IP addresses frequently. In this case, for e= very change, the administrators of the sub-networks, using these ISPs, need= to reconfigure their clients and servers to again use the security mechani= sm for authentication purposes. CGA-TSIG is the solution. It can provide th= is authentication without the need for more configuration - Global security: the same approach is applicable for authentication purpo= ses among the DNS servers on the Internet if they are under the privacy rul= es that force them to change their ISP's prefix, as was explained in my fir= st point Finally : DNS serves or clients only need use the cached CGA data and do no= t need to regenerate CGA! This is an important point because only a few cha= nges need be made to the current implementation of DNS server. I will provide you with the list of more attacks later. Some of the attack= s that CGA-TSIG can prevent are found in Security consideration section at = the following link: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-00#section-4 I welcome all questions and comments that can help to clear up the purpose = of this draft. Thank you all for your help. It is greatly appreciated. Thank you again, Hosnieh --_000_EA738325B0580041A50A364F5F76B68924D4465CF08MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

1) Having the DHCP server do dynamic update is not neces= sarily just for addresses allocated by DHCP.
See http://tools.ietf.org/h= tml/draft-ietf-dhc-addr-registration-01 which is a DHC WG draft.

Thanks a lot for your answer. Please ch= eck the consideration section of the draft you referred to. The stated appr= oach is prone to attacks as it is solely about an extra management efforts = and not security approaches. To prevent the attacks it also stated using= SEND.

Now the question is, when yo= u want to use SEND to secure your local network, my approach is also applic= able and better fits than TSIG itself as you do not need to generate public= private keys, CGA and you use the same value available there.

DHCPv6 is only useful when you would like to have mo= re management and administration control on your network. But, if you only = want to know who used which address, you do not need to go to extra configu= ration , you need just a passive monitoring system in the network to sniff = all ICMPv6 unsolicited Neighbor advertisement packets and delete them from = the monitoring database if receive no more NA messages from that node. (fre= quently nodes update their cache and send NA)

2- Is not true.   DNS information is = not the only information obtained through DHCP, it’s a general purpos= e mechanism
through which many things are, and can be, obtained. &n= bsp; It is a bad idea to try to pollute RAs with such information
(for o= ne, you’re limited to the MTU in RAs).  See RFC 5505 section 2.3= for some more discussion.

DNS information is just an information missing in NDP. For addressing not= more option is required for a node. I am not quite understand and convince= d that why every time you change the talk to DHCPv6. I am talking about the= networks where SEND is used and not DHCPv6. I do not have any discussion a= bout whether or not the DNS options in RAs is the best.

3- RFC 6434 section 6 even s=
tates
“Hosts will need to decide which mechanism (or whether both) sho=
uld be

implemented.”
The fact that we actually have two m= echanisms is a bad thing.

This is why based on the network requirements, administrator can c= hoose which one to use.

3) The main feedback some of us provided is = that the proposal would be far more
widely applicable and useful if it j= ust passed a public key and used the leap of faith
model like SSH, rathe= r than narrowing the use case significantly and depending on
implementat= ion of CGA, which isn’t really implemented/deployed in practice today= .

It is not tru= e. Please check this website http://en.wikipedia.org/wiki/Secure_Neighbor_= Discovery_Protocol .

And about using SSH, It might be a good solution to this problem= (but so general) that if you like we can work on that on a separate draft = together.

The= CGA-TSIG focused on a solution to this problem in IPv6 network when using = SEND in local security. I am not agree with you in this sentence “ it= is far applicable “, because when for the local security you use SEN= D you can easily use this approach without any configuration for your clien= ts side.

Thank you,<= /o:p>

Hosnieh

<= p class=3DMsoNormal>P.S. I also included DANE WG.=

 

 

 

<= p class=3DMsoNormal> <= /p>

From: Dave Thaler [mailto:dthaler@microsoft.com]
Sent: Wednesday= , November 07, 2012 8:40 PM
To: Rafiee, Hosnieh; Suresh Krishnan = (suresh.krishnan@ericsson.c= om); julien.ietf@gmail.com=
Cc: Int-area@ietf.org; = dnsext@ietf.org; martin@v.loewis.de
Subject: RE: (CGA-TSIG)= answers to some of the comments

 

Quick response…

<= span style=3D'color:#1F497D'>1) Having the DHCP server do dynamic update is= not necessarily just for addresses allocated by DHCP.
See http:/= /tools.ietf.org/html/draft-ietf-dhc-addr-registration-01 which is a DHC WG draft.

2) “RFC 6106, th= e router advertisement contains the DNS information also so there is no nee= d for DHCP server configuration”

Is not true.   DNS information is not the only info= rmation obtained through DHCP, it’s a general purpose mechanism
th= rough which many things are, and can be, obtained.   It is a bad = idea to try to pollute RAs with such information
(for one, you’re = limited to the MTU in RAs).  See RFC 5505 section 2.3 for some more di= scussion.

RFC 6434 sect=
ion 6 even states
“=
Hosts will need to decide which mechanism (or whether both) shoul=
d be

implemente= d.”
The fact that we actually have two mechanisms is a bad thing.<= o:p>

3) The main feedb= ack some of us provided is that the proposal would be far more
widely ap= plicable and useful if it just passed a public key and used the leap of fai= th
model like SSH, rather than narrowing the use case significantly and = depending on
implementation of CGA, which isn’t really implemented= /deployed in practice today.

-Dave

= From: int-area-bounces@= ietf.org [mailto:int-area-= bounces@ietf.org] On Behalf Of Rafiee, Hosnieh
Sent: W= ednesday, November 7, 2012 10:28 AM
To: Suresh Krishnan (suresh.krishnan@ericsson.com);= julien.ietf@gmail.com
C= c: Int-area@ietf.org; dnsext@ietf.org; martin@v.loewis.de
Subject: [Int-area] (CGA-TSIG)= answers to some of the comments

 

Thanks to Julian, Suresh and others for all their commen= ts on my presentation. Following are the answers to the questions raised an= d, hopefully, this will  clarify the main purpose of this draft:<= /o:p>

- A comment was made that DHCP can update the clients' DNS r= ecords on behalf of the clients so they see any no reason for this draft as= DHCPv6 can update the DNS records for the clients on behalf of them. =

Here we are talking about another IPv6 addressing mechani= sm, i.e., Neighbor Discovery Protocol (RFC 4861) and not DHCPv6.=

NDP is a new addressing mechanism included in the IPv6 suite that funct= ions like ARP, discovering other neighbor nodes, ICMP, and address configur= ation automatically. By default, all operating systems support this functio= nality and, for windows, it is the default method of addressing.=

- Why do some administrators prefer to use NDP instead of DHCPv6?=

With NDP no DHCP server configuration is required. <= o:p>

- Usage of NDP protocol

= All kinds= of networks like campus, companies whether they are public and private

- How can a client or a server in IPv6 networks set its IP= address using NDP

When you connect your computer to= an IPv6 network, your computer generates its IP address automatically and = then processes duplicate address detection by using 5 types of ICMPv6 messa= ges. Your computer also sets its global address by using the router adverti= sement. The administrator just needs to enable NDP on his router and config= ure it to advertise his available prefixes. It is a great way to manage the= network.

- The problem with NDP WAS (solved now)=

Before, it did not support the DNS option and it took the= DNS information from the DHCP server, BUT NOW, according to a new extensio= n to NDP, in RFC 6106, the router advertisement contains the DNS informatio= n also so there is no need for DHCP server configuration.=

= What is the problem now in this local network – what gap CGA-TSIG fil= ls

Briefly:

It provides local securi= ty in IPv6 networks without the need for extra configuration as it uses the= current security parameters and mechanism available on this network, i.e.,= SEND.  When node addresses change over time in IPv6 networks for priv= acy reasons, CGA-TSIG provides the necessary security in IPv6 networks for = the DNS authentication process. This solution works very well in local netw= orks, but also is applicable in global networks.

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>- Local= security is an important issue: In IPv6 networks that use NDP, there i= s no central server available to perform the updates to DNS records on beha= lf of the client. As local security is important, as well as global securit= y, CGA-TSIG provides a solution for the automation of this process and allo= ws for client authentication with DNS servers as well as the ability to upd= ate their own records.

The question that might arise here is= , why local security is important?:

The answer here is the sa= me as that provided for the use of SEcure Neighbor Discovery in IPv6 networ= ks. Many attacks are internal and not via the Internet. When, because of fl= aws or viruses or…, a host in a network is infected that gives the at= tacker control of that host the role of local security is highlighted. In t= his case the attacker is inside your network and using the legitimate nodes= inside your network for their malicious purposes. Therefore, if you just t= hink about global security, you have just partly secured your network!

If we also consider the case where the host's generates their IP= address and keep it as long as it is connected to the same network. When t= his legitimate node, for the first time, join to a network, if TSIG or othe= r security mechanisms are used, the administrator needs to generate this sh= ared secret so that it is only shared between this host and the DNS server.= Thus CGA-TSIG reduces this task, while at the same time, provides the secu= rity necessary for DNS servers and clients.

- Privacy is= the second or another important issue: In Europe, privacy is a very im= portant issue. An example of that is in Germany that the ISPs are forced to= change their range of IP addresses frequently. In this case, for every cha= nge, the administrators of the sub-networks, using these ISPs, need to reco= nfigure their clients and servers to again use the security mechanism for a= uthentication purposes. CGA-TSIG is the solution. It can provide this authe= ntication without the need for more configuration

- Global= security: the same approach is applicable for authentication purposes = among the DNS servers on the Internet if they are under the privacy rules t= hat force them to change their ISP's prefix, as was explained in my first p= oint

Finally : DNS serves or clients only need use the c= ached CGA data and do not need to regenerate CGA! This is an important poin= t because only a few changes need be made  to the current implementati= on of DNS server.

I will provide you with the list of more at= tacks later.  Some of the attacks that CGA-TSIG can prevent are found = in Security consideration section at the following link:<= /p>

http://tools.ietf.org/html/draft-rafiee-intarea-cga-ts= ig-00#section-4

<= b>I welco= me all questions and comments that can help to clear up the purpose of this= draft. Thank you all for your help. It is greatly appreciated.<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>

Thank you again,

Hosnieh

 

 

= --_000_EA738325B0580041A50A364F5F76B68924D4465CF08MXMA1Rhpiuni_-- From iesg-secretary@ietf.org Thu Nov 15 14:40:17 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBCF21F84E7; Thu, 15 Nov 2012 14:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMMRnNKBkjgg; Thu, 15 Nov 2012 14:40:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C734321F84E8; Thu, 15 Nov 2012 14:40:05 -0800 (PST) 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: 4.36 Message-ID: <20121115224005.11459.53607.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 14:40:05 -0800 Cc: dnsext chair , dnsext mailing list , RFC Editor Subject: [dnsext] Protocol Action: 'Clarifications and Implementation Notes for DNSSEC' to Proposed Standard (draft-ietf-dnsext-dnssec-bis-updates-20.txt) X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:40:17 -0000 The IESG has approved the following document: - 'Clarifications and Implementation Notes for DNSSEC' (draft-ietf-dnsext-dnssec-bis-updates-20.txt) as Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-bis-updates/ Technical Summary DNSSECbis was published in RFC 4033, RFC 4034, and RFC 4035. Since the publication, some people filed errata against those documents, some additional developments added to DNSSECbis, and some implementation experience illustrated ambiguities or issues with the original texts. This draft collects those issues in a single place, updating the DNSSECbis specification and clarifying it where need be. Working Group Summary This draft is the product of the DNS Extensions Working Group. Many of the clarifications came easily. The more contentious parts of the document have been discussed at length. For the most controversial of the clarifications, extensive discussion is included in appendices so that implementers and deployers may make informed decisions. Document Quality Most, if not all, of the document is reflected in the bulk of DNSSECbis validators and signers deployed on the Internet. The document is the result of several years of experience and discussion, collected with an eye to improving implementations. One of the most contentious parts resulted in multiple rounds of discussion and a special design team meeting. The document as it stands has been refined over a long period of time, and is of high quality. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Andrew Sullivan is the Document Shepherd, and Ralph Droms is the Responsible Area Director.Technical Summary From rafiee@hpi.uni-potsdam.de Mon Nov 19 13:29:55 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD0821F8734; Mon, 19 Nov 2012 13:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLJwqHQ1I5Vf; Mon, 19 Nov 2012 13:29:54 -0800 (PST) Received: from mail2.hpi.uni-potsdam.de (mail2.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17a]) by ietfa.amsl.com (Postfix) with ESMTP id F3C0D21F8733; Mon, 19 Nov 2012 13:29:53 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail2.hpi.uni-potsdam.de (Postfix) with ESMTP id 0A266D2C99; Mon, 19 Nov 2012 22:29:52 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Mon, 19 Nov 2012 22:29:51 +0100 From: "Rafiee, Hosnieh" To: Joshua Shire Date: Mon, 19 Nov 2012 22:29:47 +0100 Thread-Topic: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2rFSiGjyyz01Y/QQq74El/UneB+gFbhdAwBO/k3qAAAREhIACQiQTwAARG0ZA= Message-ID: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Int-area@ietf.org" , "dnsext@ietf.org" Subject: Re: [dnsext] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 21:29:55 -0000 Dear Joshua, Thanks a lot for your suggestions. >Speaking of typos, the modifier is actually 128 bits not 64 as I stated ;)= . Yes I understand. It was a mistake. In my implementation I did not make thi= s funny mistake but it seems in writing I did :-) If I can update my RFC (currently having formatting issue for uploading...)= then the new version will hopefully be free of these kinds of mistakes. >Regarding 4), Check Time Signed, if you look at a widely used standard lik= e Kerberos, it calls for a rough clock sync of 5 minutes. For the purposes = of anti-replay prevention (which I believe this step in >your protocol is d= esigned to thwart?) it seems to provide good security without causing too m= any issues (but you still do get clients with errors popping up from time t= o time). Lastly regarding 5), >signature, that's fine, you just may want to= be specific that RSASSA-PSS (or something else) should be used rather than= leaving it up to interpretation or preference, which may cause interoperab= ility >issues. Just a suggestion. I clarified this in new version. Maybe somebody can give me a suggestion... I actually wrote a Web applicati= on that should aid in formatting RFC (maybe also later useful for others as= it will be available public on my website). It works fine and generates a = nice txt version with the required tags but when I want to submit this draf= t I receive meta-data error and it cannot retreive the authors' names. I co= mpared the output of my application with the one that does not have any pro= blem in different formats such as ASCII, but I could not find any special = characters or any problem that cause this failure result.=20 I look forward to receiving any help I can get to make this application gen= erate a file that is acceptable for automatic process submission. (If I kne= w what the IETF parser was looking for, I could add it to my application to= make it work. But I could not find anything anywhere) Best, Hosnieh -----Original Message----- From: Joshua Shire [mailto:jshire@hyduke.com]=20 Sent: Monday, November 19, 2012 10:05 PM To: Rafiee, Hosnieh Cc: Int-area@ietf.org Subject: RE: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-0= 0.txt Thanks for your responses. Speaking of typos, the modifier is actually 128 bits not 64 as I stated ;). Regarding 4), Check Time Signed, if you look at a widely used standard like= Kerberos, it calls for a rough clock sync of 5 minutes. For the purposes o= f anti-replay prevention (which I believe this step in your protocol is des= igned to thwart?) it seems to provide good security without causing too man= y issues (but you still do get clients with errors popping up from time to = time). Lastly regarding 5), signature, that's fine, you just may want to be= specific that RSASSA-PSS (or something else) should be used rather than le= aving it up to interpretation or preference, which may cause interoperabili= ty issues. Just a suggestion. Thanks, Joshua Shire Information Systems Manager Hyduke Energy Services Inc. ph: 780-955-0401 fax: 780-955-0368 mx: help@hyduke.com -----Original Message----- From: Rafiee, Hosnieh [mailto:rafiee@hpi.uni-potsdam.de]=20 Sent: Friday, November 16, 2012 4:49 PM To: Joshua Shire Cc: Int-area@ietf.org Subject: RE: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-0= 0.txt Dear Joshua, Thank you so much for your comments. Please find the answer below. >1) RFC3972 ("CGA") specifies that the modifier should be 64 bits and the c= ollision count eight bits, yet I notice in Figure 2 it specifies a 16 bit m= odifier and a 1 bit collision count. Can you explain why you chose to imple= ment this differently? - No, that was a typo. It will be corrected in the updated version that I w= ill submit this weekend 2) In your implementation of the protocol you call for DAD but it does not = mention (or maybe I just can't find) what do re: collision count if a dupli= cate address is detected. Further, in 3.2.1.2 I don't see a step to verify = this number as per CGA. I'm assuming you're to follow the specs from CGA bu= t you may want to be specific regarding this. - After I implemented this draft RFC, I noticed that the values must be cac= hed and the DNS server should not be involved in generating CGA values or b= e involved in addressing. So, this section is for the SEND implementation i= nstalled on a DNS server or a client. In my new draft this section will als= o be updated. 3) In 3.1 step 5 you may want to be clear that bits seven and eight should = be set to zero. -I will correct it and included in my update version. 4) In 3.2.1.2, step 2, Check Time Signed, your window seems very short give= n typical retransmission timeouts and the like.=20 - I will examine my implemenation on a larger scale to see what the delay w= ill be and will update the document accordingly. 5) 3.2.1.2 step 5, Verify the signature, I don't see exact method you want = used in this protocol to accomplish this. - Please clarify this question. As you probably know, the signature verific= ation function uses a minimum of 2 values; the plaintext and the signature = itself. The default algorithm here is RSA. This is what I meant when I sai= d signature verification. The DNS server retreives all the plaintext conten= ts (CGA parameters, time signed, DNS update) of the signature and also the = signature itself and then verfies this signature using the RSA algorithm. T= he result is a boolean value.=20 =20 Joshua >Would you actually be running these algorithms again just for the p= urpose of sending a DNS update or=20 - No, just data cached in the server. The current SEND implementation would= cache this data when the server or a client wants to generate a new IP add= ress using SEND. CGA-TSIG is an application layer protocol.=20 Joshua >would you be layering on top of the existing IP stack and using the= existing CGA functionality? Yes Best, Hosnieh From rafiee@hpi.uni-potsdam.de Thu Nov 22 15:01:13 2012 Return-Path: X-Original-To: dnsext@ietfa.amsl.com Delivered-To: dnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CD521F88D5 for ; Thu, 22 Nov 2012 15:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMUB500ozQn7 for ; Thu, 22 Nov 2012 15:01:11 -0800 (PST) Received: from mail3.hpi.uni-potsdam.de (mail3.hpi.uni-potsdam.de [IPv6:2001:638:807:204::8d59:e17b]) by ietfa.amsl.com (Postfix) with ESMTP id 13EDD21F8503 for ; Thu, 22 Nov 2012 15:01:05 -0800 (PST) Received: from owa2.hpi.uni-potsdam.de (owa2.hpi.uni-potsdam.de [141.89.225.162]) by mail3.hpi.uni-potsdam.de (Postfix) with ESMTP id E0E92169E9C; Fri, 23 Nov 2012 00:01:03 +0100 (CET) Received: from 8MXMA1R.hpi.uni-potsdam.de ([fe80::88e9:3d98:b35f:83bf]) by OWA2.hpi.uni-potsdam.de ([2002:8d59:e1a2::8d59:e1a2]) with mapi; Fri, 23 Nov 2012 00:01:01 +0100 From: "Rafiee, Hosnieh" To: "Dan York (dan-ietf@danyork.org)" , "Mark Andrews (marka@isc.org)" , "Mohan Parthasarathy (suruti94@gmail.com)" , Joshua Shire Date: Fri, 23 Nov 2012 00:01:00 +0100 Thread-Topic: Please comment on this updated version < draft-rafiee-intarea-cga-tsig-01.txt> Thread-Index: Ac3JBFwvFEnPMQYYT+CKEJ+BPKWaXgAAJcyQ Message-ID: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dnsext@ietf.org" Subject: [dnsext] Please comment on this updated version < draft-rafiee-intarea-cga-tsig-01.txt> X-BeenThere: dnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DNS Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 23:01:14 -0000 DQpIZWxsbywNCkkgcmV2aXNlZCAgbXkgZHJhZnQtcmFmaWVlLWludGFyZWEtY2dhLXRzaWcgaW5j b3Jwb3JhdGluZyB5b3VyIGNvbW1lbnRzIHRoYXQgSSByZWNlaXZlZCBieSBlbWFpbC4gUGxlYXNl IHJldmlldyBteSByZXZpc2VkIGRvY3VtZW50Lg0KQmVzdCBSZWdhcmRzLA0KSG9zbmllaA0KDQoN ClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtcmFmaWVlLWludGFyZWEtY2dhLXRzaWctMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFmaWVlLWludGFyZWEtY2dhLXRzaWcN Ckh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFmaWVl LWludGFyZWEtY2dhLXRzaWctMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtcmFmaWVlLWludGFyZWEtY2dhLXRzaWctMDENCg0KQWJzdHJh Y3Q6DQogICBUaGUgZmlyc3Qgc3RlcCBpbiB0aGUgVHJhbnNhY3Rpb24gU0lHbmF0dXJlIChUU0lH KSAoUkZDIDI4NDUpIHByb2Nlc3MNCiAgIGlzIHRoZSBnZW5lcmF0aW9uIG9mIGEgc2hhcmVkIHNl Y3JldCB0byBiZSB1c2VkIGJldHdlZW4gYSBETlMgc2VydmVyDQogICBhbmQgYSBob3N0LiBUaGUg c2Vjb25kIHN0ZXAgaXMgdGhlIG1hbnVhbCBleGNoYW5nZSBvZiB0aGUgc2hhcmVkDQogICBzZWNy ZXQgYmV0d2VlbiB0aGUgRE5TIHNlcnZlciBhbmQgdGhlIGhvc3QuIFRoaXMgZG9jdW1lbnQsIENH QS1UU0lHLA0KICAgcHJvcG9zZXMgYSBwb3NzaWJsZSB3YXkgdG8gYXV0b21hdGUgdGhlIG5vdyBt YW51YWwgcHJvY2VzcyB1c2VkIGZvcg0KICAgdGhlIGF1dGhlbnRpY2F0aW9uIG9mIGEgbm9kZSB3 aXRoIGEgRE5TIHNlcnZlciBkdXJpbmcgdGhlIEROUyBVcGRhdGUNCiAgIHByb2Nlc3MgYnkgdXNp bmcgdGhlIHNhbWUgcGFyYW1ldGVycyBhcyBhcmUgdXNlZCBpbiBnZW5lcmF0aW5nIGENCiAgIHNl Y3VyZSBhZGRyZXNzIGluIElQdjYgbmV0d29ya3MsIGkuZS4sIENyeXB0b2dyYXBoaWNhbGx5IEdl bmVyYXRlZA0KICAgQWRkcmVzc2VzIChDR0EpIChSRkMgMzk3MikuIENHQS1UU0lHIGZhY2lsaXRh dGVzIHRoaXMgYXV0aGVudGljYXRpb24NCiAgIHByb2Nlc3MgYW5kIHJlZHVjZXMgdGhlIHRpbWUg bmVlZGVkIGZvciBETlMgVXBkYXRlcy4gVGhlIGN1cnJlbnQNCiAgIHNpZ25hdHVyZSBnZW5lcmF0 aW9uIHByb2Nlc3MgYW5kIHZlcmlmaWNhdGlvbiBtZWNoYW5pc20gaW4gVFNJRyBhcmUNCiAgIHRo dXMgcmVwbGFjZWQgd2l0aCBDR0EuIFRoaXMgYWxnb3JpdGhtIGlzIGFkZGVkLCBhcyBhbiBleHRl bnNpb24sIHRvDQogICBUU0lHIHRvIGVsaW1pbmF0ZSB0aGUgaHVtYW4gaW50ZXJ2ZW50aW9uIG5l ZWRlZCBmb3IgZ2VuZXJhdGlvbiBhbmQNCiAgIGV4Y2hhbmdlIG9mIGtleXMgYmV0d2VlbiBhIERO UyBzZXJ2ZXIgYW5kIGEgaG9zdCB3aGVuIFNFY3VyZSBOZWlnaGJvcg0KICAgRGlzY292ZXJ5IChT RU5EKSAoUkZDIDM5NzEpIGlzIHVzZWQuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K