From suresh.krishnan@ericsson.com Thu Nov 1 11:45:47 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4A221F935C for ; Thu, 1 Nov 2012 11:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 R10G+dkQxNEy for ; Thu, 1 Nov 2012 11:45:47 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id F344421F9269 for ; Thu, 1 Nov 2012 11:45:46 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qA1InwbN031949 for ; Thu, 1 Nov 2012 13:50:02 -0500 Received: from [142.133.112.74] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 1 Nov 2012 14:45:45 -0400 Message-ID: <5092C358.2010702@ericsson.com> Date: Thu, 1 Nov 2012 14:45:44 -0400 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Internet Area References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> In-Reply-To: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] Fwd: CORRECTION: Help the NomCom X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 18:45:47 -0000 Please consider providing feedback to the Nomcom. They need the community's feedback to pick good candidates for the open positions. Thanks Suresh -------- Original Message -------- Subject: CORRECTION: Help the NomCom Date: Thu, 1 Nov 2012 05:17:22 -0700 From: NomCom Chair To: 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 From brian@innovationslab.net Sun Nov 4 07:44:12 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C6721F8712 for ; Sun, 4 Nov 2012 07:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 3nWCCml-WzAu for ; Sun, 4 Nov 2012 07:44:12 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 005B821F8707 for ; Sun, 4 Nov 2012 07:44:11 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id A552888165 for ; Sun, 4 Nov 2012 07:44:11 -0800 (PST) Received: from dhcp-504b.meeting.ietf.org (dhcp-504b.meeting.ietf.org [130.129.80.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 75BF114003B for ; Sun, 4 Nov 2012 07:44:11 -0800 (PST) Message-ID: <50968D4D.9070000@innovationslab.net> Date: Sun, 04 Nov 2012 10:44:13 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: int-area@ietf.org References: <507EC1F9.5070700@innovationslab.net> In-Reply-To: <507EC1F9.5070700@innovationslab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Int-area] INT AD Office Hours X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 15:44:12 -0000 Just a reminder of this opportunity. The IESG breakout room is room 202. Feel free to bring any ideas, issues, concerns, or questions. Regards, Brian & Ralph On 10/17/12 10:34 AM, Brian Haberman wrote: > All, > The INT ADs will be holding office hours on Thursday (Nov. 8) of > the IETF meeting from 1730-1900 in the IESG breakout room. Feel free to > stop by and chat about any INT Area issues that you have. > > Regards, > Brian & Ralph From zehn.cao@gmail.com Mon Nov 5 10:56:57 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A15F21F8747 for ; Mon, 5 Nov 2012 10:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MPSx5SOruXa for ; Mon, 5 Nov 2012 10:56:56 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C65621F8703 for ; Mon, 5 Nov 2012 10:56:56 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so9603199iec.31 for ; Mon, 05 Nov 2012 10:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8U3EA4qmvZnxgGD9cQ1R7HPFI7KBhMjfN/ZIKvf0pZg=; b=H7DNNe5nBFcS8O8n+4hdqljSCM9ARiIq36bee69oBD6XoJd2cQpXkAwwwy4oIZQM/Y ERqIzMlZigGrA7gqyZwMqlKMu4GcllRtm2K4ZnmYNr4CxGEgdmn9yTKJby3SPTq/QWuN MPLaeGRgEqZrhdlCuIYAkxkuG2u0qhRSAcgYe5CQ9bd3R05C2qNz2hLKBMbFj5dHKyev DAe/LKN6FyRc6WjeJUiZxkuhSA3UwIzl9e+KE47UiV6VO+a/O3I2bPXwIx9gSIPXnZBk HIBcyjzOFnxCAx2+iYKql8cae/1Muq1r7svTjYBUOjxBElMLeI3JaPPB994ky3sLUB1t zg6g== MIME-Version: 1.0 Received: by 10.50.212.8 with SMTP id ng8mr10381600igc.64.1352141816148; Mon, 05 Nov 2012 10:56:56 -0800 (PST) Received: by 10.64.28.9 with HTTP; Mon, 5 Nov 2012 10:56:56 -0800 (PST) Date: Mon, 5 Nov 2012 13:56:56 -0500 Message-ID: From: "Cao Zhen (cz)" To: int-area@ietf.org, Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Subject: [Int-area] Comments to ALFI X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 18:56:57 -0000 Hi Carsten, The problem you describe is cool. But in Lwig guidance document, I remember there is a guidance saying we should avoid fragmentation if we can. And also applications are also diet in 6lowpan, so I am not sure the case we envision fragment problem. The fact is that in Internet today only has very very few fragments, due to the fact of MTU configuration/discovery and also TCP MSS option. I donot the case of the internet of things though. I think I am not the only lucky guy to have not witnessed any fragments:) Thanks, cz From cabo@tzi.org Mon Nov 5 11:11:45 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3607021F8A79 for ; Mon, 5 Nov 2012 11:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 34FQvAHN06ZV for ; Mon, 5 Nov 2012 11:11:44 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 0A23021F8977 for ; Mon, 5 Nov 2012 11:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qA5JBeQG019775; Mon, 5 Nov 2012 20:11:40 +0100 (CET) Received: from dhcp-9336.meeting.ietf.org (dhcp-9336.meeting.ietf.org [130.129.11.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id ACF55360; Mon, 5 Nov 2012 20:11:39 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 5 Nov 2012 14:11:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5C762071-A096-461E-AE41-3717C0712037@tzi.org> References: To: "Cao Zhen (cz)" X-Mailer: Apple Mail (2.1499) Cc: int-area@ietf.org Subject: Re: [Int-area] Comments to ALFI X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:11:45 -0000 On Nov 5, 2012, at 13:56, "Cao Zhen (cz)" wrote: > Hi Carsten, >=20 > The problem you describe is cool. But in Lwig guidance document, I > remember there is a guidance saying we should avoid fragmentation if > we can. Yes, but how do you do that if you don't know the fragment size? Right now, you can only guess, and you'll likely try to guess = conservatively, missing out on the opportunity to reasonably fill the = packets. > And also applications are also diet in 6lowpan, so I am not > sure the case we envision fragment problem. Indeed, simple sensor readings/actuator settings are unlikely to trigger = fragmentation. Unfortunately, when the need for bulk data arises (firmware updates, = configuration changes), it often is needed for many nodes in the = network, which means the speed at which you can perform these operations = at scale depends on the efficiency you can get. > The fact is that in Internet today only has very very few fragments, > due to the fact of MTU configuration/discovery and also TCP MSS > option. Yes. We have ways to find out the IP MTU and therefore mostly can avoid = fragmentation if our protocols are set up for that. My problem statement is that we can't do that at the adaptation layer. We simply didn't provide a way to find out the fragment sizes for the = adaptation layer. > I think I am not the only lucky guy to have not witnessed any = fragments:) Lucky you :-) Please have a look into the 6lowpan packet repository at http://svn.tools.ietf.org/svn/wg/6lowpan/packets/ if you want to see 6LoWPAN fragmentation in action... Gr=FC=DFe, Carsten From touch@isi.edu Mon Nov 5 11:34:56 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E7621F8543 for ; Mon, 5 Nov 2012 11:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.156 X-Spam-Level: X-Spam-Status: No, score=-103.156 tagged_above=-999 required=5 tests=[AWL=-1.157, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 qPjgCcLq1pUW for ; Mon, 5 Nov 2012 11:34:55 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2C77421F8863 for ; Mon, 5 Nov 2012 11:34:55 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id qA5JYL3d027446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Nov 2012 11:34:21 -0800 (PST) Message-ID: <509814BD.4070409@isi.edu> Date: Mon, 05 Nov 2012 11:34:21 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Cao Zhen (cz)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org Subject: Re: [Int-area] Comments to ALFI X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:34:56 -0000 Hi, all, On 11/5/2012 10:56 AM, Cao Zhen (cz) wrote: > Hi Carsten, > > The problem you describe is cool. Can someone summarize that to the list? I don't think I saw it. There have been a lot of recent discussion on v6ops about fragmentation as well, notably on a recommendation they are considering to "drop all fragments" due to the overhead of processing any IPv6 options. I claim: a) if processing is an issue, then they could ask to recommend "drop IPv6 with any options", but dropping only fragments could easily require more extensive chained-header processing for routers b) dropping all options isn't viable Others have claimed that it's reasonable for a port filter device to drop all fragments and send back PTB messages. Here are my concerns with that approach: - PTB messages themselves are already filtered by the same kind of operators who insist on routers doing port filtering - sending PTB to a host that has fragmented might not help; if it could/wanted to adjust the TCP or UDP segment size, it would already have done so. since IPv6 fragmentation happens at the source, the likely result is just a lot of smaller fragments (which isn't useful) I am now considering whether a port filter device may need to reassemble IPv6 fragments. IMO, if such a device isn't in a network location where such reassembly is reasonable (i.e., on behalf of a host whose entire traffic it controls), then port filtering there isn't reasonable anyway. Yes, such reassembly might be considered to violate RFC 2460, but so does "drop all fragments" or "drop any options". Arguably any device that checks port numbers is acting either as the destination or a proxy for the destination anyway. > But in Lwig guidance document, I > remember there is a guidance saying we should avoid fragmentation if > we can. That's advisable anywhere, and already in RFC 2460. > The fact is that in Internet today only has very very few fragments, > due to the fact of MTU configuration/discovery and also TCP MSS > option. I donot the case of the internet of things though. I'm not sure we're seeing the whole situation; fragments happen over tunnels too, many of which are secure and we might not be able to notice. Joe From rafiee@hpi.uni-potsdam.de Mon Nov 5 11:42:38 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] Answer to one of comments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing 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 cabo@tzi.org Mon Nov 5 11:48:45 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31E021F8620 for ; Mon, 5 Nov 2012 11:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 VZ518GKjyI5o for ; Mon, 5 Nov 2012 11:48:40 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A1A8B21F8A35 for ; Mon, 5 Nov 2012 11:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qA5JmHju004303; Mon, 5 Nov 2012 20:48:17 +0100 (CET) Received: from dhcp-9336.meeting.ietf.org (dhcp-9336.meeting.ietf.org [130.129.11.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4868838A; Mon, 5 Nov 2012 20:48:16 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <509814BD.4070409@isi.edu> Date: Mon, 5 Nov 2012 14:48:06 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <05757E74-77CB-4B3D-88BC-5F5EE3B6BFBA@tzi.org> References: <509814BD.4070409@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1499) Cc: int-area@ietf.org Subject: Re: [Int-area] Comments to ALFI X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 19:48:45 -0000 On Nov 5, 2012, at 14:34, Joe Touch wrote: > Can someone summarize that to the list? I don't think I saw it. The segment in intarea today was about adaptation layer fragmentation = indication, draft-bormann-intarea-alfi-01.txt That is fragmentation that is harder to avoid, as it happens = "transparently" below IP in an adaptation layer for a specific link = layer. I was arguing for providing a "looking glass" into what is happening = down there, so transport or application layer protocols can choose = packet sizes intelligently. The specific solution I was proposing was = mainly a strawman to show how it could be made to work in principle -- = the hop-by-hop option I used may be not very useful in the general = Internet. Gr=FC=DFe, Carsten From zehn.cao@gmail.com Mon Nov 5 12:28:23 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07FA21F879A for ; Mon, 5 Nov 2012 12:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz04gC0sGjGZ for ; Mon, 5 Nov 2012 12:28:22 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1173521F8413 for ; Mon, 5 Nov 2012 12:28:10 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so9760361iec.31 for ; Mon, 05 Nov 2012 12:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uRt3X+zKwQZDGyArgCnXsZZ7ddSnarlYmhnDx0/zZjQ=; b=mxfdFV7Sce7qWLAPMAUV0ns1Pm6tTvWcVbsi+F+SeXEdWjNUPeP1+A15la/mdownz1 sloI0S5GyZouz8Rr456PX9oHbiR4rwwK4Mjpr9PlLHHlX1c+fI5a0WmMN0auIrxbEf1J jlNdifzde910MW0d4x4uD/hJza0dZ14AggO/GSSSSTezPMQaumE2Yxxx2W9go6eJe9M7 dMp5LD07tL8SMoHO7ET7Qbj8J3hVrHfFyWcwxoQjWAhXpBsauv7kaaRFNvEKd4LXMeMu gR5qCpatVpu+AHdbPtTLQPHbF40USLOg9u5PqPHUwGWydKRZpzS++r4MGkVOBqVVrNwQ ReXQ== MIME-Version: 1.0 Received: by 10.50.179.36 with SMTP id dd4mr10662157igc.64.1352147289537; Mon, 05 Nov 2012 12:28:09 -0800 (PST) Received: by 10.64.28.9 with HTTP; Mon, 5 Nov 2012 12:28:09 -0800 (PST) In-Reply-To: <5C762071-A096-461E-AE41-3717C0712037@tzi.org> References: <5C762071-A096-461E-AE41-3717C0712037@tzi.org> Date: Mon, 5 Nov 2012 15:28:09 -0500 Message-ID: From: "Cao,Zhen (cz)" To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: int-area@ietf.org Subject: Re: [Int-area] Comments to ALFI X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 20:28:23 -0000 On Mon, Nov 5, 2012 at 2:11 PM, Carsten Bormann wrote: > On Nov 5, 2012, at 13:56, "Cao Zhen (cz)" wrote: > >> Hi Carsten, >> >> The problem you describe is cool. But in Lwig guidance document, I >> remember there is a guidance saying we should avoid fragmentation if >> we can. > > Yes, but how do you do that if you don't know the fragment size? > Right now, you can only guess, and you'll likely try to guess conservatively, missing out on the opportunity to reasonably fill the packets. Only 6lowpan adaption is here in IETF, the MTU is 127 bytes, isn't it? From cabo@tzi.org Mon Nov 5 13:49:27 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DDA21F881E for ; Mon, 5 Nov 2012 13:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 jCor3ul8W2J9 for ; Mon, 5 Nov 2012 13:49:26 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 38BD721F8808 for ; Mon, 5 Nov 2012 13:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id qA5LnI2T026958; Mon, 5 Nov 2012 22:49:18 +0100 (CET) Received: from dhcp-9336.meeting.ietf.org (dhcp-9336.meeting.ietf.org [130.129.11.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EEAA5410; Mon, 5 Nov 2012 22:49:17 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 5 Nov 2012 16:49:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C762071-A096-461E-AE41-3717C0712037@tzi.org> To: "Cao,Zhen (cz)" X-Mailer: Apple Mail (2.1499) Cc: int-area@ietf.org Subject: Re: [Int-area] Comments to ALFI X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 21:49:27 -0000 On Nov 5, 2012, at 15:28, "Cao,Zhen (cz)" wrote: > On Mon, Nov 5, 2012 at 2:11 PM, Carsten Bormann wrote: >> On Nov 5, 2012, at 13:56, "Cao Zhen (cz)" wrote: >>=20 >>> Hi Carsten, >>>=20 >>> The problem you describe is cool. But in Lwig guidance document, I >>> remember there is a guidance saying we should avoid fragmentation if >>> we can. >>=20 >> Yes, but how do you do that if you don't know the fragment size? >> Right now, you can only guess, and you'll likely try to guess = conservatively, missing out on the opportunity to reasonably fill the = packets. >=20 > Only 6lowpan adaption is here in IETF, the MTU is 127 bytes, isn't it? That is the physical layer MTU. The specific combination of MAC layer overheads, adaptation layer = overheads, and header compression gains can turn the actual initial = fragment size number into anything roughly between 70 and 160 bytes. = Note that this is more than a factor of two. Gr=FC=DFe, Carsten From rafiee@hpi.uni-potsdam.de Mon Nov 5 16:23:51 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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 Subject: [Int-area] Please send me your comments (CGA-TSIG) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing 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 zehn.cao@gmail.com Tue Nov 6 06:28:09 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8792B21F843B for ; Tue, 6 Nov 2012 06:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abIhSikTtnr1 for ; Tue, 6 Nov 2012 06:28:09 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0222B21F8860 for ; Tue, 6 Nov 2012 06:28:08 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id x24so368217iak.31 for ; Tue, 06 Nov 2012 06:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OtD2+kdNoEQ5q2qKXFruTv0WSRZtRRAHKWHwXL7P69E=; b=I+tr9VgRyQzEMC/VkNoFReFP8rjt1eMPrk2krVhMa2S+hAKZMV32mMTPn/eW67izfv qJEv752rROXaCSwJFtgGS8giMuMCJeGrh4RAKqrXUJxXLiudPvBaY54Rg+h5ybkR/WQj h61VjikSp93JvxPO5hh2LunRS1tWzU8f2ZhiWM+j+QmfhW4jPKeOW5NoARfJZFQCjm1i ZXwf3sFnTXH7tgQGUAJPZfVCIVS81NcidOuJEwBfNKJvuMTltAYjet3RNJ0X3538Q4yj 7I/u2CQk7ksuoe4oakJ06GWELaVCeIhKydUbZ/BeJNFCL9T4Hys11IgcB+0+HtzFQTOG AQ/w== MIME-Version: 1.0 Received: by 10.50.179.36 with SMTP id dd4mr1102863igc.64.1352212088646; Tue, 06 Nov 2012 06:28:08 -0800 (PST) Received: by 10.64.28.9 with HTTP; Tue, 6 Nov 2012 06:28:08 -0800 (PST) In-Reply-To: References: <5C762071-A096-461E-AE41-3717C0712037@tzi.org> Date: Tue, 6 Nov 2012 09:28:08 -0500 Message-ID: From: "Cao,Zhen (cz)" To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: int-area@ietf.org Subject: Re: [Int-area] Comments to ALFI X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:28:09 -0000 On Mon, Nov 5, 2012 at 4:49 PM, Carsten Bormann wrote: >>> Yes, but how do you do that if you don't know the fragment size? >>> Right now, you can only guess, and you'll likely try to guess conservat= ively, missing out on the opportunity to reasonably fill the packets. >> >> Only 6lowpan adaption is here in IETF, the MTU is 127 bytes, isn't it? > > That is the physical layer MTU. > > The specific combination of MAC layer overheads, adaptation layer overhea= ds, and header compression gains can turn the actual initial fragment size = number into anything roughly between 70 and 160 bytes. Note that this is m= ore than a factor of two. > This worth stating in the draft though:) regards, cz > Gr=FC=DFe, Carsten > From dan-ietf@danyork.org Tue Nov 6 11:13:38 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E721F8522 for ; Tue, 6 Nov 2012 11:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] 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 y0btDbZtkKrr for ; Tue, 6 Nov 2012 11:13:37 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA2921F84E3 for ; Tue, 6 Nov 2012 11:13:37 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so1308991iec.31 for ; Tue, 06 Nov 2012 11:13:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version :x-mailer:x-gm-message-state; bh=JJqvZTsloHmm0h1BTkryWpdclclsx4HJgswnCCX5zjU=; b=DWEpAK7zHOVxKVcbmlH/JvkQ0hCpExyFbOFIr/KOPspFspV1vHk1ypA1PaHftOavA3 +/UtfYAdSHzvGQyLo7mXW7bIJymPrrGP+MhKSYElyhiJsKIlDgasWgTHTRkZjUfV9hwa CYo4pKsDDhKpnX3YY604qJNVRWdThuUZvIlw0uHPDAPu7PyVqrAIa/uyUDeHOxkuHdjC 0b0H/RHQVBKnszDZB4Bj6KwBGIWObO5YjXXnsw8bCdBrKYylNu9MYMnW3AhQpT4tNEPw e6yAmyOg4K+8nnU/NX/cVvSMRiMSSrNCB4j5EwAHS/J/q//8G8EIlgMR/fKcOwcbJVkI IAkA== Received: by 10.50.34.225 with SMTP id c1mr10155150igj.67.1352229216666; Tue, 06 Nov 2012 11:13:36 -0800 (PST) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id pq3sm37353igc.8.2012.11.06.11.13.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 11:13:36 -0800 (PST) From: Dan York Content-Type: multipart/alternative; boundary="Apple-Mail=_3408840B-5F87-4381-AFD1-69C988E7CAFA" Date: Tue, 6 Nov 2012 14:13:33 -0500 Message-Id: <7DDD4BE3-F5EE-42B0-9FB8-C81A26E3E222@danyork.org> To: rafiee@hpi.uni-potsdam.de Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlN3ksz9R+V7YSfp3r2wQpGm02rfUL9DzUUQ+7WWIZJOMrd+0aImLvkfxBPSRxMb7scHF/g Cc: int-area@ietf.org Subject: Re: [Int-area] Please send me your comments (CGA-TSIG) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 19:13:38 -0000 --Apple-Mail=_3408840B-5F87-4381-AFD1-69C988E7CAFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hosnieh, > 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. Two suggestions/comments to you: 1. I would suggest that you add a section titled something like "Problem = Statement" at the beginning after the Introduction and Conventions = sections and before the "Algorithm Overview" that explains in more = detail the problem you are trying to solve. You have a bit of this in = the Introduction and more in the "Security Considerations" section at = the end, but I would suggest bringing it all together in a section that = explains why people would use your proposal. You might want to have = several sub-sections that enumerate different use cases (as you have = done in the current Security Considerations section) and explain how = CGA-TSIG would address those solutions. You might also want to briefly = note in here situations that are NOT solved by CGA-TSIG. It seemed to me from listening to the IETF85 discussion that this point = of what problem precisely you are trying to solve was hard for a number = of people (myself included) to easily understand. 2. The section currently titled "Security Considerations" seems to = actually be some of the potential use cases for CGA-TSIG. In my view, = this section should really be about security considerations *related to* = your CGA-TSIG proposal. I would suggest moving these use cases to the = new section I suggest you create in my earlier point. =20 I would then suggest outlining in this Security Considerations section = points such as: - how can CGA-TSIG be attacked? - can CGA-TSIG be spoofed? - are there other network considerations that need to be in place for = CGA-TSIG to be secure?=20 - do the use of these addresses provide any added privacy benefits? I'm just making these questions up, but you get the idea.... if you = think like an attacker, how can he or she break CGA-TSIG or potentially = use it for nefarious purposes? Regards, Dan --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_3408840B-5F87-4381-AFD1-69C988E7CAFA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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.

Two suggestions/comments to = you:

1. I would suggest that you add a section = titled something like "Problem Statement" at the beginning after the = Introduction and Conventions sections and before the "Algorithm = Overview" that explains in more detail the problem you are trying to = solve.   You have a bit of this in the Introduction and more in the = "Security Considerations" section at the end, but I would suggest = bringing it all together in a section that explains why people would use = your proposal. You might want to have several sub-sections that = enumerate different use cases (as you have done in the current Security = Considerations section) and explain how CGA-TSIG would address those = solutions.  You might also want to briefly note in here situations = that are NOT solved by CGA-TSIG.

It seemed to = me from listening to the IETF85 discussion that this point of what = problem precisely you are trying to solve was hard for a number of = people (myself included) to easily = understand.

2. The section currently titled = "Security Considerations" seems to actually be some of the potential use = cases for CGA-TSIG.  In my view, this section should really be = about security considerations *related to* your CGA-TSIG proposal. =  I would suggest moving these use cases to the new section I = suggest you create in my earlier point. =  

I would then suggest outlining in this = Security Considerations section points such = as:

- how can CGA-TSIG be attacked?
- = can CGA-TSIG be spoofed?
- are there other network = considerations that need to be in place for CGA-TSIG to be = secure? 
- do the use of these addresses provide any = added privacy benefits?

I'm just making these = questions up, but you get the idea.... if you think like an attacker, = how can he or she break CGA-TSIG or potentially use it for nefarious = purposes?

Regards,
Dan

dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork



= --Apple-Mail=_3408840B-5F87-4381-AFD1-69C988E7CAFA-- From rafiee@hpi.uni-potsdam.de Tue Nov 6 17:04:20 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3428421F8A60 for ; Tue, 6 Nov 2012 17:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6] 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 rnoMo3NUf8Yp for ; Tue, 6 Nov 2012 17:04:19 -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 C066F21F8A14 for ; Tue, 6 Nov 2012 17:04:18 -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 C05A2169E76; Wed, 7 Nov 2012 02:04:14 +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 02:04:14 +0100 From: "Rafiee, Hosnieh" To: Dan York Date: Wed, 7 Nov 2012 02:04:11 +0100 Thread-Topic: Please send me your comments (CGA-TSIG) Thread-Index: Ac28UtPWtzw5Re6rR1W6BQiJOvwMjAALbwyw Message-ID: References: <7DDD4BE3-F5EE-42B0-9FB8-C81A26E3E222@danyork.org> In-Reply-To: <7DDD4BE3-F5EE-42B0-9FB8-C81A26E3E222@danyork.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: multipart/alternative; boundary="_000_EA738325B0580041A50A364F5F76B68924D4465C168MXMA1Rhpiuni_" MIME-Version: 1.0 Cc: "Int-area@ietf.org" Subject: Re: [Int-area] Please send me your comments (CGA-TSIG) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 01:04:20 -0000 --_000_EA738325B0580041A50A364F5F76B68924D4465C168MXMA1Rhpiuni_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Dan, Thanks alot for your suggestions. I am working on a new draft version which= will include your suggestions I will hopefully submit it after the IETF is opened again for submissions. For the attacks, as I am finalizing now the PowerDNS CGA-TSIG, I will test = all known attacks againstn this implementation and publish the list of atta= cks that it can prevent and the possible attcaks that it cannot prevent. Thank you, Hosnieh From: Dan York [mailto:dan-ietf@danyork.org] Sent: Tuesday, November 06, 2012 8:14 PM To: Rafiee, Hosnieh Cc: int-area@ietf.org Subject: Re: Please send me your comments (CGA-TSIG) Hosnieh, 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. Two suggestions/comments to you: 1. I would suggest that you add a section titled something like "Problem St= atement" at the beginning after the Introduction and Conventions sections a= nd before the "Algorithm Overview" that explains in more detail the problem= you are trying to solve. You have a bit of this in the Introduction and = more in the "Security Considerations" section at the end, but I would sugge= st bringing it all together in a section that explains why people would use= your proposal. You might want to have several sub-sections that enumerate = different use cases (as you have done in the current Security Consideration= s section) and explain how CGA-TSIG would address those solutions. You mig= ht also want to briefly note in here situations that are NOT solved by CGA-= TSIG. It seemed to me from listening to the IETF85 discussion that this point of = what problem precisely you are trying to solve was hard for a number of peo= ple (myself included) to easily understand. 2. The section currently titled "Security Considerations" seems to actually= be some of the potential use cases for CGA-TSIG. In my view, this section= should really be about security considerations *related to* your CGA-TSIG = proposal. I would suggest moving these use cases to the new section I sugg= est you create in my earlier point. I would then suggest outlining in this Security Considerations section poin= ts such as: - how can CGA-TSIG be attacked? - can CGA-TSIG be spoofed? - are there other network considerations that need to be in place for CGA-T= SIG to be secure? - do the use of these addresses provide any added privacy benefits? I'm just making these questions up, but you get the idea.... if you think l= ike an attacker, how can he or she break CGA-TSIG or potentially use it for= nefarious purposes? Regards, Dan -- Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --_000_EA738325B0580041A50A364F5F76B68924D4465C168MXMA1Rhpiuni_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&nbs= p;

Dear Dan,

 

Thanks alot for your suggestions. I am working on a new dr= aft version which will include your suggestions I will hopefully submit it = after the

IETF is opened = again for submissions.

Fo= r the attacks, as I am finalizing now the PowerDNS CGA-TSIG, I will test al= l known attacks againstn this implementation and publish the list of attack= s that it can prevent and the possible attcaks that it cannot prevent.

 

<= p class=3DMsoNormal>Thank you,

Hosnieh

 

From:= Dan Yor= k [mailto:dan-ietf@danyork.org]
Sent: Tuesday, November 06, 2012= 8:14 PM
To: Rafiee, Hosnieh
Cc: int-area@ietf.org
<= b>Subject: Re: Please send me your comments (CGA-TSIG)

 

Hosnieh,

 = ;

Would you please send me your comments on our draft (= presentation today) to my email address, so that I can review them and prov= ide you with answers.

=  

Two suggestions/commen= ts to you:

 <= /p>

1. I would suggest that you add a sectio= n titled something like "Problem Statement" at the beginning afte= r the Introduction and Conventions sections and before the "Algorithm = Overview" that explains in more detail the problem you are trying to s= olve.   You have a bit of this in the Introduction and more in the &qu= ot;Security Considerations" section at the end, but I would suggest br= inging it all together in a section that explains why people would use your= proposal. You might want to have several sub-sections that enumerate diffe= rent use cases (as you have done in the current Security Considerations sec= tion) and explain how CGA-TSIG would address those solutions.  You mig= ht also want to briefly note in here situations that are NOT solved by CGA-= TSIG.

 

It seemed to me from listening to the IETF85 = discussion that this point of what problem precisely you are trying to solv= e was hard for a number of people (myself included) to easily understand.

 

2. The section currently titled "Security Consi= derations" seems to actually be some of the potential use cases for CG= A-TSIG.  In my view, this section should really be about security cons= iderations *related to* your CGA-TSIG proposal.  I would suggest movin= g these use cases to the new section I suggest you create in my earlier poi= nt.  

 <= /p>

I would then suggest outlining in this S= ecurity Considerations section points such as:

 

- ho= w can CGA-TSIG be attacked?

-= can CGA-TSIG be spoofed?

- a= re there other network considerations that need to be in place for CGA-TSIG= to be secure? 

- do the= use of these addresses provide any added privacy benefits?

<= /div>

 

I'm just making these questions up, but you get the idea.... if yo= u think like an attacker, how can he or she break CGA-TSIG or potentially u= se it for nefarious purposes?

 

Regards,

Dan

 

-- 
Dan York  dyork@lo= destar2.com
http://www.danyork.m= e/   skype:danyork
Phon= e: +1-802-735-1624
Twitter - http://twitter.com/danyork

 

&= nbsp;

 

= = --_000_EA738325B0580041A50A364F5F76B68924D4465C168MXMA1Rhpiuni_-- From rafiee@hpi.uni-potsdam.de Wed Nov 7 07:28:11 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] (CGA-TSIG) answers to some of the comments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing 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 07:47:05 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B1221F8AE7 for ; Thu, 8 Nov 2012 07:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.193 X-Spam-Level: X-Spam-Status: No, score=-2.193 tagged_above=-999 required=5 tests=[AWL=0.055, 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 sxqSTK7GPoHq for ; Thu, 8 Nov 2012 07:46:59 -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 290EC21F8A78 for ; Thu, 8 Nov 2012 07:46:59 -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 A561A169E98 for ; Thu, 8 Nov 2012 16:46:57 +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 16:46:57 +0100 From: "Rafiee, Hosnieh" To: "Int-area@ietf.org" Date: Thu, 8 Nov 2012 16:46:53 +0100 Thread-Topic: (CGA-TSIG) answers to some of the comments Thread-Index: Ac29yEYqVJYyeIhqTq6Ghw06XYn5dg== 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_EA738325B0580041A50A364F5F76B68924D4465D098MXMA1Rhpiuni_" MIME-Version: 1.0 Subject: Re: [Int-area] (CGA-TSIG) answers to some of the comments X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 15:47:05 -0000 --_000_EA738325B0580041A50A364F5F76B68924D4465D098MXMA1Rhpiuni_ 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_EA738325B0580041A50A364F5F76B68924D4465D098MXMA1Rhpiuni_ 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_EA738325B0580041A50A364F5F76B68924D4465D098MXMA1Rhpiuni_-- From ietf@meetecho.com Fri Nov 9 09:06:07 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD0921F8785 for ; Fri, 9 Nov 2012 09:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 UuRiiWVu8OBb for ; Fri, 9 Nov 2012 09:06:07 -0800 (PST) Received: from smtpdg9.aruba.it (smtpdg9.aruba.it [62.149.158.239]) by ietfa.amsl.com (Postfix) with ESMTP id A3AFC21F876F for ; Fri, 9 Nov 2012 09:06:06 -0800 (PST) Received: from [130.129.19.11] ([130.129.19.11]) by smtpcmd03.ad.aruba.it with bizsmtp id MV641k00b0ELJoa01V65Er; Fri, 09 Nov 2012 18:06:05 +0100 Message-ID: <509D37FA.7050603@meetecho.com> Date: Fri, 09 Nov 2012 18:06:02 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "int-area@ietf.org" Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] Meetecho session recording X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:06:07 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of this WG session at IETF-85 is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf85/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From brian@innovationslab.net Mon Nov 12 07:51:25 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB52721F8612 for ; Mon, 12 Nov 2012 07:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WN9Lz6F5STY for ; Mon, 12 Nov 2012 07:51:24 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id BFD7121F85C2 for ; Mon, 12 Nov 2012 07:51:23 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 640AE880BB for ; Mon, 12 Nov 2012 07:51:23 -0800 (PST) Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 27F4E13680BA for ; Mon, 12 Nov 2012 07:51:23 -0800 (PST) Message-ID: <50A11B04.90107@innovationslab.net> Date: Mon, 12 Nov 2012 10:51:32 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: int-area@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Int-area] WG Summaries for IETF 85 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:51:25 -0000 All, I have begun receiving summaries for the Atlanta IETF meeting. They are available at : http://trac.tools.ietf.org/area/int/trac/wiki/IETF85 Summaries will continue to be added to that page as they are received. Any feedback, comments, or questions on these summaries are welcome. Regards, Brian From linda.dunbar@huawei.com Mon Nov 12 13:50:18 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B98321F844D for ; Mon, 12 Nov 2012 13:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 OWVZQb7N4SaE for ; Mon, 12 Nov 2012 13:50:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8310B21F8452 for ; Mon, 12 Nov 2012 13:50:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALL71998; Mon, 12 Nov 2012 21:50:15 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 21:50:08 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 21:50:14 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Mon, 12 Nov 2012 13:50:11 -0800 From: Linda Dunbar To: "int-area@ietf.org" , "christopher.liljenstolpe@bigswitch.com" Thread-Topic: can you elaborate the "loops" which you are concerned with "draft-nachum-sarp-03"? Thread-Index: Ac3BH7g9Yq+PtdAcQXGTC3WEguhIWg== Date: Mon, 12 Nov 2012 21:50:11 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6450951A5@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.95] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6450951A5dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Int-area] can you elaborate the "loops" which you are concerned with "draft-nachum-sarp-03"? X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:50:18 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F6450951A5dfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chris, I am a little confused of the "loops" you stated at the microphone about t= he scheme described in "draft-nachum-sarp-03" at the InterArea WG session i= n Atlanta. The draft assumes that there is some type of loop prevention mechanism in p= lace (be it RSTP/STP, SPB-M, TRILL, or IS-IS) to prevent loops for Ethernet= data frames which don't have TTL. The same mechanism should prevent the loops of ARP/ND frames. Can you draw a scenario on how/why the loop prevention mechanism for Ethern= et data frames won't work for ARP/ND frames? Thank you very much. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F6450951A5dfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chris,

 

I am a little confused of the “loops” &n= bsp;you stated at the microphone about the scheme described in “draft= -nachum-sarp-03” at the InterArea WG session in Atlanta.

 

The draft assumes that there is some type of loop pr= evention mechanism in place (be it RSTP/STP, SPB-M, TRILL, or IS-IS) to pre= vent loops for Ethernet data frames which don’t have TTL.

 

The same mechanism should prevent the loops of ARP/N= D frames.  

 

Can you draw a scenario on how/why the loop preventi= on mechanism for Ethernet data frames won’t work for ARP/ND frames? &= nbsp;

 

 

Thank you very much.

 

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F6450951A5dfweml505mbx_-- From linda.dunbar@huawei.com Mon Nov 12 14:36:19 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D6021F87CF for ; Mon, 12 Nov 2012 14:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 0CFU3fW2CqJP for ; Mon, 12 Nov 2012 14:36:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E3B1721F87CB for ; Mon, 12 Nov 2012 14:36:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMR66943; Mon, 12 Nov 2012 22:36:16 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 22:36:06 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Nov 2012 22:36:13 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Mon, 12 Nov 2012 14:36:07 -0800 From: Linda Dunbar To: "int-area@ietf.org" , "suresh.krishnan@ericsson.com" , "julien.ietf@gmail.com" Thread-Topic: IPv6 ND applicability in draft-nachum-sarp-03 Thread-Index: Ac3BJiJbrs+Mg7erTp6yFDNDBTG1Hw== Date: Mon, 12 Nov 2012 22:36:05 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.95] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6450951DEdfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:36:19 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F6450951DEdfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Suresh and Julien, When the "draft-nachum-sarp-02" was presented at InterArea WG in 84th IETF,= the feedback was that the draft needs to be updated to include the process= ing for IPv6. So we updated the draft to include the processing of ND for IPv6. When the revised draft (draft-nachum-sarp-03) was presented at the InterAre= a WG in 85th IETF, there are several people saying there is no problems for= IPv6 ND, therefore it shouldn't be optimized. Even though that IPv6 ND uses multicast instead broadcast, IPv6 ND does hav= e scalability issues in Data Center when hosts within same subnet are sprea= d across different access switches, and when there are lot of those subnets= . In particular: * when hosts within the same subnet are spread across multiple switc= hes (or GWs in the draft), the ND solicitation still go to all switches whi= ch might have the same subnet hosts attached. The traffic across GWs are sa= me as IPv4's ARP. The only difference is that hosts impact is reduced. * When host "a" needs to communicate with host "b" in different subn= et, "a" needs to send "Neighbor Solicitation" to L2/L3 boundary router, (ju= st the same way as IPv4 ARP). When there are many subnets spreading across many access switches, the L2/L= 3 boundary router has to enable all those subnets on many of its ports/link= s. When the first "a"-> "b" data frame arrives at the boundary router, the bou= ndary router has to "hold the data frame" and send a "Neighbor Solicitation= " to all links which has the subnet for "b" enabled. The boundary router ma= y need to send "NS" multiple times until it can make sure the target "b" ex= ists before sending down the data frame from "a". This process is not only = CPU intensive, but also takes buffer. We need your advice on how to move this draft forward. Thank you very much. Linda --_000_4A95BA014132FF49AE685FAB4B9F17F6450951DEdfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Suresh and Julien,

 

When the “draft-nachum-sarp-02” was pres= ented at InterArea WG in 84th IETF, the feedback was that the dr= aft needs to be updated to include the processing for IPv6.

 

So we updated the draft to include the processing of= ND for IPv6.

 

When the revised draft (draft-nachum-sarp-03) was pr= esented at the InterArea WG in 85th IETF, there are several peop= le saying there is no problems for IPv6 ND, therefore it shouldn’t be= optimized.

 

Even though that IPv6 ND uses multicast instead broa= dcast, IPv6 ND does have scalability issues in Data Center when hosts withi= n same subnet are spread across different access switches, and when there a= re lot of those subnets. In particular:

·        when hosts within the same subnet are spread= across multiple switches (or GWs in the draft), the ND solicitation still = go to all switches which might have the same subnet hosts attached. The tra= ffic across GWs are same as IPv4’s ARP.  The only difference is that hosts impact is reduced.

 

·        When host “a” needs to communica= te with host “b” in different subnet, “a” needs to = send “Neighbor Solicitation” to L2/L3 boundary router, (just th= e same way as IPv4 ARP).

When there are many subne= ts spreading across many access switches, the L2/L3 boundary router has to = enable all those subnets on many of its ports/links.

 

When the first “a&#= 8221;-> “b” data frame arrives at the boundary router, the b= oundary router has to “hold the data frame” and send a “N= eighbor Solicitation” to all links which has the subnet for “b&= #8221; enabled. The boundary router may need to send “NS” multiple times until it can make = sure the target “b” exists before sending down the data frame f= rom “a”. This process is not only CPU intensive, but also takes= buffer.

 

 

We need your advice on how to move this draft forwar= d.

 

Thank you very much.

 

Linda

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F6450951DEdfweml505mbx_-- From J.Renouard@F5.com Tue Nov 13 13:00:48 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E0D21F8527 for ; Tue, 13 Nov 2012 13:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTBQ1hrVAhce for ; Tue, 13 Nov 2012 13:00:46 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id E38A621F8525 for ; Tue, 13 Nov 2012 13:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=J.Renouard@f5.com; q=dns/txt; s=seattle; t=1352840446; x=1384376446; h=from:to:subject:date:message-id:mime-version; bh=q2cemSaOM8LMZktVTmFfMcFBPfjkz+Db5qu/93er+hs=; b=yz8EbBr4LY1KIT9CT03gJPGjzOk+lg/ueT3eLuOpM6hsCXuXE4PhZC2w 7WdsvnOU37aNTd01OxuaVF72yuFccWWIDoWXDjJMc3eH6nOkXbzRS94Ad hwfDb3zxwyI7rMo1+zCvpW5OkNQali8R2Lh9bHwU5Hu6K2RvOwMmOFbDk 8=; X-IronPort-AV: E=Sophos;i="4.83,768,1352073600"; d="scan'208,217";a="56409180" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.240]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 13 Nov 2012 21:00:43 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.02.0283.003; Tue, 13 Nov 2012 13:00:42 -0800 From: Julia Renouard To: "brian.e.carpenter@gmail.com" , "int-area@ietf.org" , "draft-carpenter-flow-label-balancing@tools.ietf.org" Thread-Topic: Feedback for draft-carpenter-flow-label-balancing-01 Thread-Index: Ac3Bw9y0Wk77Lld0QB6uFi6vfAsD/Q== Date: Tue, 13 Nov 2012 21:00:42 +0000 Message-ID: <04B0EA2BFC1C91479AD86F776659AE7530B0776B@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.200] Content-Type: multipart/alternative; boundary="_000_04B0EA2BFC1C91479AD86F776659AE7530B0776BSEAEMBX01olympu_" MIME-Version: 1.0 Subject: [Int-area] Feedback for draft-carpenter-flow-label-balancing-01 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 21:00:48 -0000 --_000_04B0EA2BFC1C91479AD86F776659AE7530B0776BSEAEMBX01olympu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Way overdue promised feedback for draft-carpenter-flow-label-balancing-01 -= from IETF '84. Here are some broader thoughts: The biggest limitation in implementing this, as a vendor, is understanding = a) how widely adopted the flow label is currently and b) the actual entropy= we're seeing in the wild. If you have any data on adoption or samplings o= f v6 packet headers that might demonstrate it is in use, this would be usef= ul information to include. Do we know if off the shelf stacks are implemen= ting this now? Or implementing it correctly? "Correct" usage would also = be a concern. Since this is not a part of the compliance and certification= tests and 6437 is a newer RFC, I would have concerns about the correct usa= ge of this field. Another implementation assumption that may or may not affect its usefulness= is the guarantee that the flow label is not changed. There is concern tha= t intermediate nodes - perhaps full proxies or FW's might indeed be rewriti= ng or using the flow label for other purposes. Despite the admonition, som= e might read it as only applying to stateless forwarding nodes. Any of th= ese cases would break the LB's flow assumptions and break that flow essenti= ally. Something that might be interesting to address is any possible heuri= stics to detect this condition and "fall back" to standard flow association= algorithms. Specific notes and feedback: Should you might want to reference RFC 6294. I guess it doesn't say much a= bout LB but seems a gap in any case. Section 4: "Note that balancers usually do not need to consider the destination address as it is always the same, i.e., the server address." Well, this is not entirely true. LB's can be servicing different types of = servers or pools of servers or services behind the LB. If this is a core a= ssumption behind the rest of the document or section, you may need to addre= ss this. If this is not a core assumption - in other words if the rest of = the section does not rely on this assumption, then you may not need to make= this assertion. I'd be interested in a discussion of what cases an LB may= benefit from the 3-tuple instead of just the 2-tuple. Perhaps none, but t= he assertion above leads me ask. I would pull out and address the NAT question in a separate paragraph. I'm= wondering if it is worth providing guidance to NAT designers here. I also= wouldn't be so dismissive of NAT66. While I don't disagree that currently= the use-cases are not compelling, the IPv6 use-cases are still growing and= people come up with new and interesting applications that continue to surp= rise. Summary: Is it worth pursuing? Perhaps - it is an interesting summary of ideas and = a good reminder of this field but I'm not sure if this draft brings anythin= g particularly new to the table. It simply condenses it into a given use-c= ase. Perhaps it has interop value if it also reinforces or documents curre= nt practices and the behavior required by 6437 such that we get more consis= tency in stack implementations and flow-label usage. Which area? I'm not sure. Perhaps Transport but I can't quite judge that. I hope this was helpful. My apologies for taking so long. Julia Renouard --_000_04B0EA2BFC1C91479AD86F776659AE7530B0776BSEAEMBX01olympu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Way overdue prom= ised feedback for draft-carpenter-flow-label-balancing-01 – from IETF= ’84.

 

Here are some br= oader thoughts:

The biggest limi= tation in implementing this, as a vendor, is understanding a) how widely ad= opted the flow label is currently and b) the actual entropy we're seeing in the wild.  If you have any data on adoption or sampli= ngs of v6 packet headers that might demonstrate it is in use, this would be= useful information to include.  Do we know if off the shelf stacks ar= e implementing this now?  Or implementing it correctly?   "Correct" usage would also be a concer= n.  Since this is not a part of the compliance and certification tests= and 6437 is a newer RFC, I would have concerns about the correct usage of = this field. 

 

Another implemen= tation assumption that may or may not affect its usefulness is the guarante= e that the flow label is not changed.  There is concern that intermediate nodes - perhaps full proxies or FW's might indeed be rew= riting or using the flow label for other purposes.  Despite the admoni= tion, some might read it as only applying to stateless forwarding nodes.&nb= sp;  Any of these cases would break the LB's flow assumptions and break that flow essentially.  Something that mig= ht be interesting to address is any possible heuristics to detect this cond= ition and "fall back" to standard flow association algorithms.

 

Specific notes a= nd feedback:

 

Should you might= want to reference RFC 6294.  I guess it doesn't say much about LB but= seems a gap in any case. 

  

Section 4:

  &nbs= p;   "Note that balancers usually do not need to consid= er the
      destination address as it is always the same= , i.e., the server
      address."

Well, this is no= t entirely true.  LB's can be servicing different types of servers or = pools of servers or services behind the LB.  If this is a core assumption behind the rest of the document or section, you may need to add= ress this.  If this is not a core assumption - in other words if the r= est of the section does not rely on this assumption, then you may not need = to make this assertion.  I'd be interested in a discussion of what cases an LB may benefit from the 3-tuple instead o= f just the 2-tuple.  Perhaps none, but the assertion above leads me as= k.

 

I would pull out= and address the NAT question in a separate paragraph.  I'm wondering = if it is worth providing guidance to NAT designers here.  I also wouldn't be so dismissive of NAT66.  While I don't disagree that curr= ently the use-cases are not compelling, the IPv6 use-cases are still growin= g and people come up with new and interesting applications that continue to= surprise.

 

Summary:

Is it worth purs= uing?  Perhaps - it is an interesting summary of ideas and a good remi= nder of this field but I'm not sure if this draft brings anything particularly new to the table.  It simply condenses it into a given u= se-case.  Perhaps it has interop value if it also reinforces or docume= nts current practices and the behavior required by 6437 such that we get mo= re consistency in stack implementations and flow-label usage. 

 

Which area? = ; I'm not sure.  Perhaps Transport but I can't quite judge that.<= /o:p>

 

I hope this was helpful.  My apologies for taki= ng so long.

Julia Renouard

 

--_000_04B0EA2BFC1C91479AD86F776659AE7530B0776BSEAEMBX01olympu_-- From suresh.krishnan@ericsson.com Tue Nov 13 15:28:33 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978AA21F85B8 for ; Tue, 13 Nov 2012 15:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ar7VOmNgkKUt for ; Tue, 13 Nov 2012 15:28:32 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D45B721F852D for ; Tue, 13 Nov 2012 15:28:31 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qADNYXkl025212; Tue, 13 Nov 2012 17:34:34 -0600 Received: from [142.133.194.42] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 13 Nov 2012 18:27:41 -0500 Message-ID: <50A2D76C.9080407@ericsson.com> Date: Tue, 13 Nov 2012 18:27:40 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit Cc: "julien.ietf@gmail.com" , "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 23:28:33 -0000 Hi Linda, On 11/12/2012 05:36 PM, Linda Dunbar wrote: > Suresh and Julien, > > > > When the “draft-nachum-sarp-02” was presented at InterArea WG in 84^th > IETF, the feedback was that the draft needs to be updated to include the > processing for IPv6. > > > > So we updated the draft to include the processing of ND for IPv6. > > > > When the revised draft (draft-nachum-sarp-03) was presented at the > InterArea WG in 85^th IETF, there are several people saying there is no > problems for IPv6 ND, therefore it shouldn’t be optimized. > > > > Even though that IPv6 ND uses multicast instead broadcast, IPv6 ND does > have scalability issues in Data Center when hosts within same subnet are > spread across different access switches, and when there are lot of those > subnets. In particular: > > · when hosts within the same subnet are spread across multiple > switches (or GWs in the draft), the ND solicitation still go to all > switches which might have the same subnet hosts attached. The traffic > across GWs are same as IPv4’s ARP. The only difference is that hosts > impact is reduced. This is not true. If the switches are MLD snooping then the packets will not be sent to irrelevant GWs/switches. > > > > · When host “a” needs to communicate with host “b” in different > subnet, “a” needs to send “Neighbor Solicitation” to L2/L3 boundary > router, (just the same way as IPv4 ARP). Correct. But only the router gets it. Not all the other hosts in the subnet (which is the case for ARP). > > When there are many subnets spreading across many access switches, the > L2/L3 boundary router has to enable all those subnets on many of its > ports/links. This is purely an implementation issue. I know of several router implementations where this is not the case. > > > > When the first “a”-> “b” data frame arrives at the boundary router, the > boundary router has to “hold the data frame” and send a “Neighbor > Solicitation” to all links which has the subnet for “b” enabled. The > boundary router may need to send “NS” multiple times until it can make > sure the target “b” exists before sending down the data frame from “a”. > This process is not only CPU intensive, but also takes buffer. > > > > > > We need your advice on how to move this draft forward. (Chair hat off) I personally find the IPv6 ND motivations to be lacking. I think the draft needs a better description of the ND related issues that are not stated in the armd problem statement. Thanks Suresh From linda.dunbar@huawei.com Tue Nov 13 17:43:49 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82AB21F87B8 for ; Tue, 13 Nov 2012 17:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.304 X-Spam-Level: X-Spam-Status: No, score=-6.304 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 7xTlpVxPrLet for ; Tue, 13 Nov 2012 17:43:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6B521F87AA for ; Tue, 13 Nov 2012 17:43:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMT84155; Wed, 14 Nov 2012 01:43:42 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 01:43:32 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Nov 2012 01:43:41 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Tue, 13 Nov 2012 17:43:36 -0800 From: Linda Dunbar To: Suresh Krishnan Thread-Topic: IPv6 ND applicability in draft-nachum-sarp-03 Thread-Index: Ac3BJiJbrs+Mg7erTp6yFDNDBTG1HwBE2TIAAAw+YCA= Date: Wed, 14 Nov 2012 01:43:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> <50A2D76C.9080407@ericsson.com> In-Reply-To: <50A2D76C.9080407@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.138.198] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "julien.ietf@gmail.com" , "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 01:43:49 -0000 Suresh,=20 Comments are inserted below: > -----Original Message----- > > > > Even though that IPv6 ND uses multicast instead broadcast, IPv6 ND > does > > have scalability issues in Data Center when hosts within same subnet > are > > spread across different access switches, and when there are lot of > those > > subnets. In particular: > > > > * when hosts within the same subnet are spread across multiple > > switches (or GWs in the draft), the ND solicitation still go to all > > switches which might have the same subnet hosts attached. The traffic > > across GWs are same as IPv4's ARP. The only difference is that hosts > > impact is reduced. >=20 > This is not true. If the switches are MLD snooping then the packets > will > not be sent to irrelevant GWs/switches. >=20 [Linda] For those GWs which has Hosts belonging to a particular subnet, the= multicast for the subnet will reach all those GWs.=20 > > > > > > > > * When host "a" needs to communicate with host "b" in > different > > subnet, "a" needs to send "Neighbor Solicitation" to L2/L3 boundary > > router, (just the same way as IPv4 ARP). >=20 > Correct. But only the router gets it. Not all the other hosts in the > subnet (which is the case for ARP). >=20 > > > > When there are many subnets spreading across many access switches, > the > > L2/L3 boundary router has to enable all those subnets on many of its > > ports/links. >=20 > This is purely an implementation issue. I know of several router > implementations where this is not the case. >=20 [Linda] This is the standard setting. When you have one subnet spanning ove= r 20 server racks, with each rack reaching the L2/L3 boundary router via di= fferent links, the subnet has to be enabled on all those 20 ports.=20 Why do you say it is implementation issue? Linda From brian.e.carpenter@gmail.com Wed Nov 14 01:54:23 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C23621F862D for ; Wed, 14 Nov 2012 01:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.533 X-Spam-Level: X-Spam-Status: No, score=-101.533 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, 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 GfYKpTcJSAu2 for ; Wed, 14 Nov 2012 01:54:22 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1499F21F862C for ; Wed, 14 Nov 2012 01:54:21 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id w11so94110bku.31 for ; Wed, 14 Nov 2012 01:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1L5m5GtJ0jfp98a2hWiIxqXeIf7p4nqa0kCcRviGOTI=; b=tqQ3Lnv0T7LON+vj9F6ghVwhLgqMmhm7MaqMji0CmJK1/VjXShEO6vXChn7mAkQAls y+Zej9dhy6kF403aOWy2DiS4EnMmLhRgxIzVcMIYOtw8V7QNS550e1lUozN7Z4hq1om6 WCaqMvXkAi2VZe5y6kopnLal6Rdaqi+Ndi+mKQ8LP0gLfu9d9B4yDGUIJJ3Bntfi2eRr +Vl4rn+QlT+EWph3kWc9c69baNwJvX936MGwRT8VLzQAVfHlMFLyqVscVGEsyHOzWgkY S/WZhBQT9GmHFpYFsWoSovi5GWXp20FJPXbrSn55yuPwQOzhcbw1QMm9tPYO60jywmz+ f8jQ== Received: by 10.204.150.141 with SMTP id y13mr8678205bkv.1.1352886860949; Wed, 14 Nov 2012 01:54:20 -0800 (PST) Received: from [192.168.1.65] (host-2-102-218-138.as13285.net. [2.102.218.138]) by mx.google.com with ESMTPS id gy18sm7375781bkc.4.2012.11.14.01.54.18 (version=SSLv3 cipher=OTHER); Wed, 14 Nov 2012 01:54:19 -0800 (PST) Message-ID: <50A36A52.5080904@gmail.com> Date: Wed, 14 Nov 2012 09:54:26 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Julia Renouard References: <04B0EA2BFC1C91479AD86F776659AE7530B0776B@SEAEMBX01.olympus.F5Net.com> In-Reply-To: <04B0EA2BFC1C91479AD86F776659AE7530B0776B@SEAEMBX01.olympus.F5Net.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" , draft-carpenter-flow-label-balancing@tools.ietf.org Subject: Re: [Int-area] Feedback for draft-carpenter-flow-label-balancing-01 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 09:54:23 -0000 Julia, Many thanks for the review. On 13/11/2012 21:00, Julia Renouard wrote: > Way overdue promised feedback for > draft-carpenter-flow-label-balancing-01 - from IETF '84. > > > > Here are some broader thoughts: > > The biggest limitation in implementing this, as a vendor, is > understanding a) how widely adopted the flow label is > currently Very little. That's why the idea is that the flow label should be included as part of the entropy but can only become the main component over time. It's a chicken and egg problem. > and b) the actual entropy we're seeing in the wild. As it happens I've done some work related to this as part of suggesting a hash algorithm better than the appendix of RFC 6437: https://researchspace.auckland.ac.nz/handle/2292/13240 > If you have any data on adoption or samplings of v6 packet > headers that might demonstrate it is in use, this would be > useful information to include. Do we know if off the shelf > stacks are implementing this now? Basically, no. These things take time to propagate. If load balancers are known to support it, this will help propagation. > Or implementing it > correctly? "Correct" usage would also be a concern. Since > this is not a part of the compliance and certification tests > and 6437 is a newer RFC, I would have concerns about the > correct usage of this field. You also have to consider what would be the consequences of incorrect use. (1) flow label set to zero: no impact on header entropy. (2) flow label set to a not-well-distributed value: partial improvement in header entropy. (3) flow label set inconsistently within a given flow: breakage. But this would pretty much have to be malicious. > > Another implementation assumption that may or may not affect > its usefulness is the guarantee that the flow label is not > changed. There is concern that intermediate nodes - perhaps > full proxies or FW's might indeed be rewriting or using the > flow label for other purposes. Despite the admonition, some > might read it as only applying to stateless forwarding nodes. > Any of these cases would break the LB's flow assumptions and > break that flow essentially. Something that might be > interesting to address is any possible heuristics to detect > this condition and "fall back" to standard flow association > algorithms. I agree, and that is also true for (3) above, so I think some such heuristics are needed anyway. However, that's so bound up in the design of a specific load balancer that I'm not sure what can be said in general. > > > > Specific notes and feedback: > > > > Should you might want to reference RFC 6294. I guess it > doesn't say much about LB but seems a gap in any case. As general background, sure. I find that in some ways to be the most depressing RFC I've written ;-). > > > Section 4: > > "Note that balancers usually do not need to consider the > destination address as it is always the same, i.e., the > server address." > > Well, this is not entirely true. LB's can be servicing > different types of servers or pools of servers or services > behind the LB. If this is a core assumption behind the rest > of the document or section, you may need to address this. If > this is not a core assumption - in other words if the rest of > the section does not rely on this assumption, then you may > not need to make this assertion. I'd be interested in a > discussion of what cases an LB may benefit from the 3-tuple > instead of just the 2-tuple. Perhaps none, but the assertion > above leads me ask. Yes, maybe it's just a distraction to mention this. > > > > I would pull out and address the NAT question in a separate > paragraph. I'm wondering if it is worth providing guidance > to NAT designers here. I also wouldn't be so dismissive of > NAT66. While I don't disagree that currently the use-cases > are not compelling, the IPv6 use-cases are still growing and > people come up with new and interesting applications that > continue to surprise. OK > > > > Summary: > > Is it worth pursuing? Perhaps - it is an interesting summary > of ideas and a good reminder of this field but I'm not sure > if this draft brings anything particularly new to the table. > It simply condenses it into a given use-case. Perhaps it has > interop value if it also reinforces or documents current > practices and the behavior required by 6437 such that we get > more consistency in stack implementations and flow-label > usage. > Fair enough. I think the main purpose of the document is to make people like you consider the issue - the IETF can't tell vendors what to do, after all. > > Which area? I'm not sure. Perhaps Transport but I can't > quite judge that. Yes, it's a topic whose place in the IETF is unclear. > > I hope this was helpful. My apologies for taking so long. *Very* helpful, and no apology needed. Regards Brian Carpenter > Julia Renouard > > From jshire@hyduke.com Fri Nov 16 14:01:10 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8524121F8B0D for ; Fri, 16 Nov 2012 14:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 HtgGkTKIan8B for ; Fri, 16 Nov 2012 14:01:10 -0800 (PST) Received: from mail.hyduke.net (mail.hyduke.net [67.226.164.185]) by ietfa.amsl.com (Postfix) with ESMTP id D91EF21F8A31 for ; Fri, 16 Nov 2012 14:01:06 -0800 (PST) Received: from nsk1mx01.hyduke.net (192.168.9.68) by nsk1mx02.hyduke.net (192.168.10.49) with Microsoft SMTP Server id 8.1.436.0; Fri, 16 Nov 2012 15:00:54 -0700 Received: from nsk1mx01.hyduke.net ([::1]) by nsk1mx01.hyduke.net ([::1]) with mapi; Fri, 16 Nov 2012 15:00:55 -0700 From: Joshua Shire To: "Rafiee, Hosnieh" , "Int-area@ietf.org" Date: Fri, 16 Nov 2012 15:00:53 -0700 Thread-Topic: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2rFSiGjyyz01Y/QQq74El/UneB+gFbhdAwBO/k3qA= Message-ID: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-8.0.0.4125-6.800.1017-19370.004 X-TM-AS-Result: No--33.310000-4.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 22:01:10 -0000 Hello, Just a few observations after reviewing this: 1) RFC3972 ("CGA") specifies that the modifier should be 64 bits and the co= llision count eight bits, yet I notice in Figure 2 it specifies a 16 bit mo= difier and a 1 bit collision count. Can you explain why you chose to implem= ent this differently? 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. 3) In 3.1 step 5 you may want to be clear that bits seven and eight should = be set to zero. 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 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.=20 Just an overall note, and this likely has more to do with me that you, I'm = a bit confused as to how this would functionally integrate on a host using = a CGA. Would you actually be running these algorithms again just for the pu= rpose of sending a DNS update or would you be layering on top of the existi= ng IP stack and using the existing CGA functionality? 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: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behal= f Of Rafiee, Hosnieh Sent: Tuesday, October 23, 2012 9:07 AM To: Int-area@ietf.org Cc: dnsext@ietf.org Subject: [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga= -tsig-00.txt Hello, This is our "last call" request for comments concerning our draft, RFC "CGA= -TSIG". If you feel so inclined, please feel free to comment on it. Any and= all comments are greatly appreciated. Thank you, ---------------------------------- A new version of I-D, draft-rafiee-intarea-cga-tsig-00.txt has been successfully submitted by Hosnieh Rafiee and posted to the IETF re= pository. Filename: draft-rafiee-intarea-cga-tsig Revision: 00 Title: Transaction SIGnature (TSIG) using CGA Algorithm in IPv6 Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-rafiee-intarea-c= ga-tsig-00.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-t= sig Htmlized: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-0= 0 Abstract: The first step of Transaction SIGnature (TSIG) (RFC 2845) is to generate a shared secret and exchange it manually between a DNS server and a host. This document, CGA-TSIG, proposes a possible way to automate the now manual process for the authentication of a node with a DNS server during the DNS Update process by using the same parameters as are used in generating a secure address in IPv6 networks, i.e., Cryptographically Generated Addresses (CGA) (RFC 3972). CGA-TSIG facilitates this authentication process and reduces the time needed for DNS Updates. The current signature generation process and verification mechanism in TSIG are thus replaced with CGA. This algorithm is added, as an extension, to TSIG to eliminate the human intervention needed for generation and exchange of keys between a DNS server and a host when SEcure Neighbor Discovery (SEND) (RFC 3971) is used. = =20 The IETF Secretariat _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From rafiee@hpi.uni-potsdam.de Fri Nov 16 15:48:42 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26E321F89E3 for ; Fri, 16 Nov 2012 15:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 p63MbYIhGtgl for ; Fri, 16 Nov 2012 15:48: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 0F21921F8924 for ; Fri, 16 Nov 2012 15:48:41 -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 C820A169E64; Sat, 17 Nov 2012 00:48: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; Sat, 17 Nov 2012 00:48:39 +0100 From: "Rafiee, Hosnieh" To: Joshua Shire Date: Sat, 17 Nov 2012 00:48:36 +0100 Thread-Topic: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2rFSiGjyyz01Y/QQq74El/UneB+gFbhdAwBO/k3qAAAREhIA== 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" Subject: Re: [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 23:48:42 -0000 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 jshire@hyduke.com Mon Nov 19 13:04:41 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F9721F8750 for ; Mon, 19 Nov 2012 13:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Vi6dbMimyzEM for ; Mon, 19 Nov 2012 13:04:40 -0800 (PST) Received: from mail.hyduke.net (mail.hyduke.net [67.226.164.185]) by ietfa.amsl.com (Postfix) with ESMTP id 78DC721F84EB for ; Mon, 19 Nov 2012 13:04:40 -0800 (PST) Received: from nsk1mx01.hyduke.net (192.168.9.68) by nsk1mx02.hyduke.net (192.168.10.49) with Microsoft SMTP Server id 8.1.436.0; Mon, 19 Nov 2012 14:04:37 -0700 Received: from nsk1mx01.hyduke.net ([::1]) by nsk1mx01.hyduke.net ([::1]) with mapi; Mon, 19 Nov 2012 14:04:38 -0700 From: Joshua Shire To: "Rafiee, Hosnieh" Date: Mon, 19 Nov 2012 14:04:36 -0700 Thread-Topic: Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt Thread-Index: Ac2rFSiGjyyz01Y/QQq74El/UneB+gFbhdAwBO/k3qAAAREhIACQiQTw Message-ID: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-Product-Ver: SMEX-8.0.0.4125-6.800.1017-19378.004 X-TM-AS-Result: No--33.214600-4.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: "Int-area@ietf.org" Subject: Re: [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 21:04:41 -0000 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 Mon Nov 19 13:29:55 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@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: [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing 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 sm@resistor.net Mon Nov 19 14:37:33 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AF221F84C2 for ; Mon, 19 Nov 2012 14:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 HdmKxd6fuUMt for ; Mon, 19 Nov 2012 14:37:33 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2914121F8462 for ; Mon, 19 Nov 2012 14:37:33 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qAJMbOeh003524; Mon, 19 Nov 2012 14:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353364649; bh=HjBghPLfjSrbFImgk3ySWKONVumhBIjzjOPV2prWXy4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=k0DYLxX5JVw1y24DyY+CHypk+vPK+I7KXNIjsbEYE+WsAm/qxw4VEEKOACXp49XzJ hgsi/hCv7X/HQeFz+KHWOPdNBQ62DEpuWeAIOd0QVBc+h20LauKvoSbDjOqWGSf65e VobDxWROn3nrgIrD2kDo2FTwyR8LIkIZQttnK9qg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353364649; i=@resistor.net; bh=HjBghPLfjSrbFImgk3ySWKONVumhBIjzjOPV2prWXy4=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=orTymj2M0cLFeivYP9EG1UkoLiIwV6fQaclWXfPn8cION1+KNKfOptBf6mMBGpZp+ zHhNZU0vL2Rt5sx0w5Uixg1bUxuIq6ncxvsDBHuiBFsRwIYEfK53bknw/cVyCTBYBE v361H22SViTrhcNIkRTa3Rryq0do8vvneDgpDcj0= Message-Id: <6.2.5.6.2.20121119142914.0ba001a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 19 Nov 2012 14:37:24 -0800 To: "Rafiee, Hosnieh" From: SM In-Reply-To: References: <20121015203920.7137.87362.idtracker@ietfa.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Int-area@ietf.org Subject: Re: [Int-area] Last Call before IETF meeting: draft-rafiee-intarea-cga-tsig-00.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 22:37:34 -0000 At 13:29 19-11-2012, Rafiee, Hosnieh wrote: >I look forward to receiving any help I can get to make this >application generate a file that is acceptable for automatic process >submission. (If I knew 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) The idnits source code is available at http://tools.ietf.org/tools/idnits/ You might try asking on tools-discuss ( https://www.ietf.org/mailman/listinfo/tools-discuss ). I am not sure whether it is off-topic for that mailing list. Regards, -sm From suresh.krishnan@ericsson.com Mon Nov 19 15:38:46 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C12721F8790 for ; Mon, 19 Nov 2012 15:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 Sb4mg4NZM1mb for ; Mon, 19 Nov 2012 15:38:45 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2466621F87D1 for ; Mon, 19 Nov 2012 15:38:45 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAJNjen4017237; Mon, 19 Nov 2012 17:45:43 -0600 Received: from [142.133.112.133] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.31) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 19 Nov 2012 18:38:37 -0500 Message-ID: <50AAC2FC.7060505@ericsson.com> Date: Mon, 19 Nov 2012 18:38:36 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> <50A2D76C.9080407@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "julien.ietf@gmail.com" , "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 23:38:46 -0000 Hi Linda, On 11/13/2012 08:43 PM, Linda Dunbar wrote: > Suresh, > > Comments are inserted below: > >> -----Original Message----- >>> >>> Even though that IPv6 ND uses multicast instead broadcast, IPv6 ND >> does >>> have scalability issues in Data Center when hosts within same subnet >> are >>> spread across different access switches, and when there are lot of >> those >>> subnets. In particular: >>> >>> * when hosts within the same subnet are spread across multiple >>> switches (or GWs in the draft), the ND solicitation still go to all >>> switches which might have the same subnet hosts attached. The traffic >>> across GWs are same as IPv4's ARP. The only difference is that hosts >>> impact is reduced. >> >> This is not true. If the switches are MLD snooping then the packets >> will >> not be sent to irrelevant GWs/switches. >> > > [Linda] For those GWs which has Hosts belonging to a particular subnet, the multicast for the subnet will reach all those GWs. The NSs are NOT multicasted to the subnet. They are sent to a solicited node multicast address that is formed from the last 24 bits of the IPv6 address. So only network segments that have nodes with matching 24 last bits in the address would get these messages when MLD snooping switches are present. > > >>> >>> >>> >>> * When host "a" needs to communicate with host "b" in >> different >>> subnet, "a" needs to send "Neighbor Solicitation" to L2/L3 boundary >>> router, (just the same way as IPv4 ARP). >> >> Correct. But only the router gets it. Not all the other hosts in the >> subnet (which is the case for ARP). >> >>> >>> When there are many subnets spreading across many access switches, >> the >>> L2/L3 boundary router has to enable all those subnets on many of its >>> ports/links. >> >> This is purely an implementation issue. I know of several router >> implementations where this is not the case. >> > > [Linda] This is the standard setting. When you have one subnet spanning over 20 server racks, with each rack reaching the L2/L3 boundary router via different links, the subnet has to be enabled on all those 20 ports. > > > Why do you say it is implementation issue? Because it is :-). As an example, if you take an fat tree architecture, the number of access switch ports on a subnet is not directly related to the number of ports on the L3 gateway that are on the same subnet. Thanks Suresh From linda.dunbar@huawei.com Mon Nov 19 16:12:01 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A607421F86F0 for ; Mon, 19 Nov 2012 16:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 sd+Jn1mdufQj for ; Mon, 19 Nov 2012 16:12:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 64D8121F86DA for ; Mon, 19 Nov 2012 16:11:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMY43711; Tue, 20 Nov 2012 00:11:53 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 00:11:25 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 00:11:50 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Mon, 19 Nov 2012 16:11:47 -0800 From: Linda Dunbar To: Suresh Krishnan Thread-Topic: IPv6 ND applicability in draft-nachum-sarp-03 Thread-Index: Ac3BJiJbrs+Mg7erTp6yFDNDBTG1HwBE2TIAAAw+YCABIeL/AAAP6wxw Date: Tue, 20 Nov 2012 00:11:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645098E1A@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> <50A2D76C.9080407@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> <50AAC2FC.7060505@ericsson.com> In-Reply-To: <50AAC2FC.7060505@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "julien.ietf@gmail.com" , "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 00:12:01 -0000 Suresh,=20 > -----Original Message----- >=20 > Because it is :-). As an example, if you take an fat tree architecture, > the number of access switch ports on a subnet is not directly related > to > the number of ports on the L3 gateway that are on the same subnet. >=20 For the following network, if one subnet (regardless IPv4 or IPv6) have hos= ts in all server racks, the L2/L3 has to enable the subnet on links (or por= ts) to all the access switches (ToRs).=20 Then the IPv6's ND for the subnet will be flooded to all links. It is the s= ame problem as IPv4 ARP. How IPv6 ND scale better than IPv4's ARP? L2/L3 boundary +-------+ =20 +/------+ | =20 | L2/L3 | \ +---+---+/\ \ =20 / \ \ \ =20 / \ \ \ =20 +---+ +---+ +---+ +---+ |T11|... |T1x| |T21| ... |T2y| ToR switches +---+ +---+ +---+ +---+ | | | |=20 +-|-+ +-|-+ +-|-+ +-|-+ | |... | | | | ... | | +---+ +---+ +---+ +---+ Server racks | |... | | | | ... | | +---+ +---+ +---+ +---+ | |... | | | | ... | | +---+ +---+ +---+ +---+ p.s. I still don't see how it is related to implementation. May be you mean= network design? =20 Linda From suresh.krishnan@ericsson.com Tue Nov 20 08:50:47 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A2F21F8690 for ; Tue, 20 Nov 2012 08:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 9cqjzkngGHa1 for ; Tue, 20 Nov 2012 08:50:47 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2105B21F8465 for ; Tue, 20 Nov 2012 08:50:45 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id qAKGoV7O025062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Nov 2012 10:50:42 -0600 Received: from [142.133.112.133] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.32) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 11:50:40 -0500 Message-ID: <50ABB448.3050206@ericsson.com> Date: Tue, 20 Nov 2012 11:48:08 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> <50A2D76C.9080407@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> <50AAC2FC.7060505@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645098E1A@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645098E1A@dfweml505-mbx> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "julien.ietf@gmail.com" , "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 16:50:47 -0000 Hi Linda, On 11/19/2012 07:11 PM, Linda Dunbar wrote: > Suresh, > > > >> -----Original Message----- >> >> Because it is :-). As an example, if you take an fat tree architecture, >> the number of access switch ports on a subnet is not directly related >> to >> the number of ports on the L3 gateway that are on the same subnet. >> > > For the following network, if one subnet (regardless IPv4 or IPv6) have hosts in all server racks, the L2/L3 has to enable the subnet on links (or ports) to all the access switches (ToRs). > > Then the IPv6's ND for the subnet will be flooded to all links. It is the same problem as IPv4 ARP. How IPv6 ND scale better than IPv4's ARP? At the risk of repeating myself. NO, the ND message will not be flooded to all the links. It is multicast to a solicited node multicast address (ff02::1:ffxx:xxxx) and the ND message is only sent to the links where there is at least one node that has joined this multicast group. > > > > > L2/L3 boundary > +-------+ > +/------+ | > | L2/L3 | \ > +---+---+/\ \ > / \ \ \ > / \ \ \ > +---+ +---+ +---+ +---+ > |T11|... |T1x| |T21| ... |T2y| ToR switches > +---+ +---+ +---+ +---+ > | | | | > +-|-+ +-|-+ +-|-+ +-|-+ > | |... | | | | ... | | > +---+ +---+ +---+ +---+ Server racks > | |... | | | | ... | | > +---+ +---+ +---+ +---+ > | |... | | | | ... | | > +---+ +---+ +---+ +---+ > > > p.s. I still don't see how it is related to implementation. May be you mean network design? As I said above, if your switch implementation(s) do not support MLD snooping, then you will have an issue. In that case, the right fix is to add MLD snooping functionality into the switch. Thanks Suresh From linda.dunbar@huawei.com Tue Nov 20 10:05:20 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BED21F84E6 for ; Tue, 20 Nov 2012 10:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 F7ZakYDUENNq for ; Tue, 20 Nov 2012 10:05:19 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6782C21F848B for ; Tue, 20 Nov 2012 10:05:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALT05536; Tue, 20 Nov 2012 18:05:17 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 18:04:49 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Nov 2012 18:05:16 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Tue, 20 Nov 2012 10:05:12 -0800 From: Linda Dunbar To: Suresh Krishnan Thread-Topic: IPv6 ND applicability in draft-nachum-sarp-03 Thread-Index: Ac3BJiJbrs+Mg7erTp6yFDNDBTG1HwBE2TIAAAw+YCABIeL/AAAP6wxwABQJswAADjfooA== Date: Tue, 20 Nov 2012 18:05:12 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645099345@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> <50A2D76C.9080407@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> <50AAC2FC.7060505@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645098E1A@dfweml505-mbx> <50ABB448.3050206@ericsson.com> In-Reply-To: <50ABB448.3050206@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.157.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "julien.ietf@gmail.com" , "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Nov 2012 18:05:20 -0000 Suresh,=20 Are you saying that router has to send out MLD Query for all potential ND m= ulticast addresses and keep up state for listeners for all those multicast = addresses?=20 There could be millions of "Solicited-Node multicast addresses". That is a = lot of processing on routers.=20 Linda=20 > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Tuesday, November 20, 2012 10:48 AM > To: Linda Dunbar > Cc: int-area@ietf.org; julien.ietf@gmail.com; Tal Mizrahi > Subject: Re: IPv6 ND applicability in draft-nachum-sarp-03 >=20 > Hi Linda, >=20 > On 11/19/2012 07:11 PM, Linda Dunbar wrote: > > Suresh, > > > > > > > >> -----Original Message----- > >> > >> Because it is :-). As an example, if you take an fat tree > architecture, > >> the number of access switch ports on a subnet is not directly > related > >> to > >> the number of ports on the L3 gateway that are on the same subnet. > >> > > > > For the following network, if one subnet (regardless IPv4 or IPv6) > have hosts in all server racks, the L2/L3 has to enable the subnet on > links (or ports) to all the access switches (ToRs). > > > > Then the IPv6's ND for the subnet will be flooded to all links. It is > the same problem as IPv4 ARP. How IPv6 ND scale better than IPv4's ARP? >=20 > At the risk of repeating myself. NO, the ND message will not be flooded > to all the links. It is multicast to a solicited node multicast address > (ff02::1:ffxx:xxxx) and the ND message is only sent to the links where > there is at least one node that has joined this multicast group. >=20 > > > > > > > > > > L2/L3 boundary > > +-------+ > > +/------+ | > > | L2/L3 | \ > > +---+---+/\ \ > > / \ \ \ > > / \ \ \ > > +---+ +---+ +---+ +---+ > > |T11|... |T1x| |T21| ... |T2y| ToR switches > > +---+ +---+ +---+ +---+ > > | | | | > > +-|-+ +-|-+ +-|-+ +-|-+ > > | |... | | | | ... | | > > +---+ +---+ +---+ +---+ Server racks > > | |... | | | | ... | | > > +---+ +---+ +---+ +---+ > > | |... | | | | ... | | > > +---+ +---+ +---+ +---+ > > > > > > p.s. I still don't see how it is related to implementation. May be > you mean network design? >=20 > As I said above, if your switch implementation(s) do not support MLD > snooping, then you will have an issue. In that case, the right fix is > to > add MLD snooping functionality into the switch. >=20 > Thanks > Suresh From suresh.krishnan@ericsson.com Tue Nov 20 16:01:00 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40E921F86B9 for ; Tue, 20 Nov 2012 16:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.442 X-Spam-Level: X-Spam-Status: No, score=-106.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, 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 0BXxbJ32L+uh for ; Tue, 20 Nov 2012 16:00:59 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 74AC121F869A for ; Tue, 20 Nov 2012 16:00:59 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id qAL080LK014706; Tue, 20 Nov 2012 18:08:04 -0600 Received: from [142.133.112.133] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.178) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 19:00:50 -0500 Message-ID: <50AC191A.1040205@ericsson.com> Date: Tue, 20 Nov 2012 18:58:18 -0500 From: Suresh Krishnan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> <50A2D76C.9080407@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> <50AAC2FC.7060505@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645098E1A@dfweml505-mbx> <50ABB448.3050206@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645099345@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645099345@dfweml505-mbx> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "julien.ietf@gmail.com" , "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 00:01:00 -0000 Hi Linda, On 11/20/2012 01:05 PM, Linda Dunbar wrote: > Suresh, > > Are you saying that router has to send out MLD Query for all potential ND multicast addresses and keep up state for listeners for all those multicast addresses? Nope. Only for those solicited node multicast groups that have at least one host on the subnet join. > > There could be millions of "Solicited-Node multicast addresses". That is a lot of processing on routers. Not sure that I follow. Do you have millions of hosts on the subnet? If not, I do not see why you have to keep track of "millions of solicited node multicast addresses". Thanks Suresh From linda.dunbar@huawei.com Wed Nov 21 07:17:15 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC87321F8459 for ; Wed, 21 Nov 2012 07:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.275 X-Spam-Level: X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 Dd3An0ySAxAR for ; Wed, 21 Nov 2012 07:17:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1121F8441 for ; Wed, 21 Nov 2012 07:17:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANA09792; Wed, 21 Nov 2012 15:17:13 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Nov 2012 15:16:38 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Nov 2012 15:17:09 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 21 Nov 2012 07:17:04 -0800 From: Linda Dunbar To: Suresh Krishnan Thread-Topic: IPv6 ND applicability in draft-nachum-sarp-03 Thread-Index: Ac3BJiJbrs+Mg7erTp6yFDNDBTG1HwBE2TIAAAw+YCABIeL/AAAP6wxwABQJswAADjfooAAAzhYAAA7QLEA= Date: Wed, 21 Nov 2012 15:17:04 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F64509971A@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> <50A2D76C.9080407@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> <50AAC2FC.7060505@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645098E1A@dfweml505-mbx> <50ABB448.3050206@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645099345@dfweml505-mbx> <50AC191A.1040205@ericsson.com> In-Reply-To: <50AC191A.1040205@ericsson.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.251] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F64509971Adfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "julien.ietf@gmail.com" , "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 15:17:16 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F64509971Adfweml505mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Suresh, "solicited node multicast address" is formed by taking the low-order 24 bit= s of target address (unicast or anycast) and appending those bits to the pr= efix FF02:0:0:0:0:1:FF00::/104 Routers don't know ahead of time what hosts are present in their Layer 2 do= main. In DC with virtual machines added/deleted consistently, there could b= e millions of possibilities. What multicast addresses should router send out MLD Query? What you are proposing is like using MLD snooping to achieve ND function, w= hich doesn't scale. Linda > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Tuesday, November 20, 2012 5:58 PM > To: Linda Dunbar > Cc: int-area@ietf.org; julien.ietf@gmail.com; Tal Mizrahi > Subject: Re: IPv6 ND applicability in draft-nachum-sarp-03 > > Hi Linda, > > On 11/20/2012 01:05 PM, Linda Dunbar wrote: > > Suresh, > > > > Are you saying that router has to send out MLD Query for all > potential ND multicast addresses and keep up state for listeners for > all those multicast addresses? > > Nope. Only for those solicited node multicast groups that have at least > one host on the subnet join. > > > > > There could be millions of "Solicited-Node multicast addresses". That > is a lot of processing on routers. > > Not sure that I follow. Do you have millions of hosts on the subnet? If > not, I do not see why you have to keep track of "millions of solicited > node multicast addresses". > > Thanks > Suresh > --_000_4A95BA014132FF49AE685FAB4B9F17F64509971Adfweml505mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Suresh,
 
"solicited node multicast address" is formed by taking the l= ow-order 24 bits of target address (unicast or anycast) and appending those= bits to the prefix FF02:0:0:0:0:1:FF00::/104
 
Routers don't know ahead of time what hosts are present in their Layer= 2 domain. In DC with virtual machines added/deleted consistently, there co= uld be millions of possibilities.
 
What multicast addresses should router send out MLD Query?
 
What you are proposing is like using MLD snooping to achieve ND functi= on, which doesn't scale.
 
Linda
 
> -----Original Message-----
> From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com]
> Sent: Tuesday, November 20, 2012 5:58 PM
> To: Linda Dunbar
> Cc: int-area@ietf.org; julien.ietf@gmail.com; Tal Mizrahi
> Subject: Re: IPv6 ND applicability in draft-nachum-sarp-03
>
> Hi Linda,
>
> On 11/20/2012 01:05 PM, Linda Dunbar wrote:
> > Suresh,
> >
> > Are you saying that router has to send out MLD Query for all=
> potential ND multicast addresses and keep up state for listeners = for
> all those multicast addresses?
>
> Nope. Only for those solicited node multicast groups that have at= least
> one host on the subnet join.
>
> >
> > There could be millions of "Solicited-Node multicast ad= dresses". That
> is a lot of processing on routers.
>
> Not sure that I follow. Do you have millions of hosts on the subn= et? If
> not, I do not see why you have to keep track of "millions of= solicited
> node multicast addresses".
>
> Thanks
> Suresh
>
 
 
 --_000_4A95BA014132FF49AE685FAB4B9F17F64509971Adfweml505mbx_-- From julien.ietf@gmail.com Wed Nov 21 14:35:15 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7A421F8504 for ; Wed, 21 Nov 2012 14:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-cdgFPBEnAF for ; Wed, 21 Nov 2012 14:35:10 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id B48A921F8516 for ; Wed, 21 Nov 2012 14:35:10 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so5359899pbc.31 for ; Wed, 21 Nov 2012 14:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+44SDbnAE5fXiJwaRlogq9yjs0T9Qr8KMq0MMJ/Om3A=; b=0/fRWfJvQcxbNMopqSGB5I51xAni6PdnUnfuCIqnS0lkiu3MgU3ITfvvxclRv9w0Fn JliqngzoCuuUYOekSI3QueUS4tXLM7Utx/M/3SK+BUo89E4Byy1QPUqdaQKP+bwXFeAf ed6/pBtIiW9HQgEzARw6cRtSyp2OWID+BzTPdPixp9ezCtwp79FzZx4gD/T4LFVR2CFj BZ4iuG6wrev4XP6e0FQDoRYeRkgeMjyABrjsJB6xPyowzb6DrnTPls9wi6wAVRMsvPcC R+VM3StD1ywXGSAab58ASHtUI/hwAMBdEM5n1CBcm53XvkZtdTtbJIf5FHfF9JnRGzha ej5g== MIME-Version: 1.0 Received: by 10.68.252.40 with SMTP id zp8mr3406997pbc.66.1353537310485; Wed, 21 Nov 2012 14:35:10 -0800 (PST) Received: by 10.68.127.163 with HTTP; Wed, 21 Nov 2012 14:35:10 -0800 (PST) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F64509971A@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> <50A2D76C.9080407@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> <50AAC2FC.7060505@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645098E1A@dfweml505-mbx> <50ABB448.3050206@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645099345@dfweml505-mbx> <50AC191A.1040205@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F64509971A@dfweml505-mbx> Date: Wed, 21 Nov 2012 14:35:10 -0800 Message-ID: From: Julien Laganier To: Linda Dunbar Content-Type: text/plain; charset=ISO-8859-1 Cc: "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2012 22:35:16 -0000 Linda, The router periodically sends out a general query to which nodes replies to with a report of their multicast listening state. Also, when a node interface is configured with an IPv6 address, the node spontaneously sends a report for the solicited-node multicast address corresponding to the IPv6 address configured. So routers don't have to know anything ahead of time. And same goes for MLD-snooping switches. --julien On Wed, Nov 21, 2012 at 7:17 AM, Linda Dunbar wrote: > Suresh, > > "solicited node multicast address" is formed by taking the low-order 24 bits > of target address (unicast or anycast) and appending those bits to the > prefix FF02:0:0:0:0:1:FF00::/104 > > Routers don't know ahead of time what hosts are present in their Layer 2 > domain. In DC with virtual machines added/deleted consistently, there could > be millions of possibilities. > > What multicast addresses should router send out MLD Query? > > What you are proposing is like using MLD snooping to achieve ND function, > which doesn't scale. > > Linda > >> -----Original Message----- >> From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] >> Sent: Tuesday, November 20, 2012 5:58 PM >> To: Linda Dunbar >> Cc: int-area@ietf.org; julien.ietf@gmail.com; Tal Mizrahi >> Subject: Re: IPv6 ND applicability in draft-nachum-sarp-03 >> >> Hi Linda, >> >> On 11/20/2012 01:05 PM, Linda Dunbar wrote: >> > Suresh, >> > >> > Are you saying that router has to send out MLD Query for all >> potential ND multicast addresses and keep up state for listeners for >> all those multicast addresses? >> >> Nope. Only for those solicited node multicast groups that have at least >> one host on the subnet join. >> >> > >> > There could be millions of "Solicited-Node multicast addresses". That >> is a lot of processing on routers. >> >> Not sure that I follow. Do you have millions of hosts on the subnet? If >> not, I do not see why you have to keep track of "millions of solicited >> node multicast addresses". >> >> Thanks >> Suresh >> > > From gdaley@au.logicalis.com Wed Nov 21 16:13:05 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198DE21F8816 for ; Wed, 21 Nov 2012 16:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.29 X-Spam-Level: X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RELAY_IS_203=0.994, SARE_MILLIONSOF=0.315] 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 F8EJka3ZyYNz for ; Wed, 21 Nov 2012 16:13:04 -0800 (PST) Received: from smtp1.netstarnetworks.com (smtp1.au.logicalis.com [203.8.7.132]) by ietfa.amsl.com (Postfix) with ESMTP id A164B21F8810 for ; Wed, 21 Nov 2012 16:13:03 -0800 (PST) Received-SPF: None identity=mailfrom; client-ip=203.8.7.161; receiver=smtp1.netstarnetworks.com; envelope-from="gdaley@au.logicalis.com"; x-sender="gdaley@au.logicalis.com"; x-conformance=spf_only Received-SPF: None identity=helo; client-ip=203.8.7.161; receiver=smtp1.netstarnetworks.com; envelope-from="gdaley@au.logicalis.com"; x-sender="postmaster@sdcexchht.au.logicalis.com"; x-conformance=spf_only Received: from unknown (HELO sdcexchht.au.logicalis.com) ([203.8.7.161]) by smtp1.netstarnetworks.com with ESMTP; 22 Nov 2012 11:08:43 +1100 Received: from SDCEXCHMS.au.logicalis.com ([10.18.196.50]) by sdcexchht.au.logicalis.com ([fe80::68b7:8880:fefb:f742%12]) with mapi id 14.02.0318.004; Thu, 22 Nov 2012 11:12:52 +1100 From: Greg Daley To: 'Linda Dunbar' , Suresh Krishnan Thread-Topic: IPv6 ND applicability in draft-nachum-sarp-03 Thread-Index: AQHNx/tLAU++lnwQA0iUSz7QFmQJaJf03uww Date: Thu, 22 Nov 2012 00:12:51 +0000 Message-ID: <72381AF1F18BAE4F890A0813768D9928F25D62@sdcexchms.au.logicalis.com> References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> <50A2D76C.9080407@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> <50AAC2FC.7060505@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645098E1A@dfweml505-mbx> <50ABB448.3050206@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645099345@dfweml505-mbx> <50AC191A.1040205@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F64509971A@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F64509971A@dfweml505-mbx> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.196.143] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 21 Nov 2012 17:27:11 -0800 Cc: "julien.ietf@gmail.com" , "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 00:13:05 -0000 Hi Linda,=20 (also noting some overlap with Julien's response) The MLDv1 (RFC2710) or v2 (RFC3810) Querier sends out a general query R tim= es (where R is the reliability factor for the link), which requests that al= l devices respond. This goes to all-nodes multicast ff02::1, and the desit= nation of the query doesn't have to match recipients (all of which listen t= o that multicast group). This scales with responses on order N x R where N is the number of nodes. If a router needs to manage a particular stream, it can send a specific que= ry to one of the multicast addresses, particularly to verify that participa= nts. The router doesn't actually need to track the solicited nodes multicast add= resses, as these are link-local scoped and not multicast routed off-link. Actually in conformance with RFC 6398/BCP 168 (IP Router Alert Consideratio= ns and Usage)/RFC 6192 (Protecting the Router Control Plane) it is feasible= to construct filters which ignore MLD report messages which only contain L= ink-local scoped multicast groups on the router. With the correct hardware= support, this can be done at the line interface, without CPU processing. = The default is to pass all MLD reports up to the Router though. Arguably, the only reason to send MLD Join messages for Solicited Nodes' mu= lticast addresses _is_ to support MLD snooping switches. Please note that MLD snooping is an LRU caching scheme, where the cache is = refreshed for all active users through the background polling of the MLD qu= erier. The switches do not need to know anything ahead of time. Devices= which do not respond to the query will be dropped from the cache, and only= the number of active hosts will be retained. If you changed the IP addresses of every host on the link within a single q= uery interval, the maximum number of Solicited nodes addresses cached by an= MLD snooping network would be: ^A x N x 2=20 Where: The original the number of addresses is ^A x N=20 and ^A is the mean number of addresses per host, and N is the number of hos= ts on the link.=20 Sincerely Greg Daley >=20 > > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Beh= alf Of Linda Dunbar > Sent: Thursday, 22 November 2012 2:17 AM > To: Suresh Krishnan > Cc: julien.ietf@gmail.com; int-area@ietf.org > Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 > > Suresh,=20 >=A0 > "solicited node multicast address" is formed by taking the low-order 24 b= its of target address (unicast or anycast) and appending those bits to the = prefix > FF02:0:0:0:0:1:FF00::/104=20 >=A0 > Routers don't know ahead of time what hosts are present in their Layer 2 = domain. In DC with virtual machines added/deleted consistently, there could= > be millions of possibilities. >=A0 > What multicast addresses should router send out MLD Query?=20 >=A0 > What you are proposing is like using MLD snooping to achieve ND function,= which doesn't scale.=20 >=A0 > Linda =A0 > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Tuesday, November 20, 2012 5:58 PM > To: Linda Dunbar > Cc: int-area@ietf.org; julien.ietf@gmail.com; Tal Mizrahi > Subject: Re: IPv6 ND applicability in draft-nachum-sarp-03 >=20 > Hi Linda, >=20 > On 11/20/2012 01:05 PM, Linda Dunbar wrote: > > Suresh, > > > > Are you saying that router has to send out MLD Query for all > potential ND multicast addresses and keep up state for listeners for > all those multicast addresses? >=20 > Nope. Only for those solicited node multicast groups that have at least > one host on the subnet join. >=20 > > > > There could be millions of "Solicited-Node multicast addresses". That > is a lot of processing on routers. >=20 > Not sure that I follow. Do you have millions of hosts on the subnet? If > not, I do not see why you have to keep track of "millions of solicited > node multicast addresses". >=20 > Thanks > Suresh >=20 =A0 =A0 From rafiee@hpi.uni-potsdam.de Fri Nov 23 01:34:10 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9398321F8CD2 for ; Fri, 23 Nov 2012 01:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.042, 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 Iepf8Rn9Pkb4 for ; Fri, 23 Nov 2012 01:34:06 -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 6169E21F8A68 for ; Fri, 23 Nov 2012 01:34: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 61B45169E73 for ; Fri, 23 Nov 2012 10:34: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 10:34:03 +0100 From: "Rafiee, Hosnieh" To: "Int-area@ietf.org" Date: Fri, 23 Nov 2012 10:34:02 +0100 Thread-Topic: Please comment on this updated version < draft-rafiee-intarea-cga-tsig-01.txt> Thread-Index: Ac3JBFwvFEnPMQYYT+CKEJ+BPKWaXgAAJcyQABYomSA= 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Int-area] Please comment on this updated version < draft-rafiee-intarea-cga-tsig-01.txt> X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 09:34:10 -0000 Hello, I revised my draft-rafiee-intarea-cga-tsig incorporating your comments tha= t I received by email. Please review my revised document. Best Regards, Hosnieh URL: http://www.ietf.org/internet-drafts/draft-rafiee-intarea-c= ga-tsig-01.txt Status: http://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-t= sig Htmlized: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-0= 1 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-rafiee-intarea-cg= a-tsig-01 Abstract: The first step in the Transaction SIGnature (TSIG) (RFC 2845) process is the generation of a shared secret to be used between a DNS server and a host. The second step is the manual exchange of the shared secret between the DNS server and the host. This document, CGA-TSIG, proposes a possible way to automate the now manual process used for the authentication of a node with a DNS server during the DNS Update process by using the same parameters as are used in generating a secure address in IPv6 networks, i.e., Cryptographically Generated Addresses (CGA) (RFC 3972). CGA-TSIG facilitates this authentication process and reduces the time needed for DNS Updates. The current signature generation process and verification mechanism in TSIG are thus replaced with CGA. This algorithm is added, as an extension, to TSIG to eliminate the human intervention needed for generation and exchange of keys between a DNS server and a host when SEcure Neighbor Discovery (SEND) (RFC 3971) is used. From linda.dunbar@huawei.com Tue Nov 27 10:41:25 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E7E21F8641 for ; Tue, 27 Nov 2012 10:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.292 X-Spam-Level: X-Spam-Status: No, score=-5.292 tagged_above=-999 required=5 tests=[AWL=0.992, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 1BuArEV9d1yt for ; Tue, 27 Nov 2012 10:41:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 001AA21F85C0 for ; Tue, 27 Nov 2012 10:41:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ALY71330; Tue, 27 Nov 2012 18:41:23 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Nov 2012 18:41:14 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Nov 2012 02:41:22 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Tue, 27 Nov 2012 10:41:17 -0800 From: Linda Dunbar To: Greg Daley , Suresh Krishnan Thread-Topic: IPv6 ND applicability in draft-nachum-sarp-03 Thread-Index: Ac3BJiJbrs+Mg7erTp6yFDNDBTG1HwBE2TIAAAw+YCABIeL/AAAP6wxwABQJswAADjfooAAAzhYAAA7QLEAAI/yEgAEQleQg Date: Tue, 27 Nov 2012 18:41:16 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6450B626D@dfweml505-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6450951DE@dfweml505-mbx> <50A2D76C.9080407@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645096D95@dfweml505-mbx> <50AAC2FC.7060505@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645098E1A@dfweml505-mbx> <50ABB448.3050206@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F645099345@dfweml505-mbx> <50AC191A.1040205@ericsson.com> <4A95BA014132FF49AE685FAB4B9F17F64509971A@dfweml505-mbx> <72381AF1F18BAE4F890A0813768D9928F25D62@sdcexchms.au.logicalis.com> In-Reply-To: <72381AF1F18BAE4F890A0813768D9928F25D62@sdcexchms.au.logicalis.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.166] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "julien.ietf@gmail.com" , "int-area@ietf.org" Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 18:41:25 -0000 Greg,=20 Thank you very much for the detailed explanation.=20 As for Router sending MLD query to all-nodes multicast ff02::1, if Explicit= Tracing is not turned on, routers usually don't keep all the host IP addre= sses attached to each port/link, does it?=20 If the ToR switches has MLD proxy, it could suppress reports from some IP h= osts. Then, the Router may not receive MLD reports from all hosts attached = to one port.=20 Under this scenario, when a host "a" sends Neighbor Solicitation multicast= to "b", router may not know which link "b" is attached. As the result rout= er could flood all the ports which has the subnet enabled.=20 The MLD with Explicit Tracking being turned on can make router be refreshed= with all hosts in the domain. That can definitely scope the ND multicast.= =20 However, MLD with Explicit Tracking could be very resource intensive.=20 "draft-nachum-sarp" gives another approach to scope the ND multicast and al= leviates the burden on router when subnets are spread across multiple links= /ToRs.=20 Linda > -----Original Message----- > From: Greg Daley [mailto:gdaley@au.logicalis.com] > Sent: Wednesday, November 21, 2012 6:13 PM > To: Linda Dunbar; Suresh Krishnan > Cc: julien.ietf@gmail.com; int-area@ietf.org > Subject: RE: IPv6 ND applicability in draft-nachum-sarp-03 >=20 > Hi Linda, > (also noting some overlap with Julien's response) >=20 > The MLDv1 (RFC2710) or v2 (RFC3810) Querier sends out a general query R > times (where R is the reliability factor for the link), which requests > that all devices respond. This goes to all-nodes multicast ff02::1, > and the desitnation of the query doesn't have to match recipients (all > of which listen to that multicast group). >=20 > This scales with responses on order N x R where N is the number of > nodes. >=20 > If a router needs to manage a particular stream, it can send a specific > query to one of the multicast addresses, particularly to verify that > participants. >=20 > The router doesn't actually need to track the solicited nodes multicast > addresses, as these are link-local scoped and not multicast routed off- > link. >=20 > Actually in conformance with RFC 6398/BCP 168 (IP Router Alert > Considerations and Usage)/RFC 6192 (Protecting the Router Control Plane) > it is feasible to construct filters which ignore MLD report messages > which only contain Link-local scoped multicast groups on the router. > With the correct hardware support, this can be done at the line > interface, without CPU processing. The default is to pass all MLD > reports up to the Router though. >=20 > Arguably, the only reason to send MLD Join messages for Solicited > Nodes' multicast addresses _is_ to support MLD snooping switches. >=20 > Please note that MLD snooping is an LRU caching scheme, where the cache > is refreshed for all active users through the background polling of the > MLD querier. The switches do not need to know anything ahead of time. > Devices which do not respond to the query will be dropped from the > cache, and only the number of active hosts will be retained. >=20 > If you changed the IP addresses of every host on the link within a > single query interval, the maximum number of Solicited nodes addresses > cached by an MLD snooping network would be: >=20 > ^A x N x 2 >=20 > Where: >=20 > The original the number of addresses is ^A x N > and ^A is the mean number of addresses per host, and N is the number of > hosts on the link. >=20 > Sincerely >=20 > Greg Daley >=20 >=20 > > > > > > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Linda Dunbar > > Sent: Thursday, 22 November 2012 2:17 AM > > To: Suresh Krishnan > > Cc: julien.ietf@gmail.com; int-area@ietf.org > > Subject: Re: [Int-area] IPv6 ND applicability in draft-nachum-sarp-03 > > > > Suresh, > > > > "solicited node multicast address" is formed by taking the low-order > 24 bits of target address (unicast or anycast) and appending those bits > to the prefix > FF02:0:0:0:0:1:FF00::/104 > > > > Routers don't know ahead of time what hosts are present in their > Layer 2 domain. In DC with virtual machines added/deleted consistently, > there could > be millions of possibilities. > > > > What multicast addresses should router send out MLD Query? > > > > What you are proposing is like using MLD snooping to achieve ND > function, which doesn't scale. > > > > Linda >=20 > > -----Original Message----- > > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > > Sent: Tuesday, November 20, 2012 5:58 PM > > To: Linda Dunbar > > Cc: int-area@ietf.org; julien.ietf@gmail.com; Tal Mizrahi > > Subject: Re: IPv6 ND applicability in draft-nachum-sarp-03 > > > > Hi Linda, > > > > On 11/20/2012 01:05 PM, Linda Dunbar wrote: > > > Suresh, > > > > > > Are you saying that router has to send out MLD Query for all > > potential ND multicast addresses and keep up state for listeners for > > all those multicast addresses? > > > > Nope. Only for those solicited node multicast groups that have at > least > > one host on the subnet join. > > > > > > > > There could be millions of "Solicited-Node multicast addresses". > That > > is a lot of processing on routers. > > > > Not sure that I follow. Do you have millions of hosts on the subnet? > If > > not, I do not see why you have to keep track of "millions of > solicited > > node multicast addresses". > > > > Thanks > > Suresh > > >=20 >=20 From internet-drafts@ietf.org Tue Nov 27 16:15:02 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14111F0C7F; Tue, 27 Nov 2012 16:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 P4NekwE2CYP7; Tue, 27 Nov 2012 16:15:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329611F0C5F; Tue, 27 Nov 2012 16:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121128001502.1462.57442.idtracker@ietfa.amsl.com> Date: Tue, 27 Nov 2012 16:15:02 -0800 Cc: int-area@ietf.org Subject: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 00:15:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Area Working Group Working Group= of the IETF. Title : Updated Specification of the IPv4 ID Field Author(s) : Joe Touch Filename : draft-ietf-intarea-ipv4-id-update-07.txt Pages : 19 Date : 2012-11-27 Abstract: The IPv4 Identification (ID) field enables fragmentation and reassembly, and as currently specified is required to be unique within the maximum lifetime for all datagrams with a given source/destination/protocol tuple. If enforced, this uniqueness requirement would limit all connections to 6.4 Mbps. Because individual connections commonly exceed this speed, it is clear that existing systems violate the current specification. This document updates the specification of the IPv4 ID field in RFC791, RFC1122, and RFC2003 to more closely reflect current practice and to more closely match IPv6 so that the field's value is defined only when a datagram is actually fragmented. It also discusses the impact of these changes on how datagrams are used. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-ipv4-id-update-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From touch@isi.edu Tue Nov 27 16:34:22 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7146921F86B8; Tue, 27 Nov 2012 16:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.071 X-Spam-Level: X-Spam-Status: No, score=-105.071 tagged_above=-999 required=5 tests=[AWL=1.528, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XRxIrE3SS8la; Tue, 27 Nov 2012 16:34:22 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id F144021F86AF; Tue, 27 Nov 2012 16:34:21 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id qAS0XNno020442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Nov 2012 16:33:23 -0800 (PST) Message-ID: <50B55BD3.1090707@isi.edu> Date: Tue, 27 Nov 2012 16:33:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: internet-drafts@ietf.org References: <20121128001502.1462.57442.idtracker@ietfa.amsl.com> In-Reply-To: <20121128001502.1462.57442.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: int-area@ietf.org, i-d-announce@ietf.org Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 00:34:22 -0000 Hi, all, Section 5.5 was added at the request of the IESG. Please let me know if you have any concerns regarding the content of that section. Joe On 11/27/2012 4:15 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Internet Area Working Group Working Group of the IETF. > > Title : Updated Specification of the IPv4 ID Field > Author(s) : Joe Touch > Filename : draft-ietf-intarea-ipv4-id-update-07.txt > Pages : 19 > Date : 2012-11-27 > > Abstract: > The IPv4 Identification (ID) field enables fragmentation and > reassembly, and as currently specified is required to be unique > within the maximum lifetime for all datagrams with a given > source/destination/protocol tuple. If enforced, this uniqueness > requirement would limit all connections to 6.4 Mbps. Because > individual connections commonly exceed this speed, it is clear that > existing systems violate the current specification. This document > updates the specification of the IPv4 ID field in RFC791, RFC1122, > and RFC2003 to more closely reflect current practice and to more > closely match IPv6 so that the field's value is defined only when a > datagram is actually fragmented. It also discusses the impact of > these changes on how datagrams are used. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-ipv4-id-update-07 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > From Fred.L.Templin@boeing.com Wed Nov 28 10:20:48 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B5F21F8471; Wed, 28 Nov 2012 10:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt7onZdR0wyY; Wed, 28 Nov 2012 10:20:38 -0800 (PST) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) by ietfa.amsl.com (Postfix) with ESMTP id ADC9021F8468; Wed, 28 Nov 2012 10:20:35 -0800 (PST) Received: from slb-mbsout-01.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id qASIKZv1030338; Wed, 28 Nov 2012 10:20:35 -0800 Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id qASIKXOr030306 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 28 Nov 2012 10:20:34 -0800 Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.97]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Wed, 28 Nov 2012 10:20:34 -0800 From: "Templin, Fred L" To: Joe Touch , "internet-drafts@ietf.org" Date: Wed, 28 Nov 2012 10:20:32 -0800 Thread-Topic: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-07.txt Thread-Index: Ac3NAB6z2WGXJvM1TaWHFB5UppWylQAlNf1Q Message-ID: References: <20121128001502.1462.57442.idtracker@ietfa.amsl.com> <50B55BD3.1090707@isi.edu> In-Reply-To: <50B55BD3.1090707@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: No Cc: "int-area@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update-07.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 18:20:48 -0000 The section 5.5 text works for me. Fred > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Joe Touch > Sent: Tuesday, November 27, 2012 4:33 PM > To: internet-drafts@ietf.org > Cc: int-area@ietf.org; i-d-announce@ietf.org > Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-ipv4-id-update- > 07.txt >=20 > Hi, all, >=20 > Section 5.5 was added at the request of the IESG. Please let me know if > you have any concerns regarding the content of that section. >=20 > Joe >=20 > On 11/27/2012 4:15 PM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Internet Area Working Group Working > Group of the IETF. > > > > Title : Updated Specification of the IPv4 ID Field > > Author(s) : Joe Touch > > Filename : draft-ietf-intarea-ipv4-id-update-07.txt > > Pages : 19 > > Date : 2012-11-27 > > > > Abstract: > > The IPv4 Identification (ID) field enables fragmentation and > > reassembly, and as currently specified is required to be unique > > within the maximum lifetime for all datagrams with a given > > source/destination/protocol tuple. If enforced, this uniqueness > > requirement would limit all connections to 6.4 Mbps. Because > > individual connections commonly exceed this speed, it is clear that > > existing systems violate the current specification. This document > > updates the specification of the IPv4 ID field in RFC791, RFC1122, > > and RFC2003 to more closely reflect current practice and to more > > closely match IPv6 so that the field's value is defined only when a > > datagram is actually fragmented. It also discusses the impact of > > these changes on how datagrams are used. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-intarea-ipv4-id-update > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-intarea-ipv4-id-update-07 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-intarea-ipv4-id-update-07 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area