From owner-multi6@ops.ietf.org Mon Nov 1 07:36:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25404 for ; Mon, 1 Nov 2004 07:36:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CObOT-000Ioj-B8 for multi6-data@psg.com; Mon, 01 Nov 2004 12:34:41 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CObOR-000Inr-PD for multi6@ops.ietf.org; Mon, 01 Nov 2004 12:34:40 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA1CYcxX131232 for ; Mon, 1 Nov 2004 12:34:38 GMT Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA1CYc1V195166 for ; Mon, 1 Nov 2004 13:34:38 +0100 Received: from zurich.ibm.com (sig-9-146-217-68.de.ibm.com [9.146.217.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA33552 for ; Mon, 1 Nov 2004 13:34:37 +0100 Message-ID: <41862D57.3070708@zurich.ibm.com> Date: Mon, 01 Nov 2004 13:34:31 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Draft multi6 agenda Content-Type: multipart/mixed; boundary="------------020408010405000803090709" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------020408010405000803090709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This has been sent in, but of course we can still update it if necessary. Please try to read all the drafts in advance. Brian + Kurtis multi6 co-chairs --------------020408010405000803090709 Content-Type: text/plain; name="multi6-IETF61-agenda.txt" Content-Disposition: inline; filename="multi6-IETF61-agenda.txt" Content-Transfer-Encoding: 7bit Site Multihoming in IPv6 (multi6) Tuesday, November 9 at 0900-1130 Wednesday, November 10 at 1530-1730 =================================== CHAIRS: Brian Carpenter Kurt Lindqvist AGENDA: o Administrivia 5 minutes o Agenda Bashing 5 minutes o WG document status (chairs) 5 minutes (extra time if significant Last Call or IESG issues arise) draft-ietf-multi6-multihoming-threats-01.txt with IESG draft-ietf-multi6-v4-multihoming-02.txt WG Last Call ends Nov. 3 draft-ietf-multi6-things-to-think-about-00.txt WG Last Call ends Nov. 3 draft-ietf-multi6-architecture-02.txt WG Last Call ends Nov. 3 o Design team- presentations and discussion 3 hours total General report from design team (Erik Nordmark) 10 min. Multihoming L3 Shim Approach draft-nordmark-multi6dt-shim-00.txt (Erik Nordmark) 30 min. Hash Based Addresses (HBA) 30 min. draft-bagnulo-multi6dt-hba-00.txt (Marcelo Bagnulo) Functional decomposition of the M6 protocol 30 min. draft-bagnulo-multi6dt-functional-dec-00.txt (Marcelo Bagnulo) Failure Detection and Locator Selection in Multi6 30 min. draft-arkko-multi6dt-failure-detection-00.txt --- end of first session --- Multi6 Application Referral Issues 30 min. draft-nordmark-multi6dt-refer-00.txt (Erik Nordmark) Final discusssion on design team 20 min. o draft-huitema-multi6-addr-selection-00.txt 15 minutes draft-huitema-multi6-ingress-filtering-00.txt (Marcelo Bagnulo) o draft-arifumi-multi6-sas-policy-dist-00.txt 15 minutes (also see draft-hirotaka-dhcp6-sas-option-00.txt) and draft-arifumi-ipv6-nd-source-address-select-01) (Arifumi Matsumoto) o Next steps for the WG (Chairs & AD) until EOT --------------020408010405000803090709-- From owner-multi6@ops.ietf.org Mon Nov 1 07:41:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26019 for ; Mon, 1 Nov 2004 07:41:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CObUT-000KIt-MS for multi6-data@psg.com; Mon, 01 Nov 2004 12:40:53 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CObUS-000KIG-DY for multi6@ops.ietf.org; Mon, 01 Nov 2004 12:40:52 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA1CepxX145334 for ; Mon, 1 Nov 2004 12:40:51 GMT Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA1Ceoqk192838 for ; Mon, 1 Nov 2004 13:40:51 +0100 Received: from zurich.ibm.com (sig-9-146-217-68.de.ibm.com [9.146.217.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA59800 for ; Mon, 1 Nov 2004 13:40:49 +0100 Message-ID: <41862ECB.8050807@zurich.ibm.com> Date: Mon, 01 Nov 2004 13:40:43 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Reminder: multi6 WG Last Calls closing this Wednesday Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just a reminder that three WG Last Calls close on November 3. This is your last chance to express agreement or disagreement with these drafts being forwarded to the IESG. So far we have had some useful comments on the second one, but we'd like to hear more about the other two, if only "yes"! draft-ietf-multi6-architecture-02.txt draft-ietf-multi6-things-to-think-about-00.txt draft-ietf-multi6-v4-multihoming-02.txt Brian + Kurtis multi6 co-chairs From owner-multi6@ops.ietf.org Mon Nov 1 10:41:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21605 for ; Mon, 1 Nov 2004 10:41:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1COeID-00041e-Qe for multi6-data@psg.com; Mon, 01 Nov 2004 15:40:25 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COeI9-00040C-EC for multi6@ops.ietf.org; Mon, 01 Nov 2004 15:40:21 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA1Fe7Q22461; Mon, 1 Nov 2004 16:40:07 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA1Fe7Sj050988; Mon, 1 Nov 2004 16:40:07 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411011540.iA1Fe7Sj050988@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: marcelo bagnulo braun cc: multi6@ops.ietf.org cc: Tuomas Aura Subject: Re: about draft-bagnulo-multi6dt-hba-00.txt In-reply-to: Your message of Thu, 28 Oct 2004 19:22:13 +0200. Date: Mon, 01 Nov 2004 16:40:07 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: > But there is at least > another interpretation... BTW the encoding gives only a static (i.e., > easy to precompute : 0x 30 42 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 > 05 00 > 03 31 00 <48 octets> but please check :-) prefix. ok, i will try to clearify this => note that I've checked this... > Finally I am not convinced a type tag is not required for HBA CGAs, > i.e., > today HBA CGAs are not more usable than CGAs... i am not following this, could you expand a bit? => the question was about type tags for HBAs... finally I believe we don't need them, i.e., HBAs which are not CGAs have no use of type tags, HBAs which are CGAs are covered by the CGA document (draft-ietf-send-cga-06.txt). > PS: I have an OpenSSL module for CGAs (with new/free/dup/d2i/i2d and > check/sign/verify). I can send it to who'd like to extend it to HBA > (I'm using the standard BSD licence). It should be easy because if I've > understood the design the multi-prefix extension is an extension field? we are planning to implement HBA, so this would be really helpful. I will contact you later. => I had some free time in this long weekend so I wrote the code and now I have some new comments: - draft-ietf-send-cga-06.txt is not clear enough about where the extension fields are included in the hash (here the multi-prefix extension) : ... Note that the hash values are computed over the entire CGA Parameters data structure, including any unrecognized extension fields. but: 2. Concatenate from left to right the modifier, 9 zero octets, and the encoded public key. Execute the SHA-1 algorithm on the concatenation. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2. and: 5. Concatenate from left to right the final modifier value, the subnet prefix, the collision count and the encoded public key. Execute the SHA-1 algorithm on the concatenation. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1. So in draft-bagnulo-multi6dt-hba-00.txt the extension is in Hash2 (good decision) but not in Hash1 (does it matter?): 3. Concatenate from left to right the Modifier, 9 zero octets, the encoded public key or the encoded Extended Modifier (if no public key was provided) and the Multi-Prefix Extension. Execute the SHA-1 algorithm on the concatenation. Take the 112 leftmost bits of the SHA-1 hash value. The result is Hash2. and: 6.1. Concatenate from left to right the final modifier value, Prefix[i], the collision count, the encoded public key or the encoded Extended Modifier (if no public key was provided). Execute the SHA-1 algorithm on the concatenation. Take the 64 leftmost bits of the SHA-1 hash value. The result is Hash1[i]. Please fix this with Tuomas! - the second point is about the Ext Type (TBD IANA): we have to propose a common value in order to get interoperability (and examples :-). - the last point is about the collision count: I believe it should be per HBA not global as described: 5. Set the 8-bit collision count to zero. 6. For i=1 to n do ... 6.4. Perform duplicate address detection if required. If an address collision is detected, increment the collision count by one and go back to step (6). However, after three collisions, stop and report the error. I propose to put the 5 in the first step of 6 and go back to the next step (currently 6.1 but it should become 6.2) when DAD fails. From owner-multi6@ops.ietf.org Mon Nov 1 13:52:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17405 for ; Mon, 1 Nov 2004 13:52:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1COhFz-0008SA-RJ for multi6-data@psg.com; Mon, 01 Nov 2004 18:50:19 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COhFy-0008Rl-Qt for multi6@ops.ietf.org; Mon, 01 Nov 2004 18:50:18 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA1IoCNH006677; Mon, 1 Nov 2004 11:50:13 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iA1IoAJQ001500; Mon, 1 Nov 2004 19:50:11 +0100 (MET) Message-ID: <41868593.3030009@sun.com> Date: Mon, 01 Nov 2004 10:50:59 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> <41837CBC.40102@zurich.ibm.com> In-Reply-To: <41837CBC.40102@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: >> You're right in the general case. However, one could further constrain >> flow label allocation for the hosts that implement multi6 so that for >> multi6 packets the receiver wouldn't have to compare the locators but >> only use the flow label. > > > No, that doesn't work, because two quite independent source hosts might > choose the same flow label. You have no choice but to look at the source > locator as well as the label. It would work with the proper constraints. If some future standard where to say that a host should not send a multi6 packet unless the flow label had been "approved" (or allocated) by the intended receiver, the receiver could ensure that the flows of multi6 packets it receives each have a different flow label. Whether we want to do this is a different point (and I don't think we should be overloading the flow label at all). > Well, I think you could reasonably require that a sender never uses the > same > flow label twice at the same time (that is more constraining than the > global > rule, but probably not a problem in a 20 bit space). Yes, and "same time" needs to take into account how long multi6 state is allowed to remain on a receiver. > But you don't need to. > You simply apply the normal rule - make it unique per source and dest ULID > pair. That should make it unique across the {{source locator},{dest > locator}} > set anyway, and thats's all you need. My example should that your conclusion doesn't hold. This is because the ULID->locator set mapping 1) isn't known when communication is started and 2) different ULIDs can map to the same locator sets (or map to locator sets that are partially overlapping). Erik From owner-multi6@ops.ietf.org Tue Nov 2 02:01:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05841 for ; Tue, 2 Nov 2004 02:01:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1COse0-000Hjc-Bh for multi6-data@psg.com; Tue, 02 Nov 2004 06:59:52 +0000 Received: from [203.178.142.146] (helo=mail.sfc.wide.ad.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COsdy-000Hhz-31 for multi6@ops.ietf.org; Tue, 02 Nov 2004 06:59:51 +0000 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 9A6174C084 for ; Tue, 2 Nov 2004 15:59:49 +0900 (JST) Date: Tue, 2 Nov 2004 16:02:26 +0900 From: Thierry Ernst To: Multi6 Subject: Some comments on draft-ietf-multi6-v4-multihoming-02.txt Message-Id: <20041102160226.2d6c9476.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, This is the 1st time I read this draft, and, to be honest, I don't really understand the value of the document. IMHO, more text and details would help to fully meet the objectives of the draft. But I don't have any suggestions besides the following (mostly) editorial comments. - A table of contents is missing Introduction - a sentence detailing the structure of the document (from section 2 till end) would help. - particularly, the abstract nor the introduction give me a hint of the content of section 5. Section 2: - all terms but one (mullti-addressed) are defined in RFC3582, why not saying it ? (I'm OK with repeating the definitions, though) Section 4.3 - I don't get the meaning of "having their upstreams remove those on announcement". Their upstreams what ? The same occurs in orher parts of the text. Section 5 - what is the purpose of this section ? It says "analysis of the features...". Is this an analysis which goes through the goals/requirements defined in RFC3582. May sound like it since the "Simplicity", "Transport-Layer Survivability" etc are defined in RFC3582. (I know draft-v4-multihoming is about the "IPv4 experience", but it's not so clear from reading the text which document inherits from the other one, so this paragraph or Section 1 may be improved). Section 5.4 - Typo in "A single-home client a multi-homed site" Section 6.1 - Typo: remove 's' in 'might explains' - higher growth: in what ? In the (number of) the multihomed sites ? - I would also suggest "state" -> amount of state. It might be useful to specify what kind of state, for the novice reader (unless we assume this is obvious to the reader). - no need for a section "6.1" if there is no section 6.2. Thierry. From owner-multi6@ops.ietf.org Tue Nov 2 03:31:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26115 for ; Tue, 2 Nov 2004 03:31:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1COu3j-0003cf-Uz for multi6-data@psg.com; Tue, 02 Nov 2004 08:30:31 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COu3i-0003c7-7y for multi6@ops.ietf.org; Tue, 02 Nov 2004 08:30:30 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA28USxD020534; Tue, 2 Nov 2004 08:30:28 GMT Received: from sihl.zurich.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA28URwk119066; Tue, 2 Nov 2004 09:30:28 +0100 Received: from zurich.ibm.com (sig-9-145-129-191.de.ibm.com [9.145.129.191]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA14200; Tue, 2 Nov 2004 09:30:25 +0100 Message-ID: <418745A0.4040204@zurich.ibm.com> Date: Tue, 02 Nov 2004 09:30:24 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Thierry Ernst CC: Multi6 Subject: Re: Some comments on draft-ietf-multi6-v4-multihoming-02.txt References: <20041102160226.2d6c9476.ernst@sfc.wide.ad.jp> In-Reply-To: <20041102160226.2d6c9476.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thierry, The purpose of the document (which is one of our chartered deliverables) is only to write down existing practice. But I don't think any of us believe that has enough value to actually add more text and details (i.e. do more work :-). Thanks for the comments. Brian Thierry Ernst wrote: > Dear all, > > This is the 1st time I read this draft, and, to be honest, I don't > really understand the value of the document. IMHO, more text and details > would help to fully meet the objectives of the draft. But I don't have > any suggestions besides the following (mostly) editorial comments. > > > - A table of contents is missing > > > Introduction > > - a sentence detailing the structure of the document (from section 2 > till end) would help. > > - particularly, the abstract nor the introduction give me a hint of the > content of section 5. > > Section 2: > > - all terms but one (mullti-addressed) are defined in RFC3582, why not > saying it ? (I'm OK with repeating the definitions, though) > > > Section 4.3 > > - I don't get the meaning of "having their upstreams remove those on > announcement". Their upstreams what ? The same occurs in orher parts of > the text. > > Section 5 > > - what is the purpose of this section ? It says "analysis of the > features...". Is this an analysis which goes through the > goals/requirements defined in RFC3582. May sound like it since the > "Simplicity", "Transport-Layer Survivability" etc are defined in > RFC3582. (I know draft-v4-multihoming is about the "IPv4 experience", > but it's not so clear from reading the text which document inherits from > the other one, so this paragraph or Section 1 may be improved). > > > Section 5.4 > > - Typo in "A single-home client a multi-homed site" > > Section 6.1 > > - Typo: remove 's' in 'might explains' > > - higher growth: in what ? In the (number of) the multihomed sites ? > > - I would also suggest "state" -> amount of state. It might be useful to > specify what kind of state, for the novice reader (unless we assume > this is obvious to the reader). > > - no need for a section "6.1" if there is no section 6.2. > > > Thierry. > From owner-multi6@ops.ietf.org Tue Nov 2 05:14:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03398 for ; Tue, 2 Nov 2004 05:14:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1COvei-000KM5-92 for multi6-data@psg.com; Tue, 02 Nov 2004 10:12:48 +0000 Received: from [203.178.142.146] (helo=mail.sfc.wide.ad.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COveh-000KLK-2q for multi6@ops.ietf.org; Tue, 02 Nov 2004 10:12:47 +0000 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 80D6B4C084 for ; Tue, 2 Nov 2004 19:12:44 +0900 (JST) Date: Tue, 2 Nov 2004 19:15:22 +0900 From: Thierry Ernst To: Multi6 Subject: Few comments on draft-ietf-multi6-architecture-02 Message-Id: <20041102191522.0a5b3cab.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, Here are a few comments on draft-ietf-multi6-architecture-02 Section 2. - Figure 1. only shows a site with 2 transit providers A and B. Wouldn't it be useful to illustrate the case where the network is "multi-attached" ? Then, wouldn't be useful to state if this draft considers this specific case or not ? - What is the definition of "seamlessly supported" ? My mobility background may not help me to undertand this term in the same way as it is assumed in this document. I would use "Transparency". It's probably a good idea to uniformize the terms between the mobility and the multihoming fields, given the many identical issues. Section 4.1: - typo "remote domain domains" - why the number 10**7 is used, and not, say, 10**10 ? Can we consider the network everyone will have at home a site ? Such network would most likely be multihomed to distinct ISPs. Section 4.2 - I would add NEMO Basic Support (draft-ietf-nemo-basic-support-03.txt, together with MIP6 (although there is no Route Optimization procedure in NEMO Basic Support). [BTW, just being curious, can't we consider a NEMO multihomed to 2 distincts ISPs as a site ? cf draft-ietf-nemo-multihoming-issues-01.txt] Section 4.3 - typo in "...the only viable destination address to use the one that is based ..." Section 4.6 - "on packet ingress to the site": it that good English ? Is "ingress" used as a verb ? - in "a large number of associated security considerations" shouldn't it be "issues" instead of "considerations" ? - "header rewriting on site exit is for" -> shouldn't it be "on site-exit router" ? - typo "the this would" Section 5 - missing word around "there" in "to transform the ULP PDU to include locator information there is an associated requirement" Section 5.3.1 - Blank line missing before paragraphs "ICMP Triggers", "Routing Triggers", ... Section 5.3.2 - I'm not sure the following sentence is fine: "An implication of this selection process is that the host s that path selection policy ..." - "select components": shouldn't it be "selected components" ? - The word "IN" shouldn't be capitalized Section 5.3.3 - in "...when all flows to and from a particular destination has stopped": should be "have stopped" Thierry. From owner-multi6@ops.ietf.org Tue Nov 2 06:36:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08968 for ; Tue, 2 Nov 2004 06:36:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1COwvv-0006jX-HV for multi6-data@psg.com; Tue, 02 Nov 2004 11:34:39 +0000 Received: from [203.178.142.146] (helo=mail.sfc.wide.ad.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COwvu-0006jC-Ji for multi6@ops.ietf.org; Tue, 02 Nov 2004 11:34:38 +0000 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 168DD4C08C for ; Tue, 2 Nov 2004 20:34:38 +0900 (JST) Date: Tue, 2 Nov 2004 20:37:15 +0900 From: Thierry Ernst To: Multi6 Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt Message-Id: <20041102203715.680b510f.ernst@sfc.wide.ad.jp> In-Reply-To: <41812616.9090506@cisco.com> References: <4176E3B7.4090806@zurich.ibm.com> <20041028160213.GG15055@login.ecs.soton.ac.uk> <41812616.9090506@cisco.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, About mobility, something that I would like to add in the draft in section 2.4 and/or section 6.6: - In 2.4: I'm wondering here again if mentioning MIP6 without mentioning NEMO Basic Support is sufficient. A mobile network as defined in the NEMO WG may benefit from the work done in multi6. Reversely, the work done by the NEMO WG may benefit to MULTI6 (if the mobility-support approach path is followed by the Multi6 group). - In 6.5: I would request to add "NEMO sites" (ad-hoc sites is currently mentioned, but not NEMO sites). Also, I think it's a good idea to add "nested-NEMO sites". Since this document is about "things to think about", it wouldn't hurt to these 2. Thierry. From owner-multi6@ops.ietf.org Tue Nov 2 07:23:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12239 for ; Tue, 2 Nov 2004 07:23:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1COxgO-000E4N-Oj for multi6-data@psg.com; Tue, 02 Nov 2004 12:22:40 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COxgN-000E42-Mc for multi6@ops.ietf.org; Tue, 02 Nov 2004 12:22:40 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA2CLvxX007954 for ; Tue, 2 Nov 2004 12:22:01 GMT Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA2CLuRG191292 for ; Tue, 2 Nov 2004 13:21:56 +0100 Received: from zurich.ibm.com (sig-9-145-129-191.de.ibm.com [9.145.129.191]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA54670 for ; Tue, 2 Nov 2004 13:21:55 +0100 Message-ID: <41877BE1.7070706@zurich.ibm.com> Date: Tue, 02 Nov 2004 13:21:53 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Scribes needed! Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just a reminder that we need a volunteer to take minutes and a couple of volunteers to act as jabber scribes, for the two multi6 sessions next week. Brian From owner-multi6@ops.ietf.org Tue Nov 2 09:09:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22313 for ; Tue, 2 Nov 2004 09:09:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1COzKo-0004bT-V0 for multi6-data@psg.com; Tue, 02 Nov 2004 14:08:30 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1COzKn-0004au-6q for multi6@ops.ietf.org; Tue, 02 Nov 2004 14:08:29 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA18QqN3044124 for ; Mon, 1 Nov 2004 08:26:52 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA18QqY5048656 for ; Mon, 1 Nov 2004 08:26:52 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA18Qpcs004429 for ; Mon, 1 Nov 2004 08:26:52 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA18QpV8004420; Mon, 1 Nov 2004 08:26:51 GMT Received: from zurich.ibm.com (sig-9-146-217-68.de.ibm.com [9.146.217.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA70686; Mon, 1 Nov 2004 09:26:50 +0100 Message-ID: <4185F340.2080701@zurich.ibm.com> Date: Mon, 01 Nov 2004 09:26:40 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: marcelo bagnulo braun CC: Erik Nordmark , Multi6 Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> In-Reply-To: <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo braun wrote: >>> Good news. This is wrong (and I didn't realise it when analyzing NOID). >>> Flow Labels are not unique on their own and cannot be used for >>> anything on their own. You must always lookup a 3tuple.But if the >>> received {Flow Label, Source Locator, Dest Locator} is in the set >>> {Flow Label, {Source Locators}, {Dest Locators}} corresponding to >>> a particular {Flow Label, Source ULID, Dest ULID} 3tuple, the shim >>> *knows* that it is a multi6 packet. >> >> >> If the {flow label, src locator, dst locator} is used to identify the >> state then you are right. But that prevents a possible optimization >> with changing locator sets (think mobility) by requiring that multi6 >> signaling be complete to tell the peer of the new locator before that >> locator can be used as the source. >> > > well, but in this case, there is also some security information nneded > to authenticate the new locator, so the receiver will have additional > information for the demux of this packet i guess. Exactly. I'm kind of assuming we have something like HBA in place, so prior knowledge of all locators is needed anyway. Brian From owner-multi6@ops.ietf.org Tue Nov 2 10:39:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02088 for ; Tue, 2 Nov 2004 10:39:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CP0jt-000Ir8-FZ for multi6-data@psg.com; Tue, 02 Nov 2004 15:38:29 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CP0jl-000Iq7-Jv for multi6@ops.ietf.org; Tue, 02 Nov 2004 15:38:22 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8522A2FCFB; Tue, 2 Nov 2004 16:38:20 +0100 (CET) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 6D4BF2FCF8; Tue, 2 Nov 2004 16:38:20 +0100 (CET) In-Reply-To: <4185F340.2080701@zurich.ibm.com> References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> <4185F340.2080701@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3AB79A56-2CE5-11D9-8458-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 , Erik Nordmark From: marcelo bagnulo braun Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt Date: Tue, 2 Nov 2004 16:38:22 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 01/11/2004, a las 9:26, Brian E Carpenter escribi=F3: > marcelo bagnulo braun wrote: >>>> Good news. This is wrong (and I didn't realise it when analyzing=20 >>>> NOID). >>>> Flow Labels are not unique on their own and cannot be used for >>>> anything on their own. You must always lookup a 3tuple.But if the >>>> received {Flow Label, Source Locator, Dest Locator} is in the set >>>> {Flow Label, {Source Locators}, {Dest Locators}} corresponding to >>>> a particular {Flow Label, Source ULID, Dest ULID} 3tuple, the shim >>>> *knows* that it is a multi6 packet. >>> >>> >>> If the {flow label, src locator, dst locator} is used to identify=20 >>> the state then you are right. But that prevents a possible=20 >>> optimization with changing locator sets (think mobility) by=20 >>> requiring that multi6 signaling be complete to tell the peer of the=20= >>> new locator before that locator can be used as the source. >>> >> well, but in this case, there is also some security information=20 >> nneded to authenticate the new locator, so the receiver will have=20 >> additional information for the demux of this packet i guess. > > Exactly. I'm kind of assuming we have something like HBA in place, > so prior knowledge of all locators is needed anyway. > Just one additional nit... note that HBAs are particularly restrictive in this aspect, since all=20 locators need to be known a priori. However, even if you use=20 alternative schemes that don't impose such restriction, like CGAs, you=20= still need to add security information at least in the same packet that=20= carries the new locator. So even if not all locators need to be known a priori, packets with new=20= locators will have to carry additional information to validate the=20 locator (e.g. a signature with the private key associated to a cga) regards, marcelo > Brian > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Tue Nov 2 10:54:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03393 for ; Tue, 2 Nov 2004 10:54:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CP0yU-000LJY-43 for multi6-data@psg.com; Tue, 02 Nov 2004 15:53:34 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CP0yM-000LI1-Sl for multi6@ops.ietf.org; Tue, 02 Nov 2004 15:53:27 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D82572FD35; Tue, 2 Nov 2004 16:53:23 +0100 (CET) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id C21D22FD2C; Tue, 2 Nov 2004 16:53:23 +0100 (CET) In-Reply-To: <20041102191522.0a5b3cab.ernst@sfc.wide.ad.jp> References: <20041102191522.0a5b3cab.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <551A450C-2CE7-11D9-8458-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: Multi6 From: marcelo bagnulo braun Subject: Re: Few comments on draft-ietf-multi6-architecture-02 Date: Tue, 2 Nov 2004 16:53:26 +0100 To: Thierry Ernst X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Thierry, i just want to make a comment about one of the points that you are=20 considering (this may be OT for this list though... but i hope that the=20= chairs will let me know when to shut up :-) El 02/11/2004, a las 11:15, Thierry Ernst escribi=F3: > [BTW, just being curious, can't we consider a NEMO multihomed to 2 > distincts ISPs as a site ? cf=20 > draft-ietf-nemo-multihoming-issues-01.txt] > I am not sure that all the multihomed nemos can easily fall under the=20 definition of a multihomed site. IMHO, there are cases where it is clearly so, and that the multi6=20 solution will provide a solution for the multihomed nemo, while in some=20= other cases, i am not so sure. For instance, suppose a nemo that has a multihomed home network. So the=20= nemo has two prefixes, one per ISP of the home network. In this case i=20= guess that it is clear that the multi6 solution should apply to this=20 network, i guess. The same case could be when the nemo has two home networks (which i=20 guess that is the case that you are considering) I mean in all these cases, the point is that the multihoming doesn't=20 occur between the nemo and the fixed network, but between the=20 attachment of the home network(s) and the internet. I guess that in=20 those cases, the multi6 solution should apply. However, when we are considering a nemo that has multiple attachments=20 points, and for instance only one nemo prefix, then the fundamental=20 assumption of multi6 solution is no longer valid, since the nemo has a=20= single prefix. I guess that in these cases, the usefulness of the=20 multi6 solution will diminish. But anyway, i fell that it is very important to determine which parts=20 of the nemo multihoming problem can be addressed with multi6 and which=20= parts will require additional tools. Regards, marcelo > Section 4.3 > - typo in "...the only viable destination address to use the one that=20= > is > based ..." > > Section 4.6 > - "on packet ingress to the site": it that good English ? Is = "ingress" > used as a verb ? > > - in "a large number of associated security considerations" shouldn't=20= > it > be "issues" instead of "considerations" ? > > - "header rewriting on site exit is for" -> shouldn't it be "on > site-exit router" ? > > - typo "the this would" > > Section 5 > - missing word around "there" in "to transform the ULP PDU to include > locator information there is an associated requirement" > > Section 5.3.1 > - Blank line missing before paragraphs "ICMP Triggers", "Routing=20 > Triggers", ... > > Section 5.3.2 > - I'm not sure the following sentence is fine: "An implication of this > selection process is that the host s that path selection policy ..." > > - "select components": shouldn't it be "selected components" ? > > - The word "IN" shouldn't be capitalized > > Section 5.3.3 > - in "...when all flows to and from a particular destination has > stopped": should be "have stopped" > > > Thierry. > > > > > > > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Tue Nov 2 11:48:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09775 for ; Tue, 2 Nov 2004 11:48:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CP1o5-0004HS-OR for multi6-data@psg.com; Tue, 02 Nov 2004 16:46:53 +0000 Received: from [217.213.237.205] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CP1nu-0004G7-SR for multi6@ops.ietf.org; Tue, 02 Nov 2004 16:46:43 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id B871863E5C4; Tue, 2 Nov 2004 15:00:23 +0100 (CET) In-Reply-To: <20041102160226.2d6c9476.ernst@sfc.wide.ad.jp> References: <20041102160226.2d6c9476.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <8418573B-2CD7-11D9-AA47-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Kurt Erik Lindqvist Subject: Re: Some comments on draft-ietf-multi6-v4-multihoming-02.txt Date: Tue, 2 Nov 2004 15:00:12 +0100 To: Thierry Ernst X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (as co-author) On 2004-11-02, at 08.02, Thierry Ernst wrote: > - A table of contents is missing Good catch. I guess that will get caught in the nits check. Thanks! > Introduction > > - a sentence detailing the structure of the document (from section 2 > till end) would help. Do you think the document is long enough to need this? > - particularly, the abstract nor the introduction give me a hint of the > content of section 5. Ok. > Section 2: > > - all terms but one (mullti-addressed) are defined in RFC3582, why not > saying it ? (I'm OK with repeating the definitions, though) As they are so few I thought it made it more readable to repeat them. > Section 4.3 > > - I don't get the meaning of "having their upstreams remove those on > announcement". Their upstreams what ? The same occurs in orher parts > of > the text. "those" refer to the private ASes. > Section 5 > > - what is the purpose of this section ? It says "analysis of the > features...". Is this an analysis which goes through the > goals/requirements defined in RFC3582. May sound like it since the > "Simplicity", "Transport-Layer Survivability" etc are defined in > RFC3582. (I know draft-v4-multihoming is about the "IPv4 experience", > but it's not so clear from reading the text which document inherits > from > the other one, so this paragraph or Section 1 may be improved). Originally these where written as compliments to each other. Not sure if that still holds to 100%. > Section 5.4 > > - Typo in "A single-home client a multi-homed site" Thanks. > Section 6.1 > > - Typo: remove 's' in 'might explains' Thanks! > - higher growth: in what ? In the (number of) the multihomed sites ? yes, and to me that is pretty obvious from that sentence. > - I would also suggest "state" -> amount of state. It might be useful > to > specify what kind of state, for the novice reader (unless we assume > this is obvious to the reader). Agreed. > - no need for a section "6.1" if there is no section 6.2. Thanks! As the table of contents is a show-stopper for the nits checking, I need to make an update anyway and will include the other remarks. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQYeS9qarNKXTPFCVEQJxqwCglKDNM7CuZvBhoNSPNRA+rO9qhl4AoKX8 M0szxsxv5mOTyLuwmQiWJJPq =YDbX -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Nov 2 12:51:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17157 for ; Tue, 2 Nov 2004 12:51:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CP2n9-000E6c-Az for multi6-data@psg.com; Tue, 02 Nov 2004 17:49:59 +0000 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CP2n5-000E6D-7Q for multi6@ops.ietf.org; Tue, 02 Nov 2004 17:49:55 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA18TNBU104072; Mon, 1 Nov 2004 08:29:24 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA18TNZQ124774; Mon, 1 Nov 2004 08:29:23 GMT Received: from zurich.ibm.com (sig-9-146-217-68.de.ibm.com [9.146.217.68]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA23166; Mon, 1 Nov 2004 09:27:56 +0100 Message-ID: <4185F387.9090904@zurich.ibm.com> Date: Mon, 01 Nov 2004 09:27:51 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: marcelo bagnulo braun CC: Multi6 Subject: Re: I-D ACTION:draft-bagnulo-multi6dt-functional-dec-00.txt References: <200410191147.HAA14115@ietf.org> <41823C6A.8090408@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit marcelo bagnulo braun wrote: > Hi Brian, > > this draft is very draft. > Its goal is mainly to present a protocol walkthrough that considers the > different types of messages that can be used in a multi6 protocol. > several choices need to be made. I guess that when we decide which are > the preffered options, we will be able to provide a more complete analysis > do you think that for a prelimary analysis is there something very big > that is missing in the draft? No, you can assume that when I think that, I will always tell you :-) Brian > > thanks, marcelo > El 29/10/2004, a las 14:49, Brian E Carpenter escribió: > >> Just one comment at the moment: this draft doesn't cover >> *all* the functional components detailed in Section 6 >> of draft-ietf-multi6-architecture-02.txt. >> That should probably be noted in the introduction. >> >> (Incidentally, reference [3] points to an obsolete >> draft.) >> >> Brian >> >> > ------------------------------------------ > Please note that my former email address > mbagnulo@ing.uc3m.es is no longer in use > Please send mail to: > marcelo at it dot uc3m dot es > ------------------------------------------ > > > From owner-multi6@ops.ietf.org Tue Nov 2 19:29:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05963 for ; Tue, 2 Nov 2004 19:29:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CP90T-000Jyn-DF for multi6-data@psg.com; Wed, 03 Nov 2004 00:28:09 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CP90S-000JyW-Ix for multi6@ops.ietf.org; Wed, 03 Nov 2004 00:28:08 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iA30S1s3005677; Tue, 2 Nov 2004 16:28:01 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iA30RwJQ025775; Wed, 3 Nov 2004 01:27:59 +0100 (MET) Message-ID: <4188263E.7060009@sun.com> Date: Tue, 02 Nov 2004 16:28:46 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun CC: Brian E Carpenter , Multi6 Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> <4185F340.2080701@zurich.ibm.com> <3AB79A56-2CE5-11D9-8458-000D93ACD0FE@it.uc3m.es> In-Reply-To: <3AB79A56-2CE5-11D9-8458-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo braun wrote: > Just one additional nit... > note that HBAs are particularly restrictive in this aspect, since all > locators need to be known a priori. However, even if you use alternative > schemes that don't impose such restriction, like CGAs, you still need to > add security information at least in the same packet that carries the > new locator. That requirement isn't obvious to me so I think it would warrant discussion. The issue is whether it would be ok for the multi6 shim to pass a packet to the ULP when the source locator has not been verified as belonging to the peer. We all agree that we need to do such verification before *sending* packets to a new locator, but what about just accepting the packet? Things to take into account: In today's Internet, when there is no ingress filtering anybody can spoof the source IP address and the packets will be passed by IP to the ULP. However, in today's Internet when there is some ingress filtering it is possible to restrict the nodes which can actually spoof the source IP address to those that are close to the path between the real location of the IP address and the receiving node. If a host wants to prevent packet injection attacks today (such as spoofed RCP RST packets, if it wants to prevent it from all nodes and not depend on ingress filtering, wouldn't it use IPsec? Erik From owner-multi6@ops.ietf.org Wed Nov 3 00:41:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29258 for ; Wed, 3 Nov 2004 00:41:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPDsJ-000BGt-Vh for multi6-data@psg.com; Wed, 03 Nov 2004 05:40:03 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPDsI-000BGL-HC for multi6@ops.ietf.org; Wed, 03 Nov 2004 05:40:03 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA35dtF03854; Wed, 3 Nov 2004 07:39:59 +0200 Date: Wed, 3 Nov 2004 07:39:55 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: Multi6 Subject: Re: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt In-Reply-To: <4176E2F5.10008@zurich.ibm.com> Message-ID: References: <4176E2F5.10008@zurich.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 21 Oct 2004, Brian E Carpenter wrote: > It is proposed to forward > draft-ietf-multi6-architecture-01.txt > to the IESG for approval as an Informational RFC > > Any final comments must be sent to the WG list at multi6@ops.ietf.org > within two weeks, i.e. at the latest on November 3, 2004. I've two bigger concerns here. While they aren't changes which must be adopted, I think doing so would improve the document's readability a lot and help in clarifying its scope, so it might be worth the effort.. 1) The document is rather long and conversational in tone. That's probably not a big problem, but I found it difficult to read, because there was not a clear structure in the document. In particular, section 4.3 "Multi-homing: Identity Considerations" (which was discussing generic issues for further subsections) seemed ill placed to section 4. More appropriate place for quite a bit of this discussion would be under section 5, possible under 5.3.2 in particular. I'd like to reduce the amount of generic discussion in section 4, just making it lay out the different approarches in sufficient detail, and refer to the following sections for lengthier (and more structured) discussion of the details. There are also some rather long sections or long paragraphs, which could be split into more digestible pieces. E.g., section 5.1 could possibly be split into subsections based on the approach. That could give more structure and make the document easier to consume. 2) I've griped before about this document not having enough 'truth in advertising', i.e., it says it describes the architectural approaches to multihoming in IPv6, but does not go in sufficient detail to e.g., traffic engineering possibilities (the mention of this has been sprinkled along the draft though). Still, I think this is a bit of misleading and we should try to avoid this. I'd just make it clearer that this document focuses on connection survivability and not the whole multihoming problem space. How to go about this (just an idea): - a note at the end of section 3 (or after the list quoted from 3582) that the focus is on ensuring connection survivability - rename section 4, Approaches to Multi-Homing, to include a note about connection survivability and the like - note in section 4.1 that this also provides more than just conn. surv. - maybe some minor tweaks in the abstract, introduction and the title mostly editorial ---------------- In addition, [2] documents further considerations for IPv6 multi-homing. Again, the reader is referred to this document for the detailed enumeration of these considerations. The general topic areas considered in this study include: o interaction with routing systems, o aspects of a split between end-point-identifier and forwarding locator, o changes to packets on the wire, and o the interaction between names, endpoints and the DNS. ==> does this call for minor edits to update to the latest think-about-... organization? All transit providers for the site accept a prefix advertisement from the multi-homed site, and advertise this prefix globally in the inter-domain routing table. ==> s/accept/need to accept/ (a slightly different nuance)? The possible application of the MIPv6 protocol to the multihoming problem would be to use BU messages to convey information about alternative addresses to be used after the outage. ==> clarify: s/convey/convey prior to the outage/ ? the network. IN the latter case there is also the consideration of ==> s/IN/In/ IPSEC is necessary in this case, in order to avoid making changes to ==> s/IPSEC/IPsec/ changes to the end-to-end interaction, as both endS of the ==> s/endS/ends/ reasonable to assume that the identity assignation is not necessarily ==> s/assignation/assignment/ ? 6.1 Establishing Session State What form of token is passed to the transport layer from the upper level protocol element as an identification of the local protocol stack? What form of token is passed to the transport layer from the upper level protocol element as an identification of the remote session target? ==> could there be an empty line between the questions, so it would be more readable ? [4] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. Nordmark, "Mobile IP version 6 Route Optimization Security Design Background", Work in progress: Internet Drafts draft-ietf-mip6-ro-sec-01.txthttp://bgp.potaroo.net/ietf/idref/ draft-ietf-multi6-things-to-think-abou, July 2004, . ==> there's some crap here ('draft-ietf-multi6-things-to-think-abou'). 10 Informative References ==> shouldn't some of these really be normative references ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Nov 3 02:28:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03588 for ; Wed, 3 Nov 2004 02:28:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPFXg-000PHc-OH for multi6-data@psg.com; Wed, 03 Nov 2004 07:26:52 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPFXf-000PHP-LT for multi6@ops.ietf.org; Wed, 03 Nov 2004 07:26:52 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA37Qje27763; Wed, 3 Nov 2004 09:26:46 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 09:24:22 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA37OMmX000528; Wed, 3 Nov 2004 09:24:22 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00oyBSjc; Wed, 03 Nov 2004 09:24:19 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA37D2a07840; Wed, 3 Nov 2004 09:13:03 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 09:12:34 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 09:12:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: WGLC comments on draft-ietf-multi6-architecture-02.txt Date: Wed, 3 Nov 2004 09:12:35 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D431F44@esebe056.ntc.nokia.com> Thread-Topic: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt Thread-Index: AcS28mWKDTU/ABXRTNCdwGJP0IOi7ADV12nQ From: To: , X-OriginalArrivalTime: 03 Nov 2004 07:12:35.0875 (UTC) FILETIME=[7EAB7730:01C4C174] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Geoff, I support this draft going forward, I have a couple of issues, some = questions but mostly nits. thanks, John Issues: =3D=3D=3D=3D=3D=3D 1) This document would benefit from a terminology section. Perhaps a = reference to the Terminology section in RFC3582 as well. Terminology to = include would be "session resilience"; add ULP, LLP and EIP; as well as others. 2) Section 5.3.1 - Triggering Locator Switches. Inserting an = information reference to = http://www.ietf.org/internet-drafts/draft-iab-link-indications-00.txt = could be useful. It seems to me that a crucial part of any multihoming = solution will be the triggering of a multihoming event. I don't think we need to = explicitly list all of the potential triggers, but let the astute reader = catch-up on some related work. Questions: =3D=3D=3D=3D=3D=3D=3D=3D=3D 1) Section 4.3: "The intent of multi-homing in the IPv6 domain is to achieve a comparable functional outcome for multi-homed sites without an associated additional load being imposed on the routing system." This sentence seems incomplete, a comparable functional outcome=20 as compared to what? 2) 1st line, page 8: "In addition to this objective of session resilience across network reachability changes," ... I had a hard time parsing this at first, perhaps the coffee didn't kick in. Is it: "In addition to this objective of session resilience across network reachability changes," ... or "In addition to this objective of session resilience during network reachability changes," ... or "In addition to this objective of session resilience in spite of = network reachability changes," ... Nits: =3D=3D=3D=3D 1) Spacing problem, but this seems to be a Secretariat problem. 2) Page 6: "The environment of multi-homing is one that is intended to provide sufficient support to local hosts so as to allow local hosts to exchange IP packets with remote hosts, such that this exchange of packets is to be seamlessly supported across dynamic changes in connectivity." Change 'seamlessly' to another term, perhaps 'transparently'? = Seamlessly has a lot of mobility baggage, so it might be good to avoid that term. 3) Expand first usage of ULP in section 4.2. 4) Section 4.3 (and others) "vs" should be "vs." 5) Section 5.3.1 - adding a new line before each bullet would increase = readability. 6) "5.3.5 Dynamic Capability Negotiation The common aspect of these approaches is that they all involve changes to the end-to-end interaction, as both endS of the" endS -> ends 7) Section 6 - insert a blank line between questions; otherwise it is = somewhat=20 awkward to read. From owner-multi6@ops.ietf.org Wed Nov 3 02:28:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03696 for ; Wed, 3 Nov 2004 02:28:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPFY6-000PIk-UN for multi6-data@psg.com; Wed, 03 Nov 2004 07:27:18 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPFY5-000PIS-OW for multi6@ops.ietf.org; Wed, 03 Nov 2004 07:27:18 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA37RFl09797 for ; Wed, 3 Nov 2004 09:27:16 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 09:27:03 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA37R3X2028663 for ; Wed, 3 Nov 2004 09:27:03 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 005S7JIc; Wed, 03 Nov 2004 09:26:46 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA37QkS19727 for ; Wed, 3 Nov 2004 09:26:46 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 09:26:46 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 09:26:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt Date: Wed, 3 Nov 2004 09:26:45 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D09584F@esebe056.ntc.nokia.com> Thread-Topic: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt Thread-Index: AcS28mWKDTU/ABXRTNCdwGJP0IOi7AKgoKRw From: To: X-OriginalArrivalTime: 03 Nov 2004 07:26:46.0090 (UTC) FILETIME=[796FFAA0:01C4C176] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Elliot, > It is proposed to forward > draft-ietf-multi6-architecture-01.txt > to the IESG for approval as an Informational RFC >=20 > Any final comments must be sent to the WG list at multi6@ops.ietf.org > within two weeks, i.e. at the latest on November 3, 2004. I support this draft going forward, I have some comments and a few nits, however: 1) Abstract: "This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6." I'm not sure the document 'specifies' - it discusses or contains a set of questions ... 2) Introduction "At the time of this writing there are quite a number of proposed solutions to the problem of multihoming within IPv6, and related problems such as the locator/identifier split." Just thinking about when this becomes an RFC, this text will sound odd. Perhaps it would be better to say something like: "Architectural Approaches to Multi-Homing for IPv6" contains a number=20 of approaches to the problem of multihoming within IPv6, and related problems such as the locator/identifier split. 3) Section 3.12: "How does your solution interact with Son-Of-Sitelocal (whatever that will be)?" I found this somewhat confusing. One could guess that a locator/ identifier solution may create a new level of 'scoping.' Howabout: "How does your solution handle address/identifier scoping, if at = all?" 4) Section 7 "Legal concerns" This is sort of "Legal/IANA concerns" - perhaps changing this would be=20 a good idea. Nits 1) Page 6 (and others)=20 s/Ipv6/IPv6 2) Sometimes you have IPv6, Ipv6 and IP version 6 - please settle on one = form. From owner-multi6@ops.ietf.org Wed Nov 3 02:33:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06825 for ; Wed, 3 Nov 2004 02:33:39 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPFe4-00006J-Tl for multi6-data@psg.com; Wed, 03 Nov 2004 07:33:28 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPFe3-000061-Sd for multi6@ops.ietf.org; Wed, 03 Nov 2004 07:33:28 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA37XPe08913 for ; Wed, 3 Nov 2004 09:33:26 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 09:32:11 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA37WBxJ024865 for ; Wed, 3 Nov 2004 09:32:11 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00nrSAOL; Wed, 03 Nov 2004 09:32:10 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA37W8a27471 for ; Wed, 3 Nov 2004 09:32:09 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 09:32:09 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 09:32:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Multi6 WG Last Call (3 of 3) draft-ietf-multi6-v4-multihoming-02.txt Date: Wed, 3 Nov 2004 09:32:08 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D431F46@esebe056.ntc.nokia.com> Thread-Topic: Multi6 WG Last Call (3 of 3) draft-ietf-multi6-v4-multihoming-02.txt Thread-Index: AcS28u9y/4SICoc3QByA7n5bdXq7JQKg+HyA From: To: X-OriginalArrivalTime: 03 Nov 2004 07:32:09.0149 (UTC) FILETIME=[39FEDED0:01C4C177] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, > It is proposed to forward > draft-ietf-multi6-v4-multihoming-02.txt > to the IESG for approval as an Informational RFC >=20 > Any final comments must be sent to the WG list at multi6@ops.ietf.org > within two weeks, i.e. at the latest on November 3, 2004. I support this going document going forward, one small nit: 1) Expand AS on first usage, page 7 thanks, John From owner-multi6@ops.ietf.org Wed Nov 3 04:13:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13672 for ; Wed, 3 Nov 2004 04:13:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPHAd-000EFI-Cu for multi6-data@psg.com; Wed, 03 Nov 2004 09:11:11 +0000 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPHAb-000EEH-Vp for multi6@ops.ietf.org; Wed, 03 Nov 2004 09:11:10 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA39AScn161658 for ; Wed, 3 Nov 2004 09:10:33 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA39ARqQ038432 for ; Wed, 3 Nov 2004 09:10:27 GMT Received: from zurich.ibm.com (sig-9-145-131-110.de.ibm.com [9.145.131.110]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA74842 for ; Wed, 3 Nov 2004 10:10:02 +0100 Message-ID: <4188A069.70304@zurich.ibm.com> Date: Wed, 03 Nov 2004 10:10:01 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: I-D ACTION:draft-huitema-multi6-ingress-filtering-00.txt References: <200410191147.HAA14229@ietf.org> In-Reply-To: <200410191147.HAA14229@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is useful. Just a couple of comments: > The topology features two hosts, X and Y, whose respective sites are > both multi-homed. Host X has two global IPv6 addresses, which we > will note "A:X" and "B:X", formed by combining the prefixes allocated > by ISP A and B to "site X" with the host identifier of X. Similarly, > Y has two addresses "C:Y" and "D:Y". Note that "X" in A:X and B:X need not be the same bit string- more correctly you should perhaps refer to A:X1 and A:X2, where X1 and X2 are two different interface identifiers for host X. Same for Y of course (and in draft-huitema-multi6-addr-selection-00.txt). I don't think this changes the argument at all. Single site exit router versus DMZ: I think there is a third case that you haven't considered, which is a multi-site enterprise network. I have to draw it: ISP A ---ISP B--- ISP C \ / \ / \ / \ / ------------ ------------ | DMZ 1 | | DMZ 2 | ------------ ------------ | | | | ------------ IGP ------------ | sub-site 1 |-----------| sub-site 2 | ------------ ------------ In this scenario, prefix A, B or C may be in use at either of the subsites and a packet from subsite 1 with source prefix C may end up in DMZ 1. (Just the same if you have a single site exit router instead of a DMZ.) In this case, I think tunnels between the two DMZs (or exit routers) are inevitable. This is a real scenario. Brian From owner-multi6@ops.ietf.org Wed Nov 3 04:25:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14612 for ; Wed, 3 Nov 2004 04:25:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPHNG-000GEh-4f for multi6-data@psg.com; Wed, 03 Nov 2004 09:24:14 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPHNB-000GDp-RC for multi6@ops.ietf.org; Wed, 03 Nov 2004 09:24:10 +0000 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA39O8xD204838 for ; Wed, 3 Nov 2004 09:24:08 GMT Received: from sihl.zurich.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA39O88c065906 for ; Wed, 3 Nov 2004 10:24:08 +0100 Received: from zurich.ibm.com (sig-9-145-131-110.de.ibm.com [9.145.131.110]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA10520 for ; Wed, 3 Nov 2004 10:24:07 +0100 Message-ID: <4188A3B7.7000108@zurich.ibm.com> Date: Wed, 03 Nov 2004 10:24:07 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt References: <200410191146.HAA13961@ietf.org> In-Reply-To: <200410191146.HAA13961@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >1. Introduction ... > In this memo we will present a set of mechanisms enable the hosts > within the multihomed site to select the addresses in order to be > able to establish new communications after an outage. I don't see why this only applies after an outage. The problem presents itself whenever a source wants to open a new flow - with or without knowledge that an outage has occurred. (And trivially, rebooting effectively emulates a general outage.) Also, as we've discussed, a reduction in obtained QOS may also be treated as an outage. Ideally, available QOS may be a criterion for address selection. > 5.1 Proactive mechanisms > > In this case, two mechanisms are needed: first, a mechanisms to > detect the outage and then a mechanisms to inform the host about > which prefixes should be used in the source address for the different > destinations. I have some difficulty in understanding this. Before a ULP decides to communicate with a particular remote host, the multihoming apparatus has precisely zero knowledge that this host is of interest. It's inconceivable therefore to have prior knowledge of anything useful about the remote host or its ISP, in the general case. We might know the status of the local first level (and possibly second level) ISPs, but that is about all. Does that covers enough cases to be worth the cost of implementing proactive mechanisms? > 5.2 Reactive mechanisms > > In this approach, the host will try with different source addresses > until the communication is established. Possibly, this will involve QOS measurement too. And this might edge over into the proactive side - it could be worth caching the results in case other flows to the same remote host are started within the some TTL. > 6. Future steps > > This memo presents multiple possible approaches to select address for > initiating new communications after an outage in multihomed > environments. At this point, the goal of the memo is to foster > discussion about the benefits and drawbacks of each approach, so that > eventually a set of mechanisms can be selected. I think it's more important to define interfaces so that the mechanisms can be pluggable. Brian From owner-multi6@ops.ietf.org Wed Nov 3 04:44:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15829 for ; Wed, 3 Nov 2004 04:44:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPHgg-000Ivp-KV for multi6-data@psg.com; Wed, 03 Nov 2004 09:44:18 +0000 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPHge-000IvP-Ti for multi6@ops.ietf.org; Wed, 03 Nov 2004 09:44:17 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA39iGsl051982 for ; Wed, 3 Nov 2004 09:44:16 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA39iGqQ043558 for ; Wed, 3 Nov 2004 09:44:16 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA39iFwT032123 for ; Wed, 3 Nov 2004 09:44:15 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA39iEQ2032120 for ; Wed, 3 Nov 2004 09:44:14 GMT Received: from zurich.ibm.com (sig-9-145-131-110.de.ibm.com [9.145.131.110]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA75834 for ; Wed, 3 Nov 2004 10:44:14 +0100 Message-ID: <4188A86E.2050600@zurich.ibm.com> Date: Wed, 03 Nov 2004 10:44:14 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Final agenda for multi6 Content-Type: multipart/mixed; boundary="------------000502000108050605010207" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------000502000108050605010207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------000502000108050605010207 Content-Type: text/plain; name="multi6-IETF61-agenda.txt" Content-Disposition: inline; filename="multi6-IETF61-agenda.txt" Content-Transfer-Encoding: 7bit Site Multihoming in IPv6 (multi6) Tuesday, November 9 at 0900-1130 Wednesday, November 10 at 1530-1730 =================================== CHAIRS: Brian Carpenter Kurt Lindqvist AGENDA: o Administrivia 5 minutes o Agenda Bashing 5 minutes o WG document status (chairs) 5 minutes (extra time if significant Last Call or IESG issues arise) draft-ietf-multi6-multihoming-threats-01.txt with IESG draft-ietf-multi6-v4-multihoming-02.txt WG Last Call ends Nov. 3 draft-ietf-multi6-things-to-think-about-00.txt WG Last Call ends Nov. 3 draft-ietf-multi6-architecture-02.txt WG Last Call ends Nov. 3 o Design team- presentations and discussion 3 hours total General report from design team (Erik Nordmark) 10 min. Multihoming L3 Shim Approach draft-nordmark-multi6dt-shim-00.txt (Erik Nordmark) 30 min. Hash Based Addresses (HBA) 30 min. draft-bagnulo-multi6dt-hba-00.txt (Marcelo Bagnulo) Functional decomposition of the M6 protocol 30 min. draft-bagnulo-multi6dt-functional-dec-00.txt (Marcelo Bagnulo) Failure Detection and Locator Selection in Multi6 30 min. draft-arkko-multi6dt-failure-detection-00.txt --- end of first session --- Multi6 Application Referral Issues 30 min. draft-nordmark-multi6dt-refer-00.txt (Erik Nordmark) Final discusssion on design team 20 min. o draft-huitema-multi6-addr-selection-00.txt 15 minutes draft-huitema-multi6-ingress-filtering-00.txt (Marcelo Bagnulo) o draft-arifumi-multi6-sas-policy-dist-00.txt 15 minutes (also see draft-hirotaka-dhc-source-address-selection-opt-00.txt and draft-arifumi-ipv6-nd-source-address-select-01) (Arifumi Matsumoto) o Next steps for the WG (Chairs & AD) until EOT --------------000502000108050605010207-- From owner-multi6@ops.ietf.org Wed Nov 3 05:34:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19812 for ; Wed, 3 Nov 2004 05:34:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPISb-00014e-EP for multi6-data@psg.com; Wed, 03 Nov 2004 10:33:49 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPISa-00014D-CK for multi6@ops.ietf.org; Wed, 03 Nov 2004 10:33:48 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA3AXie10827; Wed, 3 Nov 2004 12:33:44 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 12:32:08 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA3AW88R028260; Wed, 3 Nov 2004 12:32:08 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00pfu2YD; Wed, 03 Nov 2004 12:32:07 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA3AVZS18796; Wed, 3 Nov 2004 12:31:35 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 12:31:16 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 12:31:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WGLC comments on draft-ietf-multi6-architecture-02.txt Date: Wed, 3 Nov 2004 12:31:15 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D431F4E@esebe056.ntc.nokia.com> Thread-Topic: WGLC comments on draft-ietf-multi6-architecture-02.txt Thread-Index: AcTBiD2eXmDkaJ6ORb6VJbzCOKRP0wAB0QVw From: To: , , X-OriginalArrivalTime: 03 Nov 2004 10:31:16.0295 (UTC) FILETIME=[3FCB3570:01C4C190] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Geoff, > Thanks indeed for your careful review of this document. I've responded = > inline to your questions, but in general I agree with the suggestions = here Just responding to one open point here: > >2) 1st line, page 8: > > > > "In addition to this objective of session resilience across = network > > reachability changes," ... > > > > I had a hard time parsing this at first, perhaps the coffee = didn't > > kick in. Is it: > > > > "In addition to this objective of session resilience across = network > > reachability changes," ... > > > > or > > > > "In addition to this objective of session resilience during = network > > reachability changes," ... > > > > or > > > > "In addition to this objective of session resilience in spite of = network > > reachability changes," ... >=20 >=20 > I think its the third. But it needs clarification in any case. What is = > going through my head as I read your comments is the distinction = between=20 > session resilience DURING the period of routing instability while the=20 > routing system reaches a new converged state as distinct to the = objective=20 > of session surviveability BEFORE and AFTER a routing change. I do not = think=20 > it is possible to undertake the former (DURING) given that there is no = > reliable stable routing state during routing churn, so I did mean = BEFORE=20 > and AFTER. I think our goal here is that a session SHOULD survive (TCP connections = don't break) but it might not be possible in all cases. I'll let you = wordsmith, however. thanks, John From owner-multi6@ops.ietf.org Wed Nov 3 06:17:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24006 for ; Wed, 3 Nov 2004 06:17:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPJ8F-00087V-75 for multi6-data@psg.com; Wed, 03 Nov 2004 11:16:51 +0000 Received: from [193.109.247.251] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPJ7P-00080B-Dw for multi6@ops.ietf.org; Wed, 03 Nov 2004 11:16:44 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id BC41064235E; Wed, 3 Nov 2004 12:16:03 +0100 (CET) In-Reply-To: <4188263E.7060009@sun.com> References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> <4185F340.2080701@zurich.ibm.com> <3AB79A56-2CE5-11D9-8458-000D93ACD0FE@it.uc3m.es> <4188263E.7060009@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <8A5F0886-2D67-11D9-AA47-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 , marcelo bagnulo braun , Brian E Carpenter From: Kurt Erik Lindqvist Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt Date: Wed, 3 Nov 2004 08:11:11 +0100 To: Erik Nordmark X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-11-03, at 01.28, Erik Nordmark wrote: > If a host wants to prevent packet injection attacks today (such as > spoofed RCP RST packets, if it wants to prevent it from all nodes and > not depend on ingress filtering, wouldn't it use IPsec? That would have to be a must. I can't see anyone building a trust model based on (the non-existing) ingress filtering. That said, I think most protection against packet injection attacks on todays Internet is actually left to ULPs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQYiElKarNKXTPFCVEQJO4ACfQ6Swyp03I6EaKoaeQkmw1mvzkC0AoI/W gCUKJxD5fCvv0QHhexPyBDmy =hqua -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Nov 3 06:41:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27433 for ; Wed, 3 Nov 2004 06:41:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPJUB-000BgI-E0 for multi6-data@psg.com; Wed, 03 Nov 2004 11:39:31 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPJU7-000Bfg-7N for multi6@ops.ietf.org; Wed, 03 Nov 2004 11:39:27 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AACC52FEBA; Wed, 3 Nov 2004 12:39:25 +0100 (CET) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 8FC7E2FEAF; Wed, 3 Nov 2004 12:39:25 +0100 (CET) In-Reply-To: <4188263E.7060009@sun.com> References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> <4185F340.2080701@zurich.ibm.com> <3AB79A56-2CE5-11D9-8458-000D93ACD0FE@it.uc3m.es> <4188263E.7060009@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <058D9A20-2D8D-11D9-8458-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 , Brian E Carpenter From: marcelo bagnulo braun Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt Date: Wed, 3 Nov 2004 12:39:29 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 03/11/2004, a las 1:28, Erik Nordmark escribi=F3: > marcelo bagnulo braun wrote: > >> Just one additional nit... >> note that HBAs are particularly restrictive in this aspect, since all=20= >> locators need to be known a priori. However, even if you use=20 >> alternative schemes that don't impose such restriction, like CGAs,=20 >> you still need to add security information at least in the same=20 >> packet that carries the new locator. > > That requirement isn't obvious to me so I think it would warrant=20 > discussion. > agree > The issue is whether it would be ok for the multi6 shim to pass a=20 > packet to the ULP when the source locator has not been verified as=20 > belonging to the peer. We all agree that we need to do such=20 > verification before *sending* packets to a new locator, but what about=20= > just accepting the packet? > good point > Things to take into account: > In today's Internet, when there is no ingress filtering anybody can=20 > spoof the source IP address and the packets will be passed by IP to=20 > the ULP. However, in today's Internet when there is some ingress=20 > filtering it is possible to restrict the nodes which can actually=20 > spoof the source IP address to those that are close to the path=20 > between the real location of the IP address and the receiving node. > Well, if we allow hosts to accept packets coming from unverified=20 locators and present them as belonging to a different ULP identifier,=20 then not even ingress filtering would prevent such attacks. I mean,=20 today, if ingress filtering is deployed, then the problem of spoofed=20 addresses is reduced. If we allow the reception from unverified=20 locators, ingress filtering won't help any more in this problem. OTOH, i understand that there is a long way between the level of=20 security provided by a semi deployed ingress filtering and the level of=20= security resulting from requiring the usage of cga or hbas to verify=20 any incoming locator. Perhaps a cookie would be enough to validate=20 incoming packets (it is clearly not enough to send packet to that=20 locator though) Another point related to this is whether we consider this new incoming=20= locator as a hint to rehome the communication to that new locator. In=20 this case, we need additional certainty i guess. regards, marcelo > If a host wants to prevent packet injection attacks today (such as=20 > spoofed RCP RST packets, if it wants to prevent it from all nodes and=20= > not depend on ingress filtering, wouldn't it use IPsec? > > Erik > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Nov 3 10:01:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15607 for ; Wed, 3 Nov 2004 10:01:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPMbo-000FqZ-SK for multi6-data@psg.com; Wed, 03 Nov 2004 14:59:36 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPMbk-000Fpj-BM for multi6@ops.ietf.org; Wed, 03 Nov 2004 14:59:33 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 14AC92FB2F; Wed, 3 Nov 2004 15:59:30 +0100 (CET) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 12E3D2FB0A; Wed, 3 Nov 2004 15:59:29 +0100 (CET) In-Reply-To: <200411011540.iA1Fe7Sj050988@givry.rennes.enst-bretagne.fr> References: <200411011540.iA1Fe7Sj050988@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org, Tuomas Aura From: marcelo bagnulo braun Subject: Re: about draft-bagnulo-multi6dt-hba-00.txt Date: Wed, 3 Nov 2004 15:59:32 +0100 To: Francis Dupont X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Francis, sorry for the delay thanks for these new comments, they are very much appreciated. some answers below... El 01/11/2004, a las 16:40, Francis Dupont escribi=F3: > In your previous mail you wrote: > >> But there is at least >> another interpretation... BTW the encoding gives only a static (i.e., >> easy to precompute : 0x 30 42 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 >> 05 00 >> 03 31 00 <48 octets> but please check :-) prefix. > > ok, i will try to clearify this > > =3D> note that I've checked this... > >> Finally I am not convinced a type tag is not required for HBA CGAs, >> i.e., >> today HBA CGAs are not more usable than CGAs... > > i am not following this, could you expand a bit? > > =3D> the question was about type tags for HBAs... finally I believe we > don't need them, i.e., HBAs which are not CGAs have no use of type=20 > tags, > HBAs which are CGAs are covered by the CGA document > (draft-ietf-send-cga-06.txt). > agree >> PS: I have an OpenSSL module for CGAs (with new/free/dup/d2i/i2d and >> check/sign/verify). I can send it to who'd like to extend it to HBA >> (I'm using the standard BSD licence). It should be easy because if=20 >> I've >> understood the design the multi-prefix extension is an extension=20 >> field? > > we are planning to implement HBA, so this would be really helpful. > I will contact you later. > > =3D> I had some free time in this long weekend so I wrote the code great! are you planning to make it public? > and > now I have some new comments: > - draft-ietf-send-cga-06.txt is not clear enough about where the=20 > extension > fields are included in the hash (here the multi-prefix extension) : > > ... Note that the hash values are computed over > the entire CGA Parameters data structure, including any = unrecognized > extension fields. > > but: > > 2. Concatenate from left to right the modifier, 9 zero octets, and > the encoded public key. Execute the SHA-1 algorithm on the > concatenation. Take the 112 leftmost bits of the SHA-1 hash > value. The result is Hash2. > > and: > > 5. Concatenate from left to right the final modifier value, the > subnet prefix, the collision count and the encoded public key. > Execute the SHA-1 algorithm on the concatenation. Take the 64 > leftmost bits of the SHA-1 hash value. The result is Hash1. > Well, as i read it, the new extensions should be included both in the=20 cga generation and verification, only that since at this point there=20 are no extension specified, the algorithm presented in the spec doesn't=20= explicitely include them. > So in draft-bagnulo-multi6dt-hba-00.txt the extension is in Hash2 > (good decision) but not in Hash1 (does it matter?): well, this is my mistake, thanks for catching it The multiprefix extension should be included both in the generation and=20= the verification of HAsh1 i will fix this in the next version > > 3. Concatenate from left to right the Modifier, 9 zero octets, the > encoded public key or the encoded Extended Modifier (if no = public > key was provided) and the Multi-Prefix Extension. Execute the > SHA-1 algorithm on the concatenation. Take the 112 leftmost = bits > of the SHA-1 hash value. The result is Hash2. > > and: > > 6.1. Concatenate from left to right the final modifier value, > Prefix[i], the collision count, the encoded public key or the > encoded Extended Modifier (if no public key was provided). > Execute the SHA-1 algorithm on the concatenation. Take the = 64 > leftmost bits of the SHA-1 hash value. The result is=20 > Hash1[i]. > > Please fix this with Tuomas! > AFAIU, the multiprefix extension should be included both in the=20 generation and verification of Hash1 and Hash2 makes sense? > - the second point is about the Ext Type (TBD IANA): we have to=20 > propose > a common value in order to get interoperability (and examples :-). > Ok, would you propose a value that you like? ( i mean what did you use=20= in your implementation? :-) > - the last point is about the collision count: I believe it should be > per HBA not global as described: > > 5. Set the 8-bit collision count to zero. > > 6. For i=3D1 to n do > > ... > > 6.4. Perform duplicate address detection if required. If an > address collision is detected, increment the collision count=20= > by > one and go back to step (6). However, after three = collisions, > stop and report the error. > > I propose to put the 5 in the first step of 6 and go back to the=20 > next > step (currently 6.1 but it should become 6.2) when DAD fails. > I can see that there is an advantage in making the collision count per=20= HBA as you suggest, since in the case that DAD fails, then you only=20 need to regenerate a single HBA and not the whole set. However, i can see some disadvantages when using the HBAs for multi6 if=20= we do this. (Note that the following argument is assuming a specific=20 usage of HBAs in the multi6 protocol, which may not be the case at the=20= end, so it may well not apply) My point is that if the collision count is per HBA, then the=20 differences between the CGA Parameter Data Structure (hereafter=20 CGA_PDS) of the different HBas of the HBA set will be increased. I=20 mean, if the collision count is global, then the only difference=20 between the CGA_PDS of the different HBAs of an HBA set is the prefix=20 included in the subnet prefix field, and considering that the prefix is=20= included in the HBa itself, it is not a big deal. However, if the collision count is per HBA, then the difference between=20= the different CGA_PDS of the different HBAs of an HBA set will be the=20 subnet prefix and maybe the collision count. Now, why does this matter? Because this means that the different values of the collision count=20 that correspond to each CGA_PDS of each HBA of the HBA set will need to=20= the transmitted to the other end, so that the receiver can generate all=20= the different CGA_PDSs I mean, if the collision count are global, then one CGA_PDS contains=20 all the information of all the CGA_PDS of all the HBAs of the HBA set.=20= If we use per HBA collision counts, then, the last statement is no=20 longer true, and we will need to transmit such additional collsion=20 count information. Now, in any case, the probability of collision is low, so i don't think=20= that any option would pose any problems, just that i feel that the=20 global option would result in a simpler multi6 protocol Regards, marcelo > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Nov 3 10:37:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20178 for ; Wed, 3 Nov 2004 10:37:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPNBd-000L7Z-6f for multi6-data@psg.com; Wed, 03 Nov 2004 15:36:37 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPNBc-000L7J-28 for multi6@ops.ietf.org; Wed, 03 Nov 2004 15:36:36 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D51AC2FDF8; Wed, 3 Nov 2004 16:36:34 +0100 (CET) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id A46D72FDF2; Wed, 3 Nov 2004 16:36:34 +0100 (CET) In-Reply-To: <4188A069.70304@zurich.ibm.com> References: <200410191147.HAA14229@ietf.org> <4188A069.70304@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2432B672-2DAE-11D9-A24C-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: Multi6 From: marcelo bagnulo braun Subject: Re: I-D ACTION:draft-huitema-multi6-ingress-filtering-00.txt Date: Wed, 3 Nov 2004 16:36:33 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Brian, thanks for your comments, see below... El 03/11/2004, a las 10:10, Brian E Carpenter escribi=F3: > This is useful. Just a couple of comments: > >> The topology features two hosts, X and Y, whose respective sites=20= >> are >> both multi-homed. Host X has two global IPv6 addresses, which we >> will note "A:X" and "B:X", formed by combining the prefixes=20 >> allocated >> by ISP A and B to "site X" with the host identifier of X. =20 >> Similarly, >> Y has two addresses "C:Y" and "D:Y". > > Note that "X" in A:X and B:X need not be the same bit string- > more correctly you should perhaps refer to A:X1 and A:X2, > where X1 and X2 are two different interface identifiers for host X. > ok, i'll fix that > Same for Y of course (and in=20 > draft-huitema-multi6-addr-selection-00.txt). > same > I don't think this changes the argument at all. > agree > Single site exit router versus DMZ: > > I think there is a third case that you haven't considered, which is > a multi-site enterprise network. I have to draw it: > > > ISP A ---ISP B--- ISP C > \ / \ / > \ / \ / > ------------ ------------ > | DMZ 1 | | DMZ 2 | > ------------ ------------ > | | > | | > ------------ IGP ------------ > | sub-site 1 |-----------| sub-site 2 | > ------------ ------------ > > In this scenario, prefix A, B or C may be in use at either > of the subsites and a packet from subsite 1 with source > prefix C may end up in DMZ 1. (Just the same if you have a > single site exit router instead of a DMZ.) In this case, > I think tunnels between the two DMZs (or exit routers) > are inevitable. > agree. do you mind if i include this example (verbatim) in the next version of=20= the draft? Thanks, marcelo > This is a real scenario. > > Brian > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Nov 3 12:13:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28529 for ; Wed, 3 Nov 2004 12:13:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPOg1-0008fX-Ap for multi6-data@psg.com; Wed, 03 Nov 2004 17:12:05 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPOg0-0008f6-0n for multi6@ops.ietf.org; Wed, 03 Nov 2004 17:12:04 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6B7012FF2D; Wed, 3 Nov 2004 18:12:02 +0100 (CET) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 535A12FF28; Wed, 3 Nov 2004 18:12:02 +0100 (CET) In-Reply-To: <4188A3B7.7000108@zurich.ibm.com> References: <200410191146.HAA13961@ietf.org> <4188A3B7.7000108@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <7A4E9D76-2DBB-11D9-A24C-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: Multi6 From: marcelo bagnulo braun Subject: Re: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt Date: Wed, 3 Nov 2004 18:12:01 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Brian, thanks for these comments too. see below... El 03/11/2004, a las 10:24, Brian E Carpenter escribi=F3: > >1. Introduction > ... >> In this memo we will present a set of mechanisms enable the hosts >> within the multihomed site to select the addresses in order to be >> able to establish new communications after an outage. > > I don't see why this only applies after an outage. The problem = presents > itself whenever a source wants to open a new flow - with or without > knowledge that an outage has occurred. (And trivially, rebooting > effectively emulates a general outage.) Well, it is clear that a host has to select the address to use when it=20= initiates a new communication with or without an outage, but in the=20 case that there is no outage, the main problem is ingress filtering and=20= policy (which are out of the scope of this draft, since we wanted to=20 keep it focused as a single component) However, in the case that an outage has occurred, the problem is more=20 serious, because if the wrong addresses are used, the communication=20 will fail. this is the situation that the mechanisms presented in the draft tries=20= to solve > > Also, as we've discussed, a reduction in obtained QOS may also be=20 > treated > as an outage. Ideally, available QOS may be a criterion for address > selection. > agree, but a first (simple) approach to the problem could be like=20 working vs non-working paths. QoS computation may be a bit tricky, so perhaps it would be better to=20 avoid it for initial mechanisms... i don't know >> 5.1 Proactive mechanisms >> In this case, two mechanisms are needed: first, a mechanisms to >> detect the outage and then a mechanisms to inform the host about >> which prefixes should be used in the source address for the=20 >> different >> destinations. > > I have some difficulty in understanding this. Before a ULP decides to > communicate with a particular remote host, the multihoming apparatus=20= > has > precisely zero knowledge that this host is of interest. It's=20 > inconceivable > therefore to have prior knowledge of anything useful about the remote=20= > host > or its ISP, in the general case. We might know the status of the local > first level (and possibly second level) ISPs, but that is about all. well i was thinking about bgp. I mean, if we have something like what was presented in NAROS, where=20 there is server that runs BGP with all the ISPs, then this server has=20 information about all the BGP feeds, so it may have additional=20 information of the remote end. Clearly this info won't cover all the=20 possible failure modes, but some of them. so in those cases, there will=20= some info available that allows the host to discard the faulty address. It is clear that those mechanisms are not enough by themselves, and the=20= reactive mechanisms are also needed. > Does > that covers enough cases to be worth the cost of implementing = proactive > mechanisms? This is the whole point i guess. FWIW those mechanisms are included in order to have all the possible=20 approaches and then select the ones we think are worthy > >> 5.2 Reactive mechanisms >> In this approach, the host will try with different source = addresses >> until the communication is established. > > Possibly, this will involve QOS measurement too. And this might edge=20= > over > into the proactive side - it could be worth caching the results in = case > other flows to the same remote host are started within the some TTL. Yes, but as i mentioned above, my feeling is that QoS considerations=20 should be covered by a bit more advanced mechanisms and that a basic=20 approach could simply differentiate among working and non working=20 address pairs, do you think that we should be considering qoS from the=20= start? > >> 6. Future steps >> This memo presents multiple possible approaches to select address=20= >> for >> initiating new communications after an outage in multihomed >> environments. At this point, the goal of the memo is to foster >> discussion about the benefits and drawbacks of each approach, so=20= >> that >> eventually a set of mechanisms can be selected. > > I think it's more important to define interfaces so that the > mechanisms can be pluggable. > agree. It would be usefull to see if these mechanisms are compatible with the=20= multi6 protocol for preserving established communications and if the=20 presented mechanisms are good enough to be used for establishing=20 initial contact in multi6 capable sessions. regards, marcelo > Brian > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Nov 3 14:29:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10906 for ; Wed, 3 Nov 2004 14:29:12 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPQmm-0003TC-G3 for multi6-data@psg.com; Wed, 03 Nov 2004 19:27:12 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPQml-0003Sv-41 for multi6@ops.ietf.org; Wed, 03 Nov 2004 19:27:11 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iA3JR6ui024311; Wed, 3 Nov 2004 12:27:07 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id iA3JR4JQ014034; Wed, 3 Nov 2004 20:27:04 +0100 (MET) Message-ID: <41893138.8080903@sun.com> Date: Wed, 03 Nov 2004 11:27:52 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun CC: Multi6 , Brian E Carpenter Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> <4185F340.2080701@zurich.ibm.com> <3AB79A56-2CE5-11D9-8458-000D93ACD0FE@it.uc3m.es> <4188263E.7060009@sun.com> <058D9A20-2D8D-11D9-8458-000D93ACD0FE@it.uc3m.es> In-Reply-To: <058D9A20-2D8D-11D9-8458-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo braun wrote: > Well, if we allow hosts to accept packets coming from unverified > locators and present them as belonging to a different ULP identifier, > then not even ingress filtering would prevent such attacks. I mean, > today, if ingress filtering is deployed, then the problem of spoofed > addresses is reduced. If we allow the reception from unverified > locators, ingress filtering won't help any more in this problem. Agreed. > OTOH, i understand that there is a long way between the level of > security provided by a semi deployed ingress filtering and the level of > security resulting from requiring the usage of cga or hbas to verify any > incoming locator. Perhaps a cookie would be enough to validate incoming > packets (it is clearly not enough to send packet to that locator though) A hard-to-guess cookie would probably make things stronger than today in the absense of ingress filtering. Today's ULP have varying verification from SCTPs use of a 32-bit verification tag, TCP's reliance on the sequence number being in the window, and UDP with nothing (but applications using UDP might have something). > Another point related to this is whether we consider this new incoming > locator as a hint to rehome the communication to that new locator. In > this case, we need additional certainty i guess. If it is merely a hint, and there is a cookie to prevent the off-path attackers from triggering the hint, that might be sufficient. Erik From owner-multi6@ops.ietf.org Wed Nov 3 15:11:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15201 for ; Wed, 3 Nov 2004 15:11:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPRTF-000ASN-Pj for multi6-data@psg.com; Wed, 03 Nov 2004 20:11:05 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPHVG-000HTE-11 for multi6@ops.ietf.org; Wed, 03 Nov 2004 09:32:30 +0000 Received: from gihz1.apnic.net (dhcp8.potaroo.net [203.10.60.8]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id iA39WDch020538; Wed, 3 Nov 2004 20:32:13 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.0.1.1.2.20041103194029.021232c8@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 03 Nov 2004 19:48:09 +1100 To: , , From: Geoff Huston Subject: Re: WGLC comments on draft-ietf-multi6-architecture-02.txt In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D431F44@esebe056.ntc.nokia. com> References: <3CF661B1787ABF41A869BE20108F8D6D431F44@esebe056.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk John, Thanks indeed for your careful review of this document. I've responded inline to your questions, but in general I agree with the suggestions here regards, Geoff >Geoff, > >I support this draft going forward, I have a couple of issues, some questions >but mostly nits. > >thanks, >John > >Issues: >====== > >1) This document would benefit from a terminology section. Perhaps a >reference > to the Terminology section in RFC3582 as well. Terminology to include > would be > "session resilience"; add ULP, LLP and EIP; as well as others. sounds like an excellent suggestion. I'll look into this >2) Section 5.3.1 - Triggering Locator Switches. Inserting an information >reference > to > http://www.ietf.org/internet-drafts/draft-iab-link-indications-00.txt could > be useful. It seems to me that a crucial part of any multihoming > solution will > be the triggering of a multihoming event. I don't think we need to > explicitly > list all of the potential triggers, but let the astute reader catch-up > on some > related work. Thanks for this. This has been a more recent contribution than the first passes of the multi6 document, and I agree that a vcross reference here would be useful >Questions: >========= > >1) Section 4.3: > > "The intent of multi-homing in the IPv6 domain is to achieve a > comparable functional outcome for multi-homed sites without an > associated additional load being imposed on the routing system." > > This sentence seems incomplete, a comparable functional outcome > as compared to what? I had implicitly added "to IPv4" in my head when I wrote that setence! :-) >2) 1st line, page 8: > > "In addition to this objective of session resilience across network > reachability changes," ... > > I had a hard time parsing this at first, perhaps the coffee didn't > kick in. Is it: > > "In addition to this objective of session resilience across network > reachability changes," ... > > or > > "In addition to this objective of session resilience during network > reachability changes," ... > > or > > "In addition to this objective of session resilience in spite of network > reachability changes," ... I think its the third. But it needs clarification in any case. What is going through my head as I read your comments is the distinction between session resilience DURING the period of routing instability while the routing system reaches a new converged state as distinct to the objective of session surviveability BEFORE and AFTER a routing change. I do not think it is possible to undertake the former (DURING) given that there is no reliable stable routing state during routing churn, so I did mean BEFORE and AFTER. >Nits: >==== > >1) Spacing problem, but this seems to be a Secretariat problem. xml2rfc does have some quirky behaviours in lists. >2) Page 6: > > "The environment of multi-homing is one that is intended to provide > sufficient support to local hosts so as to allow local hosts to > exchange IP packets with remote hosts, such that this exchange of > packets is to be seamlessly supported across dynamic changes in > connectivity." > > Change 'seamlessly' to another term, perhaps > 'transparently'? Seamlessly > has a lot of mobility baggage, so it might be good to avoid that > term. agreed and yes to the rest. >3) Expand first usage of ULP in section 4.2. > >4) Section 4.3 (and others) "vs" should be "vs." > >5) Section 5.3.1 - adding a new line before each bullet would increase >readability. > >6) "5.3.5 Dynamic Capability Negotiation > > > The common aspect of these approaches is that they all involve > changes to the end-to-end interaction, as both endS of the" > > endS -> ends > >7) Section 6 - insert a blank line between questions; otherwise it is >somewhat > awkward to read. From owner-multi6@ops.ietf.org Wed Nov 3 15:13:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15461 for ; Wed, 3 Nov 2004 15:13:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPRUq-000Agy-0Q for multi6-data@psg.com; Wed, 03 Nov 2004 20:12:44 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPFSk-000OnY-Uo for multi6@ops.ietf.org; Wed, 03 Nov 2004 07:21:47 +0000 Received: from gihz1.apnic.net (dhcp7.potaroo.net [203.10.60.7]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id iA37KCch018178; Wed, 3 Nov 2004 18:20:12 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.0.1.1.2.20041103171536.02126060@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 03 Nov 2004 18:20:13 +1100 To: Pekka Savola , Brian E Carpenter From: Geoff Huston Subject: Re: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt Cc: Multi6 In-Reply-To: References: <4176E2F5.10008@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Pekka, Thanks for your careful review of the document. I've threaded responses to your questions and comments regards, Geoff At 04:39 PM 3/11/2004, Pekka Savola wrote: > I've two bigger concerns here. While they aren't changes which must be adopted, I think > doing so would improve the document's readability a lot and help in clarifying its scope, so it > might be worth the effort.. >1) > >The document is rather long and conversational in tone. Yes. There is a fair amount of ground to cover and quite frankly in my case brevity would lead to a document that would quickly become cryptic. I chose this style as a) its a style I'm comfortable write in and b) I believe that it is suited to this form of architectural discussion, where the intent is not to be prescriptive in advocating one approach or another, but to look at the overall space and look at the manner in which various approaches choose to operate within this space. > That's probably not a big problem, but I found it difficult to read, because there was not a clear structure in the document. In particular, section 4.3 "Multi-homing: Identity Considerations" (which was discussing generic issues for further subsections) seemed ill placed to section 4. More appropriate place for quite a bit of this discussion would be under section 5, possible under 5.3.2 in particular. I'm afaid that I do not agree with this. The purpose of this section is to motivate the following 2 section (4.3 and 4.5) by looking at the common aspects of identity in the context of multi-homed environments without assuming a particular implementation class. Section 5 is a more general discussion about identities, and section 4.3 would be out of place if moved there. >I'd like to reduce the amount of generic discussion in section 4, just >making it lay out the different approarches in sufficient detail, and >refer to the following sections for lengthier (and more structured) >discussion of the details. This section (4) looks at generic styles of approach, rather than particular approaches, and looks at the potential advantages and possible limitations of multi-homing within the context of each style, and discusses them. The following section (5) is a more focussed examination of the behaviour and properties of identifiers. >There are also some rather long sections or long paragraphs, which could be split into more digestible pieces. E.g., section 5.1 could possibly be split into subsections based on the approach. That could give more structure and make the document easier to consume. I have used section headers as delimiters for particular topics which are then expounded in a single text block. Putting in a third level of heading would be somewhat disruptive to the flow of the argument I would contend. >2) > >I've griped before about this document not having enough 'truth in advertising', i.e., it says it describes the architectural approaches to multihoming in IPv6, but does not go in sufficient detail to e.g., traffic engineering possibilities (the mention of this has been sprinkled along the draft though). Still, I think this is a bit of misleading and we should try to avoid this. I'd just make it clearer that this document focuses on connection survivability and not the whole multihoming problem space. The document attempts to steer a neutral line between what some folk see as possibilities, and others see as unrealistic. For example, some would see host-based locator selection as a tool to push traffic along particular network paths which in turn could provide particular traffic engineering outcomes. while others would say that traffic engineering as an outcome of host-based locator selection is a case of fanciful thinking, as there is clearly insufficient network-based path state information provided to hosts to allow them to make an informed decision about a locator selection that would yield particular path characteristics and network load profiles. >How to go about this (just an idea): > - a note at the end of section 3 (or after the list quoted from 3582) that >the focus is on ensuring connection survivability > - rename section 4, Approaches to Multi-Homing, to include a note about >connection survivability and the like > - note in section 4.1 that this also provides more than just conn. surv. > - maybe some minor tweaks in the abstract, introduction and the title I' afraid that I don't agree with this approach - the document is intended to take an architectural view of multi-homing, and do so without particular limitation of perspective in terms of its architectural analysis. >mostly editorial >---------------- > > In addition, [2] documents further considerations for IPv6 > multi-homing. Again, the reader is referred to this document for the > detailed enumeration of these considerations. The general topic > areas considered in this study include: > o interaction with routing systems, > o aspects of a split between end-point-identifier and forwarding > locator, > o changes to packets on the wire, and > o the interaction between names, endpoints and the DNS. > >==> does this call for minor edits to update to the latest think-about-... >organization? I do not believe so - what did you have in mind? > All transit providers for the site accept a prefix advertisement from > the multi-homed site, and advertise this prefix globally in the > inter-domain routing table. > >==> s/accept/need to accept/ (a slightly different nuance)? The text here is describing a scenario, and the sense of the verb is intended to be descriptive rather than prescriptive. In this case the descriptive form "accept" is intended. > The possible application of the MIPv6 protocol to the multihoming > problem would be to use BU messages to convey information about > alternative addresses to be used after the outage. > >==> clarify: s/convey/convey prior to the outage/ ? An alternative wording is: The possible application of the MIPv6 protocol to the multihoming problem would be to use BU messages to convey information in advance about alternative addresses that could be used following an outage in the path associated with the currently used address. > the network. IN the latter case there is also the consideration of > >==> s/IN/In/ yep :-) > IPSEC is necessary in this case, in order to avoid making changes to > >==> s/IPSEC/IPsec/ thanks > changes to the end-to-end interaction, as both endS of the > >==> s/endS/ends/ thanks > reasonable to assume that the identity assignation is not necessarily > >==> s/assignation/assignment/ ? I checked this - I believe I do mean assignation, in the sense of 'something assigned' >6.1 Establishing Session State > > > What form of token is passed to the transport layer from the upper > level protocol element as an identification of the local protocol > stack? > What form of token is passed to the transport layer from the upper > level protocol element as an identification of the remote session > target? > >==> could there be an empty line between the questions, so it would be more >readable ? yes - this appears to be a xml2rfc thing > [4] Nikander, P., Arkko, J., Aura, T., Montenegro, G. and E. > Nordmark, "Mobile IP version 6 Route Optimization Security > Design Background", Work in progress: Internet Drafts > draft-ietf-mip6-ro-sec-01.txthttp://bgp.potaroo.net/ietf/idref/ > draft-ietf-multi6-things-to-think-abou, July 2004, > . > >==> there's some crap here ('draft-ietf-multi6-things-to-think-abou'). yep - will fix >10 Informative References > >==> shouldn't some of these really be normative references ? I do not believe so - this is not a specification document and hence there are no base documents upon which this document relies. That was my reasoning for using informative references in any case. Again, thanks for your careful review of the document. regards, Geoff From owner-multi6@ops.ietf.org Wed Nov 3 16:37:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21663 for ; Wed, 3 Nov 2004 16:37:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPSn0-000Nbq-Vl for multi6-data@psg.com; Wed, 03 Nov 2004 21:35:34 +0000 Received: from [193.109.175.26] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPSmx-000NbO-33 for multi6@ops.ietf.org; Wed, 03 Nov 2004 21:35:31 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 7F1F3645247; Wed, 3 Nov 2004 22:35:36 +0100 (CET) In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D431F46@esebe056.ntc.nokia.com> References: <3CF661B1787ABF41A869BE20108F8D6D431F46@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <48E924DC-2DE0-11D9-AA47-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: From: Kurt Erik Lindqvist Subject: Re: Multi6 WG Last Call (3 of 3) draft-ietf-multi6-v4-multihoming-02.txt Date: Wed, 3 Nov 2004 22:35:30 +0100 To: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-11-03, at 08.32, wrote: > Hi all, > >> It is proposed to forward >> draft-ietf-multi6-v4-multihoming-02.txt >> to the IESG for approval as an Informational RFC >> >> Any final comments must be sent to the WG list at multi6@ops.ietf.org >> within two weeks, i.e. at the latest on November 3, 2004. > > I support this going document going forward, one small nit: > > 1) Expand AS on first usage, page 7 Thanks, will include in update. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQYlPJqarNKXTPFCVEQIYDACdGdYD6cq18ZFhEABt/i2RX/Hrg4EAoLJK 0k2s5WH553GklGUEJaNCfYrM =/bBK -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Nov 3 17:22:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26189 for ; Wed, 3 Nov 2004 17:22:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPTVw-0005hB-WB for multi6-data@psg.com; Wed, 03 Nov 2004 22:22:01 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPTVv-0005fv-BD for multi6@ops.ietf.org; Wed, 03 Nov 2004 22:21:59 +0000 Received: from gihz1.apnic.net (dhcp7.potaroo.net [203.10.60.7]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id iA3MKQch008129; Thu, 4 Nov 2004 09:20:27 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.0.1.1.2.20041104085249.0233a730@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 04 Nov 2004 08:55:06 +1100 To: Kurt Erik Lindqvist , Erik Nordmark From: Geoff Huston Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt Cc: Multi6 , marcelo bagnulo braun , Brian E Carpenter In-Reply-To: <8A5F0886-2D67-11D9-AA47-000A95928574@kurtis.pp.se> References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> <4185F340.2080701@zurich.ibm.com> <3AB79A56-2CE5-11D9-8458-000D93ACD0FE@it.uc3m.es> <4188263E.7060009@sun.com> <8A5F0886-2D67-11D9-AA47-000A95928574@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk At 06:11 PM 3/11/2004, Kurt Erik Lindqvist wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >On 2004-11-03, at 01.28, Erik Nordmark wrote: > > > If a host wants to prevent packet injection attacks today (such as > > spoofed RCP RST packets, if it wants to prevent it from all nodes and > > not depend on ingress filtering, wouldn't it use IPsec? > >That would have to be a must. I can't see anyone building a trust model >based on (the non-existing) ingress filtering. That said, I think most >protection against packet injection attacks on todays Internet is >actually left to ULPs. I take it that you are classifying TCP as a ULP in this instance? As I understand it TCP attempts to provide protection against packet injection attacks and does not allow its ULP any discretion, while UDP simply passes the packet upward and places the onus on its ULP to detect injected bogus packets in the UDP exchange. regards, Geoff From owner-multi6@ops.ietf.org Wed Nov 3 17:40:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27894 for ; Wed, 3 Nov 2004 17:40:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPTmM-0007pK-5l for multi6-data@psg.com; Wed, 03 Nov 2004 22:38:58 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPTmK-0007ox-Sr for multi6@ops.ietf.org; Wed, 03 Nov 2004 22:38:57 +0000 Received: from gihz1.apnic.net (dhcp7.potaroo.net [203.10.60.7]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id iA3Mckch019437; Thu, 4 Nov 2004 09:38:47 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.0.1.1.2.20041104093550.021d4500@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 04 Nov 2004 09:36:10 +1100 To: , , From: Geoff Huston Subject: RE: WGLC comments on draft-ietf-multi6-architecture-02.txt In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D431F4E@esebe056.ntc.nokia. com> References: <3CF661B1787ABF41A869BE20108F8D6D431F4E@esebe056.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk At 09:31 PM 3/11/2004, john.loughney@nokia.com wrote: >Hi Geoff, > > > Thanks indeed for your careful review of this document. I've responded > > inline to your questions, but in general I agree with the suggestions here > >Just responding to one open point here: > > > >2) 1st line, page 8: > > > > > > "In addition to this objective of session resilience across network > > > reachability changes," ... > > > > > > I had a hard time parsing this at first, perhaps the > coffee didn't > > > kick in. Is it: > > > > > > "In addition to this objective of session resilience across network > > > reachability changes," ... > > > > > > or > > > > > > "In addition to this objective of session resilience during network > > > reachability changes," ... > > > > > > or > > > > > > "In addition to this objective of session resilience in spite of > network > > > reachability changes," ... > > > > > > I think its the third. But it needs clarification in any case. What is > > going through my head as I read your comments is the distinction between > > session resilience DURING the period of routing instability while the > > routing system reaches a new converged state as distinct to the objective > > of session surviveability BEFORE and AFTER a routing change. I do not > think > > it is possible to undertake the former (DURING) given that there is no > > reliable stable routing state during routing churn, so I did mean BEFORE > > and AFTER. > >I think our goal here is that a session SHOULD survive (TCP connections don't >break) but it might not be possible in all cases. I'll let you wordsmith, >however. thanks - I'll work on this Geoff From owner-multi6@ops.ietf.org Thu Nov 4 02:59:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23693 for ; Thu, 4 Nov 2004 02:59:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPcUn-0002yF-Kv for multi6-data@psg.com; Thu, 04 Nov 2004 07:57:25 +0000 Received: from [203.178.142.146] (helo=mail.sfc.wide.ad.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPcUl-0002xZ-H9 for multi6@ops.ietf.org; Thu, 04 Nov 2004 07:57:24 +0000 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 1565E4C0AA; Thu, 4 Nov 2004 16:57:23 +0900 (JST) Date: Thu, 4 Nov 2004 17:00:02 +0900 From: Thierry Ernst To: Multi6 Cc: chan Subject: Re: Few comments on draft-ietf-multi6-architecture-02 Message-Id: <20041104170002.2545e529.ernst@sfc.wide.ad.jp> In-Reply-To: <551A450C-2CE7-11D9-8458-000D93ACD0FE@it> References: <20041102191522.0a5b3cab.ernst@sfc.wide.ad.jp> <551A450C-2CE7-11D9-8458-000D93ACD0FE@it> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Marcelo, > i just want to make a comment about one of the points that you are=20 > considering (this may be OT for this list though... but i hope that the=20 > chairs will let me know when to shut up :-) >=20 > El 02/11/2004, a las 11:15, Thierry Ernst escribi=F3: > > [BTW, just being curious, can't we consider a NEMO multihomed to 2 > > distincts ISPs as a site ? cf=20 > > draft-ietf-nemo-multihoming-issues-01.txt] > > >=20 > I am not sure that all the multihomed nemos can easily fall under the=20 > definition of a multihomed site. Sure, some case do fall under the definition of a multihomed site, some don't. > IMHO, there are cases where it is clearly so, and that the multi6=20 > solution will provide a solution for the multihomed nemo, while in some=20 > other cases, i am not so sure. >=20 > For instance, suppose a nemo that has a multihomed home network. So the=20 > nemo has two prefixes, one per ISP of the home network. In this case i=20 > guess that it is clear that the multi6 solution should apply to this=20 > network, i guess. >=20 > The same case could be when the nemo has two home networks (which i=20 > guess that is the case that you are considering) >=20 > I mean in all these cases, the point is that the multihoming doesn't=20 > occur between the nemo and the fixed network, but between the=20 > attachment of the home network(s) and the internet. I guess that in=20 > those cases, the multi6 solution should apply. OK for the 1st case, but in the second case (the nemo has 2 home networks), I would rather see the multihoming occuring between the nemo and the home network.=20 =20 home network 1 | _AR | _-p1/56-|-|_|- p1/48 -- Internet |-|_| MR _ | -p2/56-|-|_|- p2/48 -- Internet | AR home network 2 =20 =20 > However, when we are considering a nemo that has multiple attachments=20 > points, and for instance only one nemo prefix, then the fundamental=20 > assumption of multi6 solution is no longer valid, since the nemo has a=20 > single prefix. I guess that in these cases, the usefulness of the=20 > multi6 solution will diminish. Agree. In such case, I wouldn't consider the nemo as a "site" therefore the site-multihoming solution wouldn't apply. > But anyway, i fell that it is very important to determine which parts=20 > of the nemo multihoming problem can be addressed with multi6 and which=20 > parts will require additional tools. Identifying which parts can be addressed by existing solutions of WG is something that we should definitely clarify in draft-ietf-nemo-multihoming-issues. Thierry. From owner-multi6@ops.ietf.org Thu Nov 4 03:24:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26036 for ; Thu, 4 Nov 2004 03:24:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPcul-00071d-4a for multi6-data@psg.com; Thu, 04 Nov 2004 08:24:15 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPcuk-00071M-0x for multi6@ops.ietf.org; Thu, 04 Nov 2004 08:24:14 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA48ODIA117584 for ; Thu, 4 Nov 2004 08:24:13 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA48OD2Y066042 for ; Thu, 4 Nov 2004 08:24:13 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA48OCxu025796 for ; Thu, 4 Nov 2004 08:24:12 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA48OCEP025787 for ; Thu, 4 Nov 2004 08:24:12 GMT Received: from zurich.ibm.com (sig-9-145-250-203.de.ibm.com [9.145.250.203]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA73914 for ; Thu, 4 Nov 2004 09:24:12 +0100 Message-ID: <4189E72B.8060601@zurich.ibm.com> Date: Thu, 04 Nov 2004 09:24:11 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: multi6 WG Last Calls closed Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Three multi6 WG Last Calls closed on November 3. draft-ietf-multi6-architecture-02.txt draft-ietf-multi6-things-to-think-about-00.txt draft-ietf-multi6-v4-multihoming-02.txt We had some good comments on all three drafts, and the authors are requested to make the appropriate updates as soon as possible. Most of the points seem to have been resolved in email discussion, but any remaining specific issues should be surfaced on this list. In my opinion, the two big open issues are draft-ietf-multi6-v4-multihoming-02.txt Thierry Ernst: "to be honest, I don't really understand the value of the document." As I already said, we are chartered to produce this document, but its value is indeed "for the record". Does the WG think that is enough to justify publication? draft-ietf-multi6-architecture-02.txt Pekka Savola: "The document is rather long and conversational in tone." (plus specific comments related to this view). Does the WG agree with Pekka, to the point of asking for a major revision effort? Brian co-chair From owner-multi6@ops.ietf.org Thu Nov 4 09:48:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26041 for ; Thu, 4 Nov 2004 09:48:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPitc-0001Sm-Gn for multi6-data@psg.com; Thu, 04 Nov 2004 14:47:28 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPitV-0001SD-32 for multi6@ops.ietf.org; Thu, 04 Nov 2004 14:47:21 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B068D2FE8D; Thu, 4 Nov 2004 15:47:19 +0100 (CET) Received: from [163.117.139.54] (unknown [163.117.139.54]) by smtp03.uc3m.es (Postfix) with ESMTP id 9AB722FE85; Thu, 4 Nov 2004 15:47:19 +0100 (CET) In-Reply-To: <20041104170002.2545e529.ernst@sfc.wide.ad.jp> References: <20041102191522.0a5b3cab.ernst@sfc.wide.ad.jp> <551A450C-2CE7-11D9-8458-000D93ACD0FE@it> <20041104170002.2545e529.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6DD8E79E-2E70-11D9-A24C-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: Multi6 , chan From: marcelo bagnulo braun Subject: Re: Few comments on draft-ietf-multi6-architecture-02 Date: Thu, 4 Nov 2004 15:47:19 +0100 To: Thierry Ernst X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 04/11/2004, a las 9:00, Thierry Ernst escribi=F3: > > OK for the 1st case, but in the second case (the nemo has 2 home > networks), I would rather see the multihoming occuring between the > nemo and the home network. > > home network 1 > | _AR > | _-p1/56-|-|_|- p1/48 -- Internet > |-|_| MR _ > | -p2/56-|-|_|- p2/48 -- Internet > | AR > home network 2 > > ok, sorry for not fully specifying my idea. I was thinking about the=20 case where there is a single MR and two HAs, in which case, the=20 situation is less clear. anyway, i guess that the key issue is the=20 point below... >> However, when we are considering a nemo that has multiple attachments >> points, and for instance only one nemo prefix, then the fundamental >> assumption of multi6 solution is no longer valid, since the nemo has = a >> single prefix. I guess that in these cases, the usefulness of the >> multi6 solution will diminish. > > Agree. In such case, I wouldn't consider the nemo as a "site" = therefore > the site-multihoming solution wouldn't apply. > >> But anyway, i fell that it is very important to determine which parts >> of the nemo multihoming problem can be addressed with multi6 and = which >> parts will require additional tools. > > Identifying which parts can be addressed by existing solutions of WG = is > something that we should definitely clarify in > draft-ietf-nemo-multihoming-issues. yes, imho this is the first thing that we should do with multihoming in=20= nemo, but for this we need to understand the basic multi6 solution, i=20 guess, which is still not defined... regards, marcelo > > Thierry. > > > > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Thu Nov 4 10:19:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29616 for ; Thu, 4 Nov 2004 10:19:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CPjNi-0005Xv-9r for multi6-data@psg.com; Thu, 04 Nov 2004 15:18:34 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CPjNO-0005Vg-68 for multi6@ops.ietf.org; Thu, 04 Nov 2004 15:18:14 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA4FI3730334; Thu, 4 Nov 2004 16:18:03 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iA4FI3Sj068939; Thu, 4 Nov 2004 16:18:03 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411041518.iA4FI3Sj068939@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: marcelo bagnulo braun cc: multi6@ops.ietf.org, Tuomas Aura Subject: Re: about draft-bagnulo-multi6dt-hba-00.txt In-reply-to: Your message of Wed, 03 Nov 2004 15:59:32 +0100. Date: Thu, 04 Nov 2004 16:18:03 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, NEW_DOMAIN_EXTENSIONS autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: > we are planning to implement HBA, so this would be really helpful. > I will contact you later. > > => I had some free time in this long weekend so I wrote the code great! are you planning to make it public? => yes but I don't know how (i.e., where). > now I have some new comments: > - draft-ietf-send-cga-06.txt is not clear enough about where the > extension > fields are included in the hash (here the multi-prefix extension) : Well, as i read it, the new extensions should be included both in the cga generation and verification, only that since at this point there are no extension specified, the algorithm presented in the spec doesn't explicitely include them. => so the text (in draft-ietf-send-cga-06.txt) should be clarified to explicitely include them... > So in draft-bagnulo-multi6dt-hba-00.txt the extension is in Hash2 > (good decision) but not in Hash1 (does it matter?): well, this is my mistake, thanks for catching it The multiprefix extension should be included both in the generation and the verification of HAsh1 i will fix this in the next version => well. AFAIU, the multiprefix extension should be included both in the generation and verification of Hash1 and Hash2 => this is only a problem in specifications (all everywhere should say the same thing, here that all extensions are included). > - the second point is about the Ext Type (TBD IANA): we have to > propose > a common value in order to get interoperability (and examples :-). > Ok, would you propose a value that you like? ( i mean what did you use in your implementation? :-) => I use 0x12 but it can be easily changed (I have only to fix the define and to recompute the example in the test). > - the last point is about the collision count: I believe it should be > per HBA not global as described: I can see that there is an advantage in making the collision count per HBA as you suggest, since in the case that DAD fails, then you only need to regenerate a single HBA and not the whole set. => yes, this is the issue... and with a common collision count I have to add a new function to compute explicitely the addresses (today it is done by an optional side-effect per HBA). This doesn't really matter but the point needs (needed) to be clarified. Thanks Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Fri Nov 5 07:31:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06640 for ; Fri, 5 Nov 2004 07:31:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CQ3Dl-0008Bl-4F for multi6-data@psg.com; Fri, 05 Nov 2004 12:29:37 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CQ3Dg-0008BK-O4 for multi6@ops.ietf.org; Fri, 05 Nov 2004 12:29:33 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA5CTVxX232044 for ; Fri, 5 Nov 2004 12:29:31 GMT Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA5CTULA082014 for ; Fri, 5 Nov 2004 13:29:31 +0100 Received: from zurich.ibm.com (sig-9-145-250-206.de.ibm.com [9.145.250.206]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA33216 for ; Fri, 5 Nov 2004 13:29:30 +0100 Message-ID: <418B7226.4040501@zurich.ibm.com> Date: Fri, 05 Nov 2004 13:29:26 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: I-D ACTION:draft-arifumi-multi6-sas-policy-dist-00.txt References: <200410211948.PAA12822@ietf.org> In-Reply-To: <200410211948.PAA12822@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 3.1 Multihome Site with Global-Closed Mixed Connectivity > > ============== > | Internet | > ============== > | > 2001:db8::/32 | 3ffe:1800::/32 > +----+-+ +-+----+ > | ISP1 | | ISP2 | (Closed Network) > +----+-+ +-+----+ > | | > 2001:db8:a::/48 | | 3ffe:1800:a::/48 > (DHCP-PD') ++-------++ (DHCP-PD') > | Gateway | > +----+----+ > | 2001:db8:a:1::/64 > | 3ffe:1800:a:1::/64 > | (RA'/DHCP') > ------+---+---------- > | > +-+----+ 2001:db8:a:1:[EUI64] > | Host | 3ffe:1800:a:1:[EUI64] > +------+ I'm afraid I don't see why this case is of interest to multi6. It is a case where the user site is connected to one ISP and to one WGP (walled garden provider). This is not site multihoming in the sense of multi6. As far as I can see, a longest match is sufficient to tell the host which source prefix to use. > 3.2 Host with Multiple Home Addresses and Connectivity to Two Global > Networks This is the case of interest to multi6. ... > Note that the end nodes are notified of an address-selection policy > that includes prefix ::/0 by both ISPs, hence a specific source > address for ::/0 can't be determined in the Label-Rule judgment > phase described in RFC3484. So, these entries for prefix ::/0 won't > actually be stored in the policy table, and this policy table won't > have any effect on source-address selection for packets that match > ::/0. The source address in these cases will be determined by > following rules listed in RFC3484, such as longest match with the > destination address. Exactly. And it is this case - when two ISPs both offer connectivity to ::/0 - that multi6 has to solve. That seems to be the case you don't help with. > Unlike the previous example (3.1.1(iv)), normal destination- > address-based routing doesn't specify a particular next-hop. > > Dst Next-Hop > 2001:db8::/32 ISP1 > ::/0 ISP1 > 3ffe:1800::/32 ISP2 > ::/0 ISP2 i.e., it doesn't help me choose the appropriate exit router and source prefix to use for a given destination in ::/0. That would only be possible if the table contained separate entries for every prefix that each ISP can route to - that amounts to the whole BGP table for each ISP - with a metric. Which certainly doesn't scale. Brian From matt_nens50@yahoo.com Fri Nov 5 16:04:49 2004 Received: from web90105.mail.scd.yahoo.com (web90105.mail.scd.yahoo.com [66.218.94.76]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17405 for ; Fri, 5 Nov 2004 16:04:49 -0500 (EST) Received: (qmail 97821 invoked by uid 60001); 5 Nov 2004 21:04:20 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=FYwqCDkrCE4+O5rSlCP7zrxtp0J3LpkWyc+ahW+FRpd/8NHFgFBRab8BzbU8yK460B6HMX+jjD7TbtdkeW0BzGeVx3zJOVGFrkev6oIwPMVNDgBuYIHdROOImn2w2/1Lc16pYJ19J8VCLYXdEkWYO45MoO+wsO8WVoEFMEIjaUY= ; Message-ID: <20041105210420.97819.qmail@web90105.mail.scd.yahoo.com> Received: from [196.201.65.6] by web90105.mail.scd.yahoo.com via HTTP; Fri, 05 Nov 2004 13:04:20 PST Date: Fri, 5 Nov 2004 13:04:20 -0800 (PST) From: matt nens Subject: LETTER OF ASSISTANCE To: matt_nens50@yahoo.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1937460018-1099688660=:97095" --0-1937460018-1099688660=:97095 Content-Type: text/plain; charset=us-ascii FROM MATT NENS ABIDJAN-COTE D'IVOIRE WEST AFRICA. Dearest one, permit me to inform you of my desire of going intobusiness relationship with you. I have the believe youare a reputable and responsible and trustworthy person I can do business with from the little information so far I gathered about you through your profile for a partner and by matter of trust I must not hesitate to confide in you for this simple and sincere business. I am MATT NENS 23 years of age the only son of late Mr Boni Jake whom was killed by the rebels that attacked our country cote d'Ivoire west Africa and took over our town (BOUAKE). I ran to Abidjan the economical capital of cote d'ivoire from were I am contacting you.Before the death of my father he told me that he has a sum of US$9,000,000(Nine million united states dollars) kept in a private security company in cote d'ivoire in my name as the next of kin, but during the rebel attack in cote d ivoire, I was informed by the company that all consignment have been moved to their branch office in EUROPE. Sir, in the capacity of the next of kin, I am contacting you with due sence of humanity and responsibility and with few awareness that you will give it a sympathetic and mutual consideration. I am honourably seeking your assistance in the following ways. (1)To provide a bank account where this money would be transferred to. (2)To serve as the guardian of this fund and to visit the security company in EUROPE to take delivery of the consignment. (3)To make arrangement for me to come over to your country to further my education and to secure a residential permit for me in your country. (4)To provide good investment plans for the fund and to manage the fund for 5 years, during the investment period,only our profit will be shared annually 70% for me the investor while 30% will be for you the fund manager annually. Moreover, I am willing to offer you 20 % of the total sum as compensation for your effort /input after the successful transfer of this fund to your nominated account overseas before the investments starts.and I have maped 5% for any expenses that might be incured during the course of this transaction. furthermore, you can indicate your option towards assisting me as I believe that this transaction would be concluded within a stipulated period of time you signify your interest to assist me. Anticipating hearing from you immediately to my private email: matt_nens50@yahoo.com Thanks and God bless. Best Regards. MATT NENS --------------------------------- Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com/a --0-1937460018-1099688660=:97095 Content-Type: text/html; charset=us-ascii
FROM MATT NENS
ABIDJAN-COTE D'IVOIRE
WEST AFRICA.

Dearest one,

permit me to inform you of my desire of going intobusiness relationship with you. I have the believe youare a reputable and responsible and trustworthy person I can do business with from the little information so far I gathered about you through your profile for a partner and by matter of trust I must not hesitate to
confide in you for this simple and sincere business.

I am MATT NENS 23 years of age the only son of late Mr Boni Jake whom was killed by the rebels that attacked our country cote d'Ivoire west Africa and
took over our town (BOUAKE). I ran to Abidjan the economical capital of cote d'ivoire from were I am contacting you.Before the death of my father he told
me that he has a sum of US$9,000,000(Nine million united states dollars) kept in a private security company in cote d'ivoire in my name as the next of
kin, but during the rebel attack in cote d ivoire, I was informed by the company that all consignment have been moved to their branch office in EUROPE.
 
Sir, in the capacity of the next of kin, I am contacting you with due sence of humanity and responsibility and with few awareness that you will
give it a sympathetic and mutual consideration. I am honourably seeking your assistance in the following ways.

(1)To provide a bank account where this money would be transferred to.

(2)To serve as the guardian of this fund and to visit the security company in EUROPE to take delivery of the consignment.

(3)To make arrangement for me to come over to your country to further my education and to secure a residential permit for me in your country.

(4)To provide good investment plans for the fund and to manage the fund for 5 years, during the investment period,only our profit will be shared annually 70% for me the investor while 30% will be for you the fund manager annually. Moreover, I am willing to offer you 20 % of the total sum as compensation for your effort /input after the successful transfer of this fund to your nominated account overseas before the investments starts.and I have maped 5% for any expenses that might be incured during the course of this transaction.

furthermore, you can indicate your option towards assisting me as I believe that this transaction would be concluded within a stipulated period of time you signify your interest to assist me. Anticipating hearing from you immediately to my private email:
matt_nens50@yahoo.com
 
Thanks and God bless.
Best Regards.
MATT NENS

Do you Yahoo!?
Check out the new Yahoo! Front Page. www.yahoo.com; Sat, 6 Nov 2004 16:38:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CQYEA-000GJo-Bs for multi6-data@psg.com; Sat, 06 Nov 2004 21:36:06 +0000 Received: from [63.240.218.73] (helo=s-utl01-dcpop.stsn.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CQYE9-000GJb-IW for multi6@ops.ietf.org; Sat, 06 Nov 2004 21:36:05 +0000 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004110616360410542 for ; Sat, 06 Nov 2004 16:36:04 -0500 Received: from laptop2.kurtis.pp.se ([10.67.87.47]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Nov 2004 16:35:54 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id EB47564E051; Sat, 6 Nov 2004 22:02:44 +0100 (CET) In-Reply-To: <6.0.1.1.2.20041104085249.0233a730@kahuna.telstra.net> References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> <4185F340.2080701@zurich.ibm.com> <3AB79A56-2CE5-11D9-8458-000D93ACD0FE@it.uc3m.es> <4188263E.7060009@sun.com> <8A5F0886-2D67-11D9-AA47-000A95928574@kurtis.pp.se> <6.0.1.1.2.20041104085249.0233a730@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <7C7A1CFD-301A-11D9-88D6-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 , marcelo bagnulo braun , Brian E Carpenter , Erik Nordmark From: Kurt Erik Lindqvist Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt Date: Sat, 6 Nov 2004 18:37:09 +0100 To: Geoff Huston X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 06 Nov 2004 21:35:54.0313 (UTC) FILETIME=[982F1B90:01C4C448] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-11-03, at 22.55, Geoff Huston wrote: > At 06:11 PM 3/11/2004, Kurt Erik Lindqvist wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On 2004-11-03, at 01.28, Erik Nordmark wrote: >> >> > If a host wants to prevent packet injection attacks today (such as >> > spoofed RCP RST packets, if it wants to prevent it from all nodes >> and >> > not depend on ingress filtering, wouldn't it use IPsec? >> >> That would have to be a must. I can't see anyone building a trust >> model >> based on (the non-existing) ingress filtering. That said, I think most >> protection against packet injection attacks on todays Internet is >> actually left to ULPs. > > I take it that you are classifying TCP as a ULP in this instance? Yes. > As I understand it TCP attempts to provide protection against packet > injection attacks and does not allow its ULP any discretion, > while UDP simply passes the packet upward and places the onus on its > ULP to detect injected bogus packets in the UDP exchange. Agreed. I simply meant "something above IP" with ULP... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQY0LyaarNKXTPFCVEQJh5QCfYNn3Wii1H/PV4mEyWHB6xOM48a8An3ex 9HwKz/uVD0y2e7KYQ4/gDCN+ =g/Nq -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sat Nov 6 21:21:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26689 for ; Sat, 6 Nov 2004 21:21:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CQceT-000Nid-MS for multi6-data@psg.com; Sun, 07 Nov 2004 02:19:33 +0000 Received: from [63.240.218.73] (helo=s-utl01-dcpop.stsn.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CQceS-000NiP-Sd for multi6@ops.ietf.org; Sun, 07 Nov 2004 02:19:32 +0000 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004110621193212050 for ; Sat, 06 Nov 2004 21:19:32 -0500 Received: from laptop2.kurtis.pp.se ([10.67.87.47]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 6 Nov 2004 21:19:21 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id EB47564E051; Sat, 6 Nov 2004 22:02:44 +0100 (CET) In-Reply-To: <6.0.1.1.2.20041104085249.0233a730@kahuna.telstra.net> References: <200410191148.HAA14355@ietf.org> <4180E82C.302@zurich.ibm.com> <4182B26D.2050306@sun.com> <496A5E72-2AA5-11D9-AB06-000D93ACD0FE@it> <4185F340.2080701@zurich.ibm.com> <3AB79A56-2CE5-11D9-8458-000D93ACD0FE@it.uc3m.es> <4188263E.7060009@sun.com> <8A5F0886-2D67-11D9-AA47-000A95928574@kurtis.pp.se> <6.0.1.1.2.20041104085249.0233a730@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <7C7A1CFD-301A-11D9-88D6-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 , marcelo bagnulo braun , Brian E Carpenter , Erik Nordmark From: Kurt Erik Lindqvist Subject: Re: I-D ACTION:draft-nordmark-multi6dt-shim-00.txt Date: Sat, 6 Nov 2004 18:37:09 +0100 To: Geoff Huston X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-OriginalArrivalTime: 07 Nov 2004 02:19:22.0130 (UTC) FILETIME=[31A20720:01C4C470] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-11-03, at 22.55, Geoff Huston wrote: > At 06:11 PM 3/11/2004, Kurt Erik Lindqvist wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On 2004-11-03, at 01.28, Erik Nordmark wrote: >> >> > If a host wants to prevent packet injection attacks today (such as >> > spoofed RCP RST packets, if it wants to prevent it from all nodes >> and >> > not depend on ingress filtering, wouldn't it use IPsec? >> >> That would have to be a must. I can't see anyone building a trust >> model >> based on (the non-existing) ingress filtering. That said, I think most >> protection against packet injection attacks on todays Internet is >> actually left to ULPs. > > I take it that you are classifying TCP as a ULP in this instance? Yes. > As I understand it TCP attempts to provide protection against packet > injection attacks and does not allow its ULP any discretion, > while UDP simply passes the packet upward and places the onus on its > ULP to detect injected bogus packets in the UDP exchange. Agreed. I simply meant "something above IP" with ULP... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQY0LyaarNKXTPFCVEQJh5QCfYNn3Wii1H/PV4mEyWHB6xOM48a8An3ex 9HwKz/uVD0y2e7KYQ4/gDCN+ =g/Nq -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Nov 7 00:01:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06069 for ; Sun, 7 Nov 2004 00:01:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CQfAG-000HIN-HV for multi6-data@psg.com; Sun, 07 Nov 2004 05:00:32 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CQfAF-000HI0-KT for multi6@ops.ietf.org; Sun, 07 Nov 2004 05:00:31 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 025AD653 for ; Sun, 7 Nov 2004 00:00:31 -0500 (EST) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 07 Nov 2004 00:00:30 -0500 Message-Id: <20041107050031.025AD653@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 27.50% | 11 | 24.77% | 43525 | brc@zurich.ibm.com 17.50% | 7 | 21.19% | 37230 | marcelo@it.uc3m.es 10.00% | 4 | 12.79% | 22477 | gih@apnic.net 10.00% | 4 | 9.95% | 17486 | john.loughney@nokia.com 10.00% | 4 | 8.00% | 14049 | ernst@sfc.wide.ad.jp 10.00% | 4 | 7.43% | 13056 | kurtis@kurtis.pp.se 7.50% | 3 | 6.17% | 10845 | erik.nordmark@sun.com 5.00% | 2 | 5.88% | 10332 | francis.dupont@enst-bretagne.fr 2.50% | 1 | 3.80% | 6683 | pekkas@netcore.fi --------+------+--------+----------+------------------------ 100.00% | 40 |100.00% | 175683 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Nov 7 12:00:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04673 for ; Sun, 7 Nov 2004 12:00:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CQqNj-000PCZ-Oi for multi6-data@psg.com; Sun, 07 Nov 2004 16:59:11 +0000 Received: from [130.129.135.217] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CQqNi-000PCF-Ph for multi6@ops.ietf.org; Sun, 07 Nov 2004 16:59:11 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id BDF6F64E04E; Sat, 6 Nov 2004 22:02:44 +0100 (CET) In-Reply-To: <4189E72B.8060601@zurich.ibm.com> References: <4189E72B.8060601@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <3FDCCC3F-301B-11D9-88D6-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Kurt Erik Lindqvist Subject: Re: multi6 WG Last Calls closed Date: Sat, 6 Nov 2004 18:42:37 +0100 To: Brian E Carpenter X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (co-chair hat-off) On 2004-11-04, at 09.24, Brian E Carpenter wrote: > In my opinion, the two big open issues are > > draft-ietf-multi6-v4-multihoming-02.txt > Thierry Ernst: "to be honest, I don't > really understand the value of the document." > > As I already said, we are chartered to produce this document, > but its value is indeed "for the record". Does the WG think that > is enough to justify publication? I have no real strong feeling one way or the other. I do think that we want this documented somewhere and if not in a separate document perhaps this could be fitted into the architectural analysis? But I am not sure that is the best place and I think that might add length to an already quite long document. > draft-ietf-multi6-architecture-02.txt > Pekka Savola: "The document is rather long and conversational > in tone." (plus specific comments related to this view). > > Does the WG agree with Pekka, to the point of asking for a > major revision effort? No. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQY0NEaarNKXTPFCVEQL7AwCcDLTwBZSQBnwSkmyu0ME/1FiQIj8An0R8 4QqXK6TtXeeXqS0tAO6rVEIk =YXB9 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Nov 7 16:48:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01200 for ; Sun, 7 Nov 2004 16:48:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CQus2-000CkC-Ja for multi6-data@psg.com; Sun, 07 Nov 2004 21:46:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CQus1-000Cju-EO for multi6@ops.ietf.org; Sun, 07 Nov 2004 21:46:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA7LkYA24327; Sun, 7 Nov 2004 23:46:38 +0200 Date: Sun, 7 Nov 2004 23:46:34 +0200 (EET) From: Pekka Savola To: Kurt Erik Lindqvist cc: Brian E Carpenter , Multi6 Subject: Re: multi6 WG Last Calls closed In-Reply-To: <3FDCCC3F-301B-11D9-88D6-000A95928574@kurtis.pp.se> Message-ID: References: <4189E72B.8060601@zurich.ibm.com> <3FDCCC3F-301B-11D9-88D6-000A95928574@kurtis.pp.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Sat, 6 Nov 2004, Kurt Erik Lindqvist wrote: >> In my opinion, the two big open issues are >> >> draft-ietf-multi6-v4-multihoming-02.txt >> Thierry Ernst: "to be honest, I don't >> really understand the value of the document." >> >> As I already said, we are chartered to produce this document, >> but its value is indeed "for the record". Does the WG think that >> is enough to justify publication? > > I have no real strong feeling one way or the other. I do think that we > want this documented somewhere and if not in a separate document > perhaps this could be fitted into the architectural analysis? But I am > not sure that is the best place and I think that might add length to an > already quite long document. I think the doc we have should be sufficiently useful, and besides, we've been requested to do. I'd say just ship it and if the IESG evaluation shows that it's not good enough, let's reconsider. >> draft-ietf-multi6-architecture-02.txt >> Pekka Savola: "The document is rather long and conversational >> in tone." (plus specific comments related to this view). >> >> Does the WG agree with Pekka, to the point of asking for a >> major revision effort? To be clear, even though I said "rather long and conversational in tone", I was *not* asking the document to be rewritten to _not_ be that. What I was hoping was maybe some more structure and changes in the document's organization so that the "conversation" would be more manageable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Nov 8 04:18:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13537 for ; Mon, 8 Nov 2004 04:18:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CR5dh-000FBg-S7 for multi6-data@psg.com; Mon, 08 Nov 2004 09:16:41 +0000 Received: from [192.68.245.115] (helo=mail.nttv6.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CR5dg-000FBP-5J for multi6@ops.ietf.org; Mon, 08 Nov 2004 09:16:40 +0000 Received: from [IPv6:::1] (localhost.nttv6.net [127.0.0.1]) by mail.nttv6.net (8.13.1/3.7Wpl2-00020918) with ESMTP id iA89DtKU074266; Mon, 8 Nov 2004 18:13:57 +0900 (JST) In-Reply-To: <418B7226.4040501@zurich.ibm.com> References: <200410211948.PAA12822@ietf.org> <418B7226.4040501@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Arifumi Matsumoto Subject: Re: I-D ACTION:draft-arifumi-multi6-sas-policy-dist-00.txt Date: Mon, 8 Nov 2004 18:16:34 +0900 To: Brian E Carpenter X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Brian, thank you for comments. On 2004/11/05, at 21:29, Brian E Carpenter wrote: >> 3.1 Multihome Site with Global-Closed Mixed Connectivity >> ============== >> | Internet | >> ============== >> | >> 2001:db8::/32 | 3ffe:1800::/32 >> +----+-+ +-+----+ >> | ISP1 | | ISP2 | (Closed Network) >> +----+-+ +-+----+ >> | | >> 2001:db8:a::/48 | | 3ffe:1800:a::/48 >> (DHCP-PD') ++-------++ (DHCP-PD') >> | Gateway | >> +----+----+ >> | 2001:db8:a:1::/64 >> | 3ffe:1800:a:1::/64 >> | (RA'/DHCP') >> ------+---+---------- >> | >> +-+----+ 2001:db8:a:1:[EUI64] >> | Host | 3ffe:1800:a:1:[EUI64] >> +------+ > > > I'm afraid I don't see why this case is of interest to multi6. > It is a case where the user site is connected to one ISP and > to one WGP (walled garden provider). This is not site multihoming > in the sense of multi6. As far as I can see, a longest match is > sufficient to tell the host which source prefix to use. Actually longest match isn't sufficient. If a packet is destined for a closed network, an appropriate source address is chosen automatically by longest match. On the other hand, a packet is destined for somewhere in the Internet, it is not always true. For example, when a packet is destined for 3ffe:1801::1 in the Internet, the source address will be the one delegated by ISP2(WGP). In the end, the reply packet for it never returns because of the wall. Anyway, I agree that this case may not be the scope of multi6. > >> 3.2 Host with Multiple Home Addresses and Connectivity to Two Global >> Networks > > This is the case of interest to multi6. > > ... >> Note that the end nodes are notified of an address-selection >> policy >> that includes prefix ::/0 by both ISPs, hence a specific source >> address for ::/0 can't be determined in the Label-Rule judgment >> phase described in RFC3484. So, these entries for prefix ::/0 >> won't >> actually be stored in the policy table, and this policy table >> won't >> have any effect on source-address selection for packets that >> match >> ::/0. The source address in these cases will be determined by >> following rules listed in RFC3484, such as longest match with the >> destination address. > > Exactly. And it is this case - when two ISPs both offer connectivity to > ::/0 - that multi6 has to solve. That seems to be the case you don't > help with. Though I didn't include them in this version of my I-D, we are thinking of some other solutions. For those hosts that can support ECMP(equal cost multi-path) or some other special mechanisms for multihoming, it would be helpful to notify all the default routes and all the SAS Policies for default routes as I mentioned in I-D. For normal hosts, however, it would be better not to notify multiple routes for the same destination network. So, it should be configurable on routers not to announce multiple routes but to choose one. The configuration will be like prioritizing ISPs. It may be useful to define a new DHCP option for Solicit message that explicitly requests for multiple routes for the same destination network. -- Arifumi Matsumoto Ubiquitous Computing Project NTT Information Sharing Platform Laboratories E-mail: arifumi@nttv6.net From owner-multi6@ops.ietf.org Mon Nov 8 10:48:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22756 for ; Mon, 8 Nov 2004 10:48:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRBjC-0006i3-Ph for multi6-data@psg.com; Mon, 08 Nov 2004 15:46:46 +0000 Received: from [212.68.1.186] (helo=pegasus.hiit.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRBiu-0006gK-61 for multi6@ops.ietf.org; Mon, 08 Nov 2004 15:46:28 +0000 Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id 69B22220006; Mon, 8 Nov 2004 17:46:24 +0200 (EET) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 24E768; Mon, 8 Nov 2004 17:46:25 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <58336276-319D-11D9-A88A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List Reply-To: hipsec-rg@honor.trusecure.com, Pekka Nikander From: Pekka Nikander Subject: A lowest layer with location independent identifiers with more than one protocols Date: Mon, 8 Nov 2004 10:46:24 -0500 To: hipsec-rg@honor.trusecure.com X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [Replies directed to hipsec-rg, be careful.] As some of you may know, we had a workshop on "HIP and Related Architectures" on Saturday. There were a number of conclusions from the workshop; they will be presented at the HIP RG on Saturday. However, there were a couple ones that IMHO may be important also to the multi6 folks, and I'd like to share them. Firstly, it was determined that there seems to be some value of providing "a lowest layer that supports location independent identifiers" In a way, that seems to be exactly what multi6 is trying to provide. Secondly, some people expressed their discomfort with the HIP approach of combining identifiers and security. Ion Stoica and Scott Shenker put it out nicely, saying that HIP provides A. A mapping from a public key to an identifier, and B. A mapping from an identifier to a set of locators Based on this observation, we came to an analogy. Consider the case with current TCP and UDP. They are on the same layer, and provide the same kind of *identifier* abstraction. However, they provide different communication semantics. In a way, one could perhaps characterise that "UDP is TCP without congestion control". (I know, that is not quite true, but I wish you get the point.) In the same way, there might be value to have more than one protocols at the "lowest layer that supports location independent identifiers". These multiple protocols would all provide the same kind of *identifier* abstraction, but different semantics. One of the protocols might be HIP, with both A and B. Another protocol might be something else, maybe with just B without A. That might be what multi6 is aiming for. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Nov 8 12:59:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07290 for ; Mon, 8 Nov 2004 12:59:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRDmf-000MD3-73 for multi6-data@psg.com; Mon, 08 Nov 2004 17:58:29 +0000 Received: from [130.233.215.20] (helo=neon.tcs.hut.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRDme-000MCj-7m for multi6@ops.ietf.org; Mon, 08 Nov 2004 17:58:28 +0000 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id E73C7800193 for ; Mon, 8 Nov 2004 19:58:26 +0200 (EET) Date: Mon, 8 Nov 2004 19:58:26 +0200 (EET) From: Wassim Haddad To: multi6@ops.ietf.org Subject: [Mip6] Bar-Bof on Privacy scheduled for Monday, Nov 8th (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk FYI, ---------- Forwarded message ---------- Date: Mon, 8 Nov 2004 10:10:40 -0600 From: Basavaraj.Patil@nokia.com To: mip6@ietf.org Cc: multi6@ops.ietf.org Subject: [Mip6] Bar-Bof on Privacy scheduled for Monday, Nov 8th Hello, Note that the privacy Bar-Bof will be held in meeting room Lincoln at 10 PM on Monday, Nov 8th. Please join the discussion. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From owner-multi6@ops.ietf.org Mon Nov 8 15:36:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27352 for ; Mon, 8 Nov 2004 15:36:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRGET-000DGv-Rp for multi6-data@psg.com; Mon, 08 Nov 2004 20:35:21 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRGES-000DGY-Mj for multi6@ops.ietf.org; Mon, 08 Nov 2004 20:35:21 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8KZIW10743; Mon, 8 Nov 2004 22:35:18 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 22:35:00 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA8KZ00n015030; Mon, 8 Nov 2004 22:35:00 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00HqQAv4; Mon, 08 Nov 2004 22:34:59 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8KYwS29739; Mon, 8 Nov 2004 22:34:58 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 22:34:56 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 22:34:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: A lowest layer with location independent identifiers with more than one protocols Date: Mon, 8 Nov 2004 22:34:55 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D09585E@esebe056.ntc.nokia.com> Thread-Topic: A lowest layer with location independent identifiers with more than one protocols Thread-Index: AcTFq7bsybkzXbstQHmc5Y4Y/laFugAJYUlg From: To: , Cc: X-OriginalArrivalTime: 08 Nov 2004 20:34:54.0742 (UTC) FILETIME=[67BC6360:01C4C5D2] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, > Firstly, it was determined that there seems to be some value of=20 > providing >=20 > "a lowest layer that supports location independent identifiers" Could you explain a little bit more what you mean by this? Lowest layer of what & what value is there? Do you mean a lowest layer 3.5? =20 =20 > In a way, that seems to be exactly what multi6 is trying to provide. >=20 > Secondly, some people expressed their discomfort with the HIP approach > of combining identifiers and security. Ion Stoica and Scott Shenker > put it out nicely, saying that HIP provides >=20 > A. A mapping from a public key to an identifier, and > B. A mapping from an identifier to a set of locators >=20 > Based on this observation, we came to an analogy. Consider the case > with current TCP and UDP. They are on the same layer, and provide the > same kind of *identifier* abstraction. However, they provide = different > communication semantics. In a way, one could perhaps characterise = that > "UDP is TCP without congestion control". (I know, that is not quite=20 > true, but I wish you get the point.) I get this point, but you should at least add that different protocols=20 use different transport protocols because these transport protocols provide different services. =20 =20 > In the same way, there might be value to have more than one protocols > at the "lowest layer that supports location independent identifiers". > These multiple protocols would all provide the same kind of = *identifier* > abstraction, but different semantics. One of the protocols might be > HIP, with both A and B. Another protocol might be something else, = maybe > with just B without A. That might be what multi6 is aiming for. This might be useful, but you should be mindful that HIP and Multi6, = then, could potentially provide different services to the protocols that run on top of them. The reasons for using HIP vs. Multi6, then, could be based upon the services provided. John From owner-multi6@ops.ietf.org Mon Nov 8 19:40:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24260 for ; Mon, 8 Nov 2004 19:40:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRK0G-000Bxd-2A for multi6-data@psg.com; Tue, 09 Nov 2004 00:36:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRK04-000BwD-Ck for multi6@ops.ietf.org; Tue, 09 Nov 2004 00:36:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA90agN29167 for ; Tue, 9 Nov 2004 02:36:42 +0200 Date: Tue, 9 Nov 2004 02:36:42 +0200 (EET) From: Pekka Savola To: multi6@ops.ietf.org Subject: Comments on multi6dt documents Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Hi, I read the 5-document set of multi6dt documents. In general, I thought they were a very useful start, but there were some inconsistancies across documents, and clearly there was not yet time to analyze how the solution (or different pieces of solution) correspond to the "thinks-to-think-about" document. This especially seemed to be the case with the shim layer document, which might end up having some potentially significant issues. =============================== HBA: substantial ----------- I think there are two big issues: 1) The spec should have a clear section which describes the assumptions placed upon the features which must be supported in the multi6 solution. In this particular case, for example, the CGA Parameter Data Structure needs to be passed to the peers out of band because otherwise they can't perform verification. This might help in figuring out how the HBA address generation integrates to the rest of the multi6 solution problem space. 2) IPR. Unfortunately, SEND had IPR; fortunately, RF licensing was granted for implementations of SEND. Someone has to figure out how generic those patent applications were, i.e., whether HBA would be covered as well. editorial --------- 5. HBA verification ==> I spotted about 3 typos in this section, and one helluva long paragraph which should be split up. ================================== Referrals: substantial ----------- - "Identity" comparison. Some applications might retain the IP address, not as a means to initiate communication as in the above cases, but as a means to compare whether a peer is the same as another peer. While this is insecure in general, it might be something which is used e.g., when TLS is used. ==> I think the document should use a bit of space to discuss (or refer to) why identity comparison is insecure in general. This seems to be true in the sense that if you have an established secure application identity, and you come across a new identity which uses the same IP address in an insecured manner, then comparing them might not be sufficient (example: IPsec-secured w/ IP=1.1.1.1 session being tampered by a packet with source address of IP=1.1.1.1). But if the security levels of comparison are equal, I don't think there is a real problem. - Even if the bullet above is addressed somehow, the introduction of RFC 3041 temporary addresses for improved privacy adds to the burden. Today there is no mechanism for a host with temporary addresses to create temporary FQDNs that resolve to those addresses, and temporary FQDNs are necessary to preserve the difficulty of correlating these addresses with more permanent identifiers of the host. ==> this may or may not be true. RFC3041 even mentions DNS names based on RFC3041, as long as they are not identifying the real user, and draft-ietf-dnsop-ipv6-issues-10.txt discusses this a bit as well. I think the more appropriate formulation is that mechanisms do exist, but the hosts do not implement these automatically (an implementation issue), and even if they did, the DNS zone admins might not allow the required DNS updates. Unique local addresses could be treated following approach as just another locator which is known to be unreachable (at least when outside the site to which it is assigned), thus there might be some performance optimizations that can be applied. But the fact that the identifier is centrally assigned means that it is reasonable to ==> this draft makes the assumption that there would be only centrally allocated ULAs, which is not correct. There will definitely be other ULAs, but those would likely have no chance to be used in these kinds of mappings because there's chance this kind of mapping could be established. But that's quite different from this silent assumption. editorial --------- and for a given transport connection a pair consisting of a local and a peer locator are chosen as part of the identification of the connection. ==> s/a pair/, a pair/ ==> s/are// However, it is far from clear that this is feasible for all applications in all deployments. Reasons why FQDNs are problematic include ==> s/include/include:/ In this case it is possible to perform a reverse lookup of the single IP address to find out the FQDN, followed by a forward lookup of the FQDN to find all the AAAA records. This method finds all the locators registered in the DNS but assumes that both the reverse tree and the forward tree are maintained. ==> s/maintained/maintained in a consistent manner/ -- or the like: it's not sufficient to just put some stuff in the reverses or forward trees, they must be actively kept in sync. This is an area which is not often the case.. ==> s/likely/likely to/ [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the NSRG", draft-irtf-nsrg-report-09.txt (work in progress), March 2003. ==> wasn't this an RFC already? [HIP] Pekka Nikander, "Considerations on HIP based IPv6 multi- homing", 23-Jan-04, ==> I thought this became a HIP wg item? ================================== Failure detection: substantial ----------- Generic observation: I found section 2 extremly illustrative and useful -- I was surprised there has been a vast amount of work by different parties on this. It would seem to be natural to consider whether creating a mailing list for discussion of this particular topic would be a good idea; this touches on multi6, sctp, mobike, hip, and also application peoples' expectations about the robustness of mechanisms to detect network problems (for example, currently the mechanisms to recover from blackholed traffic are very poor, and this could help with non-multihomed case as well). Obviously, this could also lead to a trying to solve every problem (except maybe world hunger) and getting nothing done in the end, but I guess it might be useful to have some more united forum to discuss these issues rather than crossposting to about 5 different mailing lists :-) semi-editorial -------------- SCTP does not define how local knowledge (such as information learned from the link layer) should be used. SCTP also has no mechanism to deal with dynamic changes to the set of available addresses. ==> I think there is this "add-ip" extension to SCTP -- the standardization status of which I'm not familiar with -- but they have at least started to look at the problem space. Network attachment procedures are also relevant for multihoming. The IPv6 and MIP6 working groups have standardized mechanisms to dynamically learn about new networks that a node has attached to, ==> I don't think IPv6 WG has standardized anything on this space. Vanilla RFC2461 does not count as it's not sufficient to tell whether you've attached to a new link? o ICMP error messages. Given the ease of spoofing ICMP messages, one should be careful to not trust these blindly, however. Our suggestion is to use ICMP error messages only as a hint to perform an explicit reachability test, but not as a reason to disrupt ongoing communications without other indications of problems. ==> actually, robust implementations have long since started properly verifying the ICMP messages. For examples, as draft-gont-tcpm-icmp-attacks-00.txt describes, you can protect against ICMP attacks against TCP by verifying that the ICMP message includes the correct port numbers, seq/ack numbers etc., so that only (practically) on-the-path attacker could have generated them. There's not much UDP can do, because there's not much ICMP does to UDP, but something could be possible there as well, I'd guess. Architecturally, a number of questions arises. One simple question is whether there needs to be communications between a multihoming solution residing at the IP layer and upper layer protocols? Upon changing to a new address pair, transport layer protocol SHOULD be notified so that it can perform a slow start. ==> using 'slow start' might be a bit accurate, because there's not much slow in 'slow start' except the name. Did the draft mean a really slow start, or was aggressive probing OK as well? 5.2 State Machine for Address Pair Selection ==> the state machine doesn't appear to have the (trivial) even where adding a new pair would happen during testing the primary pair state. Our suggestion is that nodes MUST first consult RFC 3484 [5] policy tables to determine what combinations of addresses are legal from a local point of view, as this reduces the search space. ==> you're probably referring to extending RFC 3484 somehow, because AFAIR it can't be used like this. (Or were you referring to adding some destination host-specific policies in the table?) editorial --------- of useful terms and discusses them, and xref target='transport'/> ==> reference gone bad o The address is a global unicast or unique site-local address [8]. ==> s/site-// (Note that this notification can not be done in protocol designs where the end points are not the final hosts, such as where a gateway is used. ==> add ")" at the end Note that due to potentially asymmetric connectivity, both sides have to perform their own tests, and make their own primary pair selections. An action to reset a timer so that it will send an event after a specified time. ==> extra space there.. This process result in a combinatorial explosion when there are many ==> s/result/results/ [16] Nikander, P., "End-Host Mobility and Multi-Homing with Host Identity Protocol", draft-nikander-hip-mm-02 (work in progress), July 2004. ==> I was thinking this had just become hip WG document, but I may have been mistaken.. ================================ Shim layer: substantial ----------- The context state in this approach is maintained per remote ULID i.e. approximately per peer host, and not at any finer granularity. It might make sense to merge the context state for multiple ULIDs assigned to the same peer host, but this is for further study. ==> this spec seems to be silent about demultiplexing of external inputs which relate to an existing session, but do not have existing per peer host state. Example: ICMP unreachable message sent by a router pertaining to a packet sent (and mangled by the shim layer) by the host. These need to be dealt with somehow as well. In practice, this would seem to be creating a 1:1 NAT, and requiring to go down to the application payloads (e.g., stuff inside the ICMP message) as well. This needs to be considered explicitly, and discussed with pros/cons prominently. The approach makes no assumption about the reverse tree since the approach does not use it. However, applications might rely on the reverse tree whether multi6 is used or not. ==> across different documents, I think there have been some inconsistancies regarding this, e.g., as a means to find new or different locators by doing reverse+forward lookups. What's the real story here? (I think the shim approach does not require DNS in and of itself, but when something gets broken, like when applications start doing more advanced stuff, DNS is a way which could "come to the rescue"..) 8.1. Initial Context Establishment [...] When the policy is triggers, which could be on either A or B, an initial context establishment takes place. This exchange might fail should the peer not support the multi6 protocol. If it succeeds it results in both ends receiving the locator sets from their respective peer, and the security mechanism provides some way to verify these sets. ==> s/triggers/triggered/ (or something)? ==> is it possible / feasible to merge this functionality with steps 1 and 2? I.e., this does not discuss whether the set-up could be piggybacked upon earlier messages? There's plenty of space in those TCP conn. establishment messages, for example.. semi-editorial -------------- This document outlines an approach to solving IPv6 multihoming in order to stimulate discussion. ==> sigh.. this must have been written in haste, because there is no chance it is going to solve all the problems; just one rather important one (for small sites at least) Note that the hard issues with ULIDs is how to perform the mappings between them and the locator sets. With routable ULIDs the AAAA resource record set provides this "mapping". Non-routable ULIDs would need similar mechanisms, which is probably feasible for unique local addresses based on prefixes that are centrally assigned. ==> see my comments on referrals. The assumption of ULAs being central is bogus; it may be that no support will be possible for non-central ones is possible (and not necessarily even on central ones, depending on whether reverse tree gets built or not), but this needs to be stated explicitly. This approach would reduce the overhead. On the other hand, this approach would cause changes in the available MTU, since packets that include the Extension Header will have an MTU 8 octets shorter. ==> please also remember that in case if the required overhead changes (e.g., overhead is only needed in some special cases), it might be that the additional overhead triggers failure conditions which may be difficult to debug. Not a major problem, but something to bear in mind. [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): AN EXTENDED PROPOSAL", draft-crocker-mast-protocol-01.txt, October, 2003. ==> I believe this was superseded by CELP. editorial -------- Ls(A) is the locator set for A, which consists of L1(A), L2(A), ... Ln(A). ==> s/L1/locators L1/ This implies that the ULID section is performed as today's default ==> s/section/selection/ Should not all locators be working when the communication is initiated some extra complexity arises, because the ULP has already been told which ULIDs to use. If the locators that where selected to be ULIDs are not working and the multi6 shim does not know of alternate locators, it has to choice than to have the application try a different ULID. ==> s/where/were/ ==> s/choice/choose/ However, this approach requires support form the initiator node, implying that only upgraded nodes will obtain improves fault tolerance while legacy nodes that don't support the new DNS record will still obtain reduced fault tolerance capabilities. ==> s/form/from/ ==> s/improves/improved/ DNS to prevent them from every being used as ULIDs. The applications ==> s/every/ever/ The host-pair context is established on each end of the communication when one of the endpoints performs the multi6 signaling (the 4-way handshake referred to in [M6FUNC]. ==> s/]/])/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Nov 8 19:53:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25240 for ; Mon, 8 Nov 2004 19:53:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRKFF-000Ddz-Kt for multi6-data@psg.com; Tue, 09 Nov 2004 00:52:25 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRKFB-000DdE-Kp for multi6@ops.ietf.org; Tue, 09 Nov 2004 00:52:21 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA90qHW28047; Tue, 9 Nov 2004 02:52:17 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 02:52:12 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA90qC4c021780; Tue, 9 Nov 2004 02:52:12 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00l7NMmV; Tue, 09 Nov 2004 02:52:11 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA90qAa15837; Tue, 9 Nov 2004 02:52:10 +0200 (EET) Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 02:52:07 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 9 Nov 2004 02:52:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on multi6dt documents Date: Tue, 9 Nov 2004 02:52:07 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D431FE0@esebe056.ntc.nokia.com> Thread-Topic: Comments on multi6dt documents Thread-Index: AcTF9SsTDzDQwwYCTMO0FWmwgN9/kgAAE3kg From: To: , X-OriginalArrivalTime: 09 Nov 2004 00:52:07.0286 (UTC) FILETIME=[563FB960:01C4C5F6] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable quick comment: > semi-editorial > -------------- >=20 > SCTP does not define how local knowledge (such as information = learned > from the link layer) should be used. SCTP also has no mechanism = to > deal with dynamic changes to the set of available addresses. >=20 > =3D=3D> I think there is this "add-ip" extension to SCTP -- the = standardization > status of which I'm not familiar with -- but they have at least = started to > look at the problem space. The 'add-ip' extension has been proposed awhile ago, I know that there = are some implementations of it out there.=20 I know that some of the people involved have also proposed transport = mobility work as well. John From owner-multi6@ops.ietf.org Mon Nov 8 20:00:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25979 for ; Mon, 8 Nov 2004 20:00:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRKLG-000EZI-U1 for multi6-data@psg.com; Tue, 09 Nov 2004 00:58:38 +0000 Received: from [212.68.1.186] (helo=pegasus.hiit.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRKLF-000EZ0-Ns for multi6@ops.ietf.org; Tue, 09 Nov 2004 00:58:38 +0000 Received: from n97.nomadiclab.com (teldanex.hiit.fi [128.214.112.65]) by pegasus.hiit.fi (Postfix) with ESMTP id E492B220006; Tue, 9 Nov 2004 02:58:34 +0200 (EET) Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 5DBC68; Tue, 9 Nov 2004 02:58:35 +0200 (EET) In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D09585E@esebe056.ntc.nokia.com> References: <3CF661B1787ABF41A869BE20108F8D6D09585E@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7A86C881-31EA-11D9-A88A-000D9331AFB0@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: , From: Pekka Nikander Subject: Re: A lowest layer with location independent identifiers with more than one protocols Date: Mon, 8 Nov 2004 19:58:33 -0500 To: X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit >> Firstly, it was determined that there seems to be some value of >> providing >> >> "a lowest layer that supports location independent identifiers" > > Could you explain a little bit more what you mean by this? Lowest > layer > of what & what value is there? Do you mean a lowest layer 3.5? Well, it was really John Wroclawski who made the statement, but I'll try to explain how I understood it. In the good old days, i.e. before NATs, firewalls, and mobility, when you had an IP address you could hand it around and know that you can make a connection to that host without too much worries. As we know well, that was all broken by NATs, firewalls, mobility, etc. Today, we have a number of layers where you do have identifiers that still have the property that you can hand them around and get your communication done. E-mail addresses and SIP URLs are good examples. But they are application level entities, not lower in the stack. Now, if we had somewhere down the stack a layer with identifiers that you can hand around and use independent of your own current location in the network and the other node's current location, that would have some value. In more practical terms, that means that the layer would need to support mobility, multi-homing, middle box traversal including legacy NATs and future architected middle boxes, and probably some amount of security awareness to allow authorised firewall traversal. I am not saying that layer 3.5 is necessarily the right place for this. There are many reasons why layer 4.5 or even 5 _might_ be more appropriate. On the other hand, having the functionality below the socket API might have some value from the point of view of better supporting legacy applications. But you could probably implement things also at layer 4.5 and still make it to support the current socket API. Indeed, I think that designing such a protocol would be quite an interesting thing. More generally, it looks that we need to redesign the stack from roughly middle of layer 3 to the socket API. Such redesign is likely to involve more than just adding a new layer 3.5 or 4.5. >> Secondly, some people expressed their discomfort with the HIP approach >> of combining identifiers and security. Ion Stoica and Scott Shenker >> put it out nicely, saying that HIP provides >> >> A. A mapping from a public key to an identifier, and >> B. A mapping from an identifier to a set of locators >> >> Based on this observation, we came to an analogy. Consider the case >> with current TCP and UDP. They are on the same layer, and provide the >> same kind of *identifier* abstraction. However, they provide >> different >> communication semantics. In a way, one could perhaps characterise >> that >> "UDP is TCP without congestion control". (I know, that is not quite >> true, but I wish you get the point.) > > I get this point, but you should at least add that different protocols > use different transport protocols because these transport protocols > provide different services. Right. That is exactly the point. Some protocols might want to have B but not A, for example, because they rely on other security measures and would not get any value from A. >> In the same way, there might be value to have more than one protocols >> at the "lowest layer that supports location independent identifiers". > > This might be useful, but you should be mindful that [the different > protocols], then, could potentially provide different services to > the protocols that run on top of them. The reasons for [selecting > to use a specific protocol], then, could be based upon the services > provided. If generalised as I suggest to interpret your words above, I fully concur. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Nov 8 20:03:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26184 for ; Mon, 8 Nov 2004 20:03:24 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRKOs-000F5m-3K for multi6-data@psg.com; Tue, 09 Nov 2004 01:02:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRKOn-000F4q-C6 for multi6@ops.ietf.org; Tue, 09 Nov 2004 01:02:18 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA9129P29905; Tue, 9 Nov 2004 03:02:09 +0200 Date: Tue, 9 Nov 2004 03:02:09 +0200 (EET) From: Pekka Savola To: Geoff Huston cc: Brian E Carpenter , Multi6 Subject: Re: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt In-Reply-To: <6.0.1.1.2.20041103171536.02126060@kahuna.telstra.net> Message-ID: References: <4176E2F5.10008@zurich.ibm.com> <6.0.1.1.2.20041103171536.02126060@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Sorry for not responding earlier; I was waiting for others' comments, and the ball got dropped. Inline.. On Wed, 3 Nov 2004, Geoff Huston wrote: > At 04:39 PM 3/11/2004, Pekka Savola wrote: >> I've two bigger concerns here. While they aren't changes which must be adopted, I think >> doing so would improve the document's readability a lot and help in clarifying its scope, so it >> might be worth the effort.. > >> 1) >> >> The document is rather long and conversational in tone. > > > Yes. There is a fair amount of ground to cover and quite frankly in > my case brevity would lead to a document that would quickly become > cryptic. I chose this style as a) its a style I'm comfortable write > in and b) I believe that it is suited to this form of architectural > discussion, where the intent is not to be prescriptive in advocating > one approach or another, but to look at the overall space and look > at the manner in which various approaches choose to operate within > this space. Understood and agreed. Better be verbose than overly brief. However, to be frank, I've had problems when reading the document. I've done it three times along the process, with different amount of concetration, and always I've thought, "so, what *were* the architectural issues?". What I want to say is that the document structure, subsection titling or some other details are probably interfering with the readability of the document. >> That's probably not a big problem, but I found it difficult to >> read, because there was not a clear structure in the document. In >> particular, section 4.3 "Multi-homing: Identity Considerations" >> (which was discussing generic issues for further subsections) >> seemed ill placed to section 4. More appropriate place for quite a >> bit of this discussion would be under section 5, possible under >> 5.3.2 in particular. > > I'm afaid that I do not agree with this. The purpose of this section > is to motivate the following 2 section (4.3 and 4.5) by looking at > the common aspects of identity in the context of multi-homed > environments without assuming a particular implementation class. > > Section 5 is a more general discussion about identities, and section > 4.3 would be out of place if moved there. Then maybe some other reorganization would be possible, or a change of focus. I'd just like to keep the sections concise, dealing with one particular issue only, so that it's easier to see the big picture without having to "combine the puzzle" in your head :-) >> I'd like to reduce the amount of generic discussion in section 4, just >> making it lay out the different approarches in sufficient detail, and >> refer to the following sections for lengthier (and more structured) >> discussion of the details. > > This section (4) looks at generic styles of approach, rather than > particular approaches, and looks at the potential advantages and > possible limitations of multi-homing within the context of each > style, and discusses them. The following section (5) is a more > focussed examination of the behaviour and properties of identifiers. As above, then maybe some generic properties of e.g. locator selection should be discussed in a separate section, appropriately titled subsections or the like. >> 2) >> >> I've griped before about this document not having enough 'truth in >> advertising', i.e., it says it describes the architectural >> approaches to multihoming in IPv6, but does not go in sufficient >> detail to e.g., traffic engineering possibilities (the mention of >> this has been sprinkled along the draft though). Still, I think >> this is a bit of misleading and we should try to avoid this. I'd >> just make it clearer that this document focuses on connection >> survivability and not the whole multihoming problem space. > > The document attempts to steer a neutral line between what some folk > see as possibilities, and others see as unrealistic. For example, > some would see host-based locator selection as a tool to push > traffic along particular network paths which in turn could provide > particular traffic engineering outcomes. while others would say that > traffic engineering as an outcome of host-based locator selection is > a case of fanciful thinking, as there is clearly insufficient > network-based path state information provided to hosts to allow them > to make an informed decision about a locator selection that would > yield particular path characteristics and network load profiles. Yes, some of these issues could be pushed through hosts and locator selection to the hosts, maybe using some tools by the network management. But if it's visioned this could be a significant part of the current solution set, then it should by all rights be expanded in the document to consider the different problems etc. >> mostly editorial >> ---------------- >> >> In addition, [2] documents further considerations for IPv6 >> multi-homing. Again, the reader is referred to this document for the >> detailed enumeration of these considerations. The general topic >> areas considered in this study include: >> o interaction with routing systems, >> o aspects of a split between end-point-identifier and forwarding >> locator, >> o changes to packets on the wire, and >> o the interaction between names, endpoints and the DNS. >> >> ==> does this call for minor edits to update to the latest think-about-... >> organization? > > I do not believe so - what did you have in mind? The document was just reorganized, while the topics are still the same, they should probably be classified here the same way as in the think-about. >> The possible application of the MIPv6 protocol to the multihoming >> problem would be to use BU messages to convey information about >> alternative addresses to be used after the outage. >> >> ==> clarify: s/convey/convey prior to the outage/ ? > > An alternative wording is: > > The possible application of the MIPv6 protocol to the multihoming > problem would be to use BU messages to convey information in > advance about alternative addresses that could be used following > an outage in the path associated with the currently used address. OK -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Nov 8 20:38:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29389 for ; Mon, 8 Nov 2004 20:38:40 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRKxF-000IIn-Mr for multi6-data@psg.com; Tue, 09 Nov 2004 01:37:53 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRKxE-000IIT-5p for multi6@ops.ietf.org; Tue, 09 Nov 2004 01:37:52 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA91bmrQ174050 for ; Tue, 9 Nov 2004 01:37:48 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA91bmPt092594 for ; Tue, 9 Nov 2004 01:37:48 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA91bl7a003606 for ; Tue, 9 Nov 2004 01:37:48 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA91bl0O003603; Tue, 9 Nov 2004 01:37:47 GMT Received: from zurich.ibm.com (sig-9-145-255-241.de.ibm.com [9.145.255.241]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id CAA49720; Tue, 9 Nov 2004 02:37:45 +0100 Message-ID: <41901F67.9050003@zurich.ibm.com> Date: Tue, 09 Nov 2004 02:37:43 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Nikander CC: john.loughney@nokia.com, multi6@ops.ietf.org, hipsec-rg@honor.trusecure.com Subject: Re: A lowest layer with location independent identifiers with more than one protocols References: <3CF661B1787ABF41A869BE20108F8D6D09585E@esebe056.ntc.nokia.com> <7A86C881-31EA-11D9-A88A-000D9331AFB0@nomadiclab.com> In-Reply-To: <7A86C881-31EA-11D9-A88A-000D9331AFB0@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Indeed, I think that designing such a > protocol would be quite an interesting thing. More generally, it > looks that we need to redesign the stack from roughly middle of > layer 3 to the socket API. Such redesign is likely to involve > more than just adding a new layer 3.5 or 4.5. Interesting indeed, but way out of scope for multi6. Brian Pekka Nikander wrote: >>> Firstly, it was determined that there seems to be some value of >>> providing >>> >>> "a lowest layer that supports location independent identifiers" >> >> >> Could you explain a little bit more what you mean by this? Lowest layer >> of what & what value is there? Do you mean a lowest layer 3.5? > > > Well, it was really John Wroclawski who made the statement, but > I'll try to explain how I understood it. > > In the good old days, i.e. before NATs, firewalls, and mobility, > when you had an IP address you could hand it around and know that > you can make a connection to that host without too much worries. > As we know well, that was all broken by NATs, firewalls, mobility, > etc. > > Today, we have a number of layers where you do have identifiers > that still have the property that you can hand them around and get > your communication done. E-mail addresses and SIP URLs are good > examples. But they are application level entities, not lower in > the stack. > > Now, if we had somewhere down the stack a layer with identifiers > that you can hand around and use independent of your own current > location in the network and the other node's current location, > that would have some value. In more practical terms, that means > that the layer would need to support mobility, multi-homing, middle > box traversal including legacy NATs and future architected middle > boxes, and probably some amount of security awareness to allow > authorised firewall traversal. > > I am not saying that layer 3.5 is necessarily the right place > for this. There are many reasons why layer 4.5 or even 5 _might_ > be more appropriate. On the other hand, having the functionality > below the socket API might have some value from the point of view > of better supporting legacy applications. But you could probably > implement things also at layer 4.5 and still make it to support > the current socket API. Indeed, I think that designing such a > protocol would be quite an interesting thing. More generally, it > looks that we need to redesign the stack from roughly middle of > layer 3 to the socket API. Such redesign is likely to involve > more than just adding a new layer 3.5 or 4.5. > >>> Secondly, some people expressed their discomfort with the HIP approach >>> of combining identifiers and security. Ion Stoica and Scott Shenker >>> put it out nicely, saying that HIP provides >>> >>> A. A mapping from a public key to an identifier, and >>> B. A mapping from an identifier to a set of locators >>> >>> Based on this observation, we came to an analogy. Consider the case >>> with current TCP and UDP. They are on the same layer, and provide the >>> same kind of *identifier* abstraction. However, they provide different >>> communication semantics. In a way, one could perhaps characterise that >>> "UDP is TCP without congestion control". (I know, that is not quite >>> true, but I wish you get the point.) >> >> >> I get this point, but you should at least add that different protocols >> use different transport protocols because these transport protocols >> provide different services. > > > Right. That is exactly the point. Some protocols might want to > have B but not A, for example, because they rely on other security > measures and would not get any value from A. > >>> In the same way, there might be value to have more than one protocols >>> at the "lowest layer that supports location independent identifiers". >> >> >> This might be useful, but you should be mindful that [the different >> protocols], then, could potentially provide different services to >> the protocols that run on top of them. The reasons for [selecting >> to use a specific protocol], then, could be based upon the services >> provided. > > > If generalised as I suggest to interpret your words above, I fully > concur. > > --Pekka Nikander > > From owner-multi6@ops.ietf.org Tue Nov 9 08:36:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25324 for ; Tue, 9 Nov 2004 08:36:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRW9m-000DWu-3U for multi6-data@psg.com; Tue, 09 Nov 2004 13:35:34 +0000 Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRW9k-000DWX-O8 for multi6@ops.ietf.org; Tue, 09 Nov 2004 13:35:33 +0000 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA9DZU220288 for ; Tue, 9 Nov 2004 14:35:30 +0100 (MET) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Nov 2004 14:35:29 +0100 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D458216@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'multi6@ops.ietf.org'" Subject: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Tue, 9 Nov 2004 14:35:21 +0100 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk I don't think this is ready for the IESG as yet. If the wg is going forward with this document the language in it needs to be cleaned up considerably IMHO. I guess part of the problem is that it looks like an aide-memoire for those already skilled in the art - as an introduction for somebody who is new to the problem it probably assumes too large a knowledge base. Substantive: ============ Section 6: A problem with all of these schemes is that they have no inherent means for informing the multihomed site of a failed path where the failure is not in a link directly connected to the link. A major failure in the provider network or an upstream transit provider can result in outgoing traffic being blackholed even though incoming traffic is being rerouted via the alternative path. A host's transport has no way to influence the routing even if it discovers that the path is broken. Editorial: ========== Throughout: Consistency as regards hyphenation: multihomed,multihome vs multi-homed, multi-home I don't believe there is a verb 'to multihome'...s/b to be multi-homed. Several abbreviations are not expanded at first usage (ISP, RIR, AS, CIDR, etc) Abstract: s/The analysis is done in order to serve as underlaying documentation/This analysis has been carried out to provide baseline documentation/ s/who are working/which is working to provide/ s/as are described/that are described/ S1: several places: 'announcing an address block' is a sloppy description of what BGP does. para 3: s/who wish to multi-home/which wish to be multi-homed/ what is a 'netblock'? last para: the first and second disdavantages are not properly separated..the last sentence of the first disadvantage is actually the second disadvantage restated. Both disadvantages stem from the multihomed site only leasing the addresses from the primary provider. The whole paragraph would benefit from a rewrite. ISP is not expanded at first use (and could be avoided) S2: the definition of transit provider is not the normally accepted usage S4.2: 'covering supernet' probably needs more explanation S4.3: s/A site that have solved their/A site that has solved its/ There is more but time has run out... Regards, Elwyn ---------------------------------------------------------------------------- ------ Elwyn B Davies Routing and Addressing Strategy Prime & IPv6 Core Team Leader CTO Office, Portfolio Integration Solutions Ready Nortel Networks plc Email: elwynd@nortelnetworks.com Harlow Laboratories ESN 6-742-5498 London Road, Harlow, Direct Line +44-1279-405498 Essex, CM17 9NA, UK Fax +44-1279-402047 Registered Office: Maidenhead Office Park, Westacott Way, Company No. 3937799 Maidenhead, Berkshire, SSL6 3QH ---------------------------------------------------------------------------- This message may contain information proprietary to Nortel Networks plc so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited. ---------------------------------------------------------------------------- "The Folly is mostly mine" and the opinions are mine and not those of my employer. ============================================================================ ====== From owner-multi6@ops.ietf.org Tue Nov 9 12:22:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21913 for ; Tue, 9 Nov 2004 12:22:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRZfm-000EIq-UE for multi6-data@psg.com; Tue, 09 Nov 2004 17:20:50 +0000 Received: from [200.180.242.22] (helo=PENTIUM4.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CRZfX-000EEX-Ht for multi6@ops.ietf.org; Tue, 09 Nov 2004 17:20:47 +0000 Date: Tue, 09 Nov 2004 15:20:19 -0300 To: "Multi" From: "Smd" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------qpwjudxknumaqgianpwd" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Level: *** X-Spam-Status: No, hits=3.5 required=5.0 tests=AWL,BAYES_60, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk ----------qpwjudxknumaqgianpwd Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------qpwjudxknumaqgianpwd Content-Type: image/jpeg; name="gxxlafhune.jpeg" Content-Disposition: attachment; filename="gxxlafhune.jpeg" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwh MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAAR CAAQAHQDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAA AgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl 5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREA AgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYk NOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk 5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iiigCtqFw9ppt1cxhS8ULyKG6EgE81Q 0rWH1VohF5WEhR7kjs7LkKoz9eT9PXF/ULd7vTbq2jKh5YXjUt0BII5qhYaRJYS2EkRiUpbC C5UZw+BkMOOu7PXHBrkq+19tHl+Hr9/9X8jGfPzq2xdj1OzllkjSbc0YYn5Tggddpxhsd8Zx To9QtZmt1jl3G5jMkWFPzKMc9OOo61k6fog0yZJZnj8m2EjLK80hO1uTlSdq4HXrnGeKh8NW sgvbuZmD20OYLRwSQYyxY49RyoyPT2rOFevzRjOKTf4bf8FetiVUqXSkt/6/zOlrGu9TnTV3 tEnggiRI/nlgeTLsWwCQwC9B171qNE5uVlFxKqKMGIBdrdeTxn8j2qjqtjc6lE9pviW1kKEs Mh12sCcdjnHtj3rfEc7h7m6/H7npr1LqczXuiXWqPDr1hp8aKUn8zzHPUFV3AD36fnVS1125 muvKNuruySsbdMCSHYcAPzg7uMcDr361LPos765ZXsd45ihkkd1fbkbhjC4Xkdjk5x0Oahg0 C4R4ke62xwLOqSo3zyeaerDGBj8cnB4rlk8S5u17X8tvd/8Atv8Ah7WyfteZ+v8Al/wRkPiG 5e2uZFgjuWitlnKwceWxJHltkn5hgk9Oh4FaOk6i9810jNFKsDhVuIfuSZUE4GTgjODzWcPD lxLayxS3KxH7GlmnlEkMFOd7AgcnpjsCeea0tOsZre5vLqdlElyykxRsWRNq7eCQOT349KKH 1nnjz3t/w/8AwP00uFP2vMub+t/+AaNFFFekdQUUUUAf/9l//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9/ICsgK/9//3+0YyAr2m//f/9/aUMgK/9//3//f/9//3//f7Nf ICuxWyArs1//f/9//3//f/9//38gKyArICv/f/9//3//f/9//3//f/9/ICtpQ/9/ICsgKyAr ICsgKyAr/38gKyAr/3//fyArICv/fyArICv/f/9/ICsgK/9/ICsgK/9//38gKyAr/3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fyArICv8d/9/ICtpQ/9//3//fyAr ICsgKyArICsgK/9//39pQyAr/nsgK2lD/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//fyArICv/f7Fb2m//fyArICv/f/9/aUMgK/9//38gKyAr/39pQyAr/3//fyArICv/f2lD ICv/f/9/ICsgK/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr aUO0YyArtmf/f/9//39pQyAr/3//fyArjUv/f/x3ICuxW/9/sVsgK9tz/3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//38gK2lD/3/bc7Fb/38gKyAr/3//f7ZnICvbc9pvICu2Z/9/ tmcgK9tz2m8gK7Zn/3+2ZyAr23PabyArtmf/f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9/ICsgK2lDICsgK/57/3//f/9/tGMgK9hv2m8gK9dr/3+2ZyAr2G//f9hv ICu2Z/9//3//f/9//3//f/9//3//f/9//3//f7FbICv9e9hvICu0Y/9//3+NS/x3ICsgK/9/ /3//f41LICsgKyAr/nv/f/9/jUsgKyArICv+e/9//3+NSyArICsgK/57/3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//fyArICvabyArj1P/f/9//3//f/9/s18gKyAr tmf/f/9/jUsgK/57/3/+eyArjUv/f/9//3//f/9//3//f/9//3//f/9//3+xWyAraUMgK7Fb /3//f/9/2m+0YyArICv/f/9/s18gK/x3/HcgK7Rj/3+zXyAr/Hf8dyArtGP/f7NfICv8d/x3 ICu0Y/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr/3+2ZyAr 2G//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/12sgK9pv/3//f/9//3//f/9/jUsgKyAr/3//fyArICv/f/9/ICsgK/9/ICsgK/9/ /38gKyAr/38gKyAr/3//fyArICv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/ICsgK/9//3+xWyAr23P/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f9tzICuzX/9//3//f/9//3//f9hvICsgK/9//3+xWyAr /Hf8dyArsVv/f7FbICv8d/x3ICuxW/9/sVsgK/x3/HcgK7Fb/3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fyArICv/f/9//3+NS2lD/Xv/f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3/+eyArICsgKyArICv/f/9/ /3//f2lDICv/f/9//XuzXyArICuzX/57/3/9e7NfICsgK7Nf/nv/f/17s18gKyArs1/+e/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fw== ----------qpwjudxknumaqgianpwd Content-Type: application/octet-stream; name="Garry.zip" Content-Disposition: attachment; filename="Garry.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAOB0aTESdu/Gm1cAADNUAAAMAAAAbW5heWNoeGMuZXhlD+jXW5ic1a/N0b2O Kse/HpSBu3WmUAcp5gUp40takjimmNFTWrNwzq105m0WqMFhnRySEhASgcIFN6p38yJ4GOe6 yOHEI47Uvh9d8JSM6GntP9boFgnOVw6EoqbSKtBYVxRKDRdRzPkQ7LMwMhMFPbXvO9cBy/22 7xpYVlM5Iiwog0HmcWeQ7EHu6vEsuF+gcDWP1Vo8PHbk7f6YezvfD+BWUojycLJpV0P6R2oJ Pv7um1sW3N/bHHuay+qFKtoSKhsx9TajZmGsZhdHvOYbzEGM+rlpLM/fM8dDCtyJ7ShIYut7 v+l+YB109Twfr46HDbQSedX5m4SD6WnEDNcL9zQJrofAGNv2GQeJCfiVRiT6Tz6ISLDFhg85 0w3W+jcvGckOJURRGKBAJ+feprGyyltv0+onkPKI1iLkzd+MNVu/6ID8Dl3J/8UumuhEuDBd r5TKN60NfgUcIbDFkAfegf9KI6PLhM9wHtUpJwEosmKAROIrhLcL5daz2MuTBMO6QP8/PO4y U/Ms4FFzL176N6uV7wT1SA9gBoDflNHATMW2UxzN2zBFovi2lRKmFU83grngBwiIL9HgbrrW wVnadkP9Yuxq3VKYyCjlzzzHAmw9Q7mochEFwb+4yNEpb+t3BYtnICRX/JKMlV1L+UEawx52 TU89H8lUrThZvFYPtXTfNUX3jKntIgS06q6dTtQi3Um/cvBaUug+Hlkun5QpkMCfLEucoXN9 2iVtDcA2eoLYgDvuGT4cy2V+MbD7I/Pa/jGXmlPI2ruCfdz9RQrpsvVFZ7ZwRS36LFbkCWMg HJtdYTw156O31iu8P1GJBBJn6gtid2c9yuCIbwxtwHYpQgiV7zVVvUZtEKxSPKVZDH3PF0dy z+gRRlaLqlJHFzk6f1JpStx7gGG59SfhqETapTmh5XyFF2rj0JAtWhtmdmEwaNLmIHhnEl9D 6GijYzAT0Mjmlx0MarB9skK2BDQ7vxgoKugGZ/C0Dj2jgk5ofBCvsy/NkN77di52p5YCebwF nXxJnBH9VLhU/jAeczIOGNnKRRVmKtjEbQ5Bt7I++1NhzTCtiUAe3UeE0hD78KIrOB/bekYc n+7tD3fzl1k63O5bOI4YBSUsAHziWgMsaOxBAJw3zoP8+AKvMPTLu0BLo8lvO3kRx6cVT+vN RGfm+g8dPbvpUxkFDNi8pa4PDZXbQnDRDD9Y2M8U9xNh3Qs/ckdHLRKu5TO03QS9xJJTpA1I x0iWUWoTeB1MJqBaGwGiWAkWT4YjaaK/MAwCrWGVejuu5G7SFS8YU7MEKSQ3M1eVCGvOaKWU O5Sa/2hUaqeIBweUKGIsfj6S6uIZlqVTiAdUd8eA/ZDwuO9CpB8cbv3+Fo5/McZqarNshi2V x1wtmD74W/Dd+O1cAPiQMuHyi510SNSvZ54l4G8jRpS5qPfK4Y3ARR0JQXhbuAxyJj17/UHn +ih2nojoRNQrDsLrFxhCvrpCcXNFXyUcNTx/OGxOxo0UX0oKT3Sm8Bio4LCbGbhweeEe338D vyDVPY7nPbQm94BfbvFAnrHQWNpgOSdN20mqjNygfJDugeqFxM5rg5exms7lk4DMt8EWURjX YBAdsGNn4ErIjKfjmU09qBDDNnm+9fWrv2FHT+X2iSN75F73D7LXsAQd66UU4Q5BI2IJ6njj gaEOGSvIGUOzY1CLFxuU9275yJoetqbhbHlz9A6JejkjCzCi/NqRk1v6DzyFa/k1QcXM1/WW 7865T7ofO665Fi/LNxpyY4q0IF2lOd0RECbddWTbEpt1FaJ5AfcffIWvULYEd7U/Q5kP44ZW bw2xObHlTrPXHtXM2CLx/yEt/qEDIrUHGkN0evmOfj6OtfHYfQvMMlmKzpRQNnOBietRFKwG Xu5VQb8yQovyGIGBUYMLlEwOnKKu7EH6vlNl5KD55Tl7C4mEZ7LarIPCbqk0xT48wR6HrDoO np/j65J3zJ5IgxXM/VB3NoTciHvZSsyDwPowjYKs9o2m/Wm+KU+rxtJ+4BZrAiGCKBzLccYq zP7TRr/o34PV5zbbffUt7LGSwOySwlumXFZESdaFIRhkro05mK9oLlDUiGolvVZJmRUinIoN MW3qvPA5XggJS0cUpEZJdkYpt+ilyami+kul46J/g9zSNHoApXOi7iaBi1T9wissC4WusenV 2gDpEgbSJGoHN8tTpcCiBLS82hDW/Aw1UHu9cLVUd+uTYvFimYqsnw4ge+ip0J80neXfew/Y C/FhkzgC6R9jRC2tM3QgiA0iEy9gcbv/D5Bc8BOckOaeYuHtFuQf/LtvY/oBwxPfp3dZSnGe ZHEFdixW3U9jYhxgfNBEtwlYDFvF7kgO09nn51C4SO5I5qf/hDXlxvzgAn08qM7ufFWx5cQy FzvXIWU8CKYhbBtOBHRd8PXmi1AGCgHCIhkDLARtrK7Cs2FrOypIAzCWu0nT/QaYcqzOt66k Gfz6VaMDmj0IF4pXZS+upQiWxjsji41vdK0XXHFIKsIEHSocIS+jfbJH8RHxOOKQMaOvMm/Q OxuSt82OL33FveuYpGZwA/tRmfVR+9lIdCaEIZYW3XFAmTw9dx+9O70JIGwpTd7+hXAzOXuZ Av5Ik1KpjavWJEujpNhBMcGbRyAx71uhFSXlfeAMIhUGy3K7EYwdtnZcDOGPzq8m3pgioXu2 G8QYmrSvv6eC/JXTf3i4TZRTbSamF+RVBYLhe5xVyCydwA4jZZVjarNJer06IgDLZIEqBehN xoSGi1I2ajtMnApBTm4vDeShe/sFhTV0S+zGYLDIu7dIWgZJ+qjRD6Qid9oQfeNM7EbNBOeP BzuCWgVIxeMWnCwE7UqhfuVpaYi5vQmjvQpQDNBydoY3iiy8K4lrRoopsYkOzZzMCLEKZ0xb R1B3+1ftjgLlcAlzL+epRX5IVqfvr1VBriKx8RI0nO8HrpWYrYogw6Qi8YhGUxQtlxqJvgFc rtEQjar6fuwHddpjF7YozdTP5okCoRHA9+M/L/FIeiE3uW8P69dAy8B4PFBxxW4uu1hgItGH gWIxoBrP9joBEL1g+/XuHHyLW33RqVVY6GykIVO9THaiJ7miuaGkdKcffo2/UtN6K8/EJA0p pLfmNNkhBP96+HwNVxGE13PyZcyjj6V8yfcRMpD2x8b5nnKHKU+1yV++mHOGznlo3AsQb0N9 r5Bdn94g/h8NZG1+8Q4aL9eweUzvSs8uNs1f0UsozASX1XV+MOcZbBWs3joY6fsj3R2l1MLQ /cCADDcv0+dyaHzUxXN450v4AoAiBKXxVHdEVBydZ7eRV9H3fIf6AncZY4YDeNVI1VzqkNJA 8US7eENesMVEQYCw8PR0rbHH6yapbhZHtQum/9yOFcUrNuJbtklIwvhDleYQjpcCE+low0HV 9vuEQTX5K+xQ3TulwnHslimja8XM45jD4Ut28DQ3TQC0BIWEmpfQyXRwXTbgKmKNDb9qMA7s sLUOKiiRX1lHa+gqjUbCvmAopGu2csYT52AgNnfF2zSsmHwK9gpsHsl49TIYvR5nQSs6oNpm vui51LjMI35nkVhSnZvoxk6c6i/MCLuJGTqlhLybhv5Tia/ax93/o2huRNVwQxVk//VUB7TI hcK98hAccvCZfVJjAxG35e53yEizsn71AX74t3RqRXp1S18lQnx4eomEdk28+hZaPsansVGE F1QFCBTXrChszLjFOmC2HRkukLId36E+hngJ73Yln8/y6ozdzk02O1t6PHmk2KkxExhdqpJf oeUuIFanjHzqLFYo4yKQ3WroplnWuXzuRJAA3Jyiat4fOxxUmN7NF57l+R+6kwgE/2jR2zYu FSsHPnecy/mjh7sMUERF1OYCnnq8AfnDf8UKMCko5C/dUpKH751ryrgzQ02FHVQ2lX0NATwE 8MRJnjQSqMZDQw3EJn3SU5op9RJCM8UXEaYiZWmyFKsqvXX2eoIpGrDqZjO32YteiSEsbhJN PaAOnwR2snfafm5MPqsKJK8Y60O4gKlnxqe3BH6Vy6nShdn8q9RI3NWueSA4uUe8shsTaf0A aehqaZA2gTf+8Taul/Br9xDgrBpLF0Fg7wukiNI+oH9F8fKjwY3YEUOhp5ZZwmdDzPEWJ0ph 0/8BircKnq82LKSGFDPifLtSJjwx3qEB4p34gCMF/eMNo2NEcW+7bTdgiKcVpW5wQY1DauXm mcLwMZl7YdP8SpeFgwVE179X1yrBunJDKLx25BqSLL4YoFLHYl/voFiNWxdmenrx+LL7Sl4N Wx7NIFoPo3XNWTlhD2ctmaRv9xxmgm7FIvCHAIB/QNujMeITAuBBivi+F93kUXO2c+BcJAYb JEN4zc1IvcLr37at/V0PX8PiYSWOaZpbc/fgGVq9SfvYEPB30HuphIKPc6S5uYTqUD/tA8Bs Gaa9eh004vzMWm7CxMPhvzaXoCyzt+eZ6EwjAES14zys06Drd274k2CtUIqlxgK3mHTEMDPJ iTQdo9ZOK9wX0JxlUXmWN19YesFRpjneg/53JZ5sPcdOk9IJbtRJAO2U7DLfZp+3kdVRBPWO F6rVzlWxH1J03K1Wzqs/Uaua5K0AuReYE0aJq42bx9C4QM+bBMjwm1A8dK2v6+W7T5sflwM6 py6AhZkLmHReJPtGqpHOVin420A8XNlt5nKq4CLVGRspN/G94tWmIt+1KvTAJs7GnUnKrEV+ Kw3gNs/edfewJKph4LVSy0lvUiNzCES5vuvtoE/eaFNB/CdsSQz54m/IS7bgP6qfp62LMiV9 p4PkG/CUepwKwiz31koG/wsyXkCgcUqPDuMnO1jF0fJ0RwoXW5yc7wXcs7fFnSgPMrYs002o 5kKyNrYZexE2o5kHjBgr4ZLj11AoL+Lv852J3MDsWwFKUnowocJIOEDn/lG7mU87wpuQKiff sFDxTema1rwKZO1XXetDK49L/+C1+SF7FDKXQPhhmcnhrzZGDjXasIhOVYEaplkzpV0+E8p/ agvkmrjLtiS4GSPWNgR1vJ202e7xdeRWhvhfB6GvZPzE0vHFRqDTAGmmWfYq0HqCVx7QKwYv pGzsUEu6D3YTSFcLyOFSs8SbGX3T6yArMWzym5ZYNXZv5pZi17kO4SCt6PZ0bEM4cVe4LYDp kqmJayd9GR8hh6SSRqtySHn7027HyHc85Lcr+uaprG0o434yk9lpjkp6zk9zurCgia823UPP MZVRTyXUvN4QCxUHlk52I90OPz36l8i7gm7ymi0i+a0CWzTrOCIr4zaTJc+vJhJjGZODIz/S 9ReE28/F0Ca4RW05zASPjuExPDo0wMO+mo+yrrvOMV9o2WOGjiRP0TaiHTvtjbi3R+iDWfO1 RCYAi2xkbsitBvQ0bqThMyyAUGPMjTtZ6h3SOqCN6o5TFESP58BMsN4e/4PUrs24kfUVNGt9 B3GGMn7b7JJ1w0Lzt3Mw4d7Pxp0whDAdZmdy3WAMrsxjimovI7tACxjLNV7oZ2TANH2JFuhi /SE2NVMBWIGndoK1icZYNndwF/HHig/IM76Xe6Mh6/d8YVfCdsRIdNz1oy5vIUv/w2ZkwojZ roOOvoLljJi5dB+wBdrmWJ5+yiwkQaUB5Pw3sj4xrD1r/GoNM25eRUhsw636pBLujjR14hYW 0PjuX7KfV7+XJtoR+vXf9yhkfwtSBriwRr4DvsMhRlJUs1XM9kzyFiUlrZ7vxJyBf7JWmpOz LsH1fQ9di8+O3ptkJwQQG9NdAmnD0qdeYRefRjMmUEWjk7NlqPnmQZjXT9+6uuuTx8rJRlNS WwdHZmWx/Y4ecsYMShke6kLT1cxSs4mcH+PcPRJsn/rjrURWoRBVemi40Ds2dibfbIuiwAYc z7jFcDssZhzGqGMztaWpYDKBmddPnczUyKZknOvFErqOygdz3VnraCWpg1++1fk2KrkLF7Gy uwSBEQLShKJ/bKTiuat12611nPvAbm9tIdJ5xKyzJAzosIgluora0doHV2dE4cmkLAe4qwcL QpXSyns8aZepvqw5yt20VOMv32so7UcwbcKotVmwNjQ3iQxs+Dh5LJxBmVB5Jc/BYIOTC/TJ U67EB65RAlYjSjX97rNnNPcg9L4GtmTF1L8jZsfdnbPdECluHPUhwUtcqqV7mv2cy/0x94Lt 2yrdFhz+SYhAg3S/b74A6c7QXspRtzUaja/OFs2pQgJ1969V88rtWCkuk3iyHsfiCG1xtDRI ZstMsp/Ha4qO9ueoWZR01qIZWsR2/cJFIaNXh4ITrFXGfDl/0sgr5Waot46C46VAYiXtD2p0 v+vmN0v235UGuAC611NvXUS8zrNdlmDAB2Ui6WM0gabEYuEMO0B87c5oZ/s9Y6DG0J9uUrf5 FWhBcFteVVRPfPCSHNdFzZO5WYybBC3rSuC78XzcU5xf+jD43kjlOX9iWxuWMp6eYHEkCM4W sx4n758Gv3R3Q0XFhCvgU3Imtnu2K8R82v3giAggD4+kdDQTwruSBZdrLG/wj6st84AIPKo2 qXREqm8yqmy9jIELDH3GZupimcc9BkpKgN7vLwslNN8pgcKZwqEMORqbI3tMmg6cNeMXUZtu DE6NsRMN4XuM6dVDcmobBkRqjQnWAQANfNB7gjn0EasdlladO7gqN0JL69LXiYs/XJQDoRxq FP0ADKo+Wqagbn1Comw6hFmKxOY+mW6JDyXTg0XifF87fIwln2coDW1CnosXuNKEt+tMX7yb 1phEl14/+GrUdXh9Jas/rJkPRp3Rqv4HKIR5ATP63xs8jDg6Fspv6teZzfMSYvsAgFkitU4U gfFkUfMkIj7Ig45xz0Em5bIsx2nv1GYMD92+WxKNBMJf3qpiI+7U9ny/+Pw2Wv8gQ+srPGHt JVQyOqspROEnp98Dsg+HQGsuGRBD/b2px3SYoPnMNAXFMH94KsD+fBmSlKKMNTFzKTcTS/dR M4qQarsWR2KZSt5yqxW7T4PM0DBcXMUWoQCWgnhQW83GXix7rIm7B5GsQbk4QBGt2mt3NweO PE3DRL/qjkWaFfrbJJv+P18ZX0C40L4+p5oScc0Q4QwubhdVHw0scKLTaaGvTWABn6hC5p/4 ywhU6HcmkTKUV2wmmddbWo8MiefamM35Jhb8aNvN8vYcoIMa0qbp+CGGpsWyNGTQF5MDbYr3 +jZ26pHpptje9H1xkQdsuFMeRGyDF9jieolU4nSFPl3IRTlEx6OZbIifnTV+MN1gnmgvGbY2 4gkXMjeW4EDfzW91hQi+7VSSgyEvRH7VLSh/IONAnWQDOi1mYfdAvsLoEYUV41tseeFEtG6U BTq1wWNGSNfyYOg9kgQM9RX38KHUeTy5SbQZ3nYt9OH9L/vQcVJcdYFBte+bX3olKWNqqxo/ mAO3fj3OJ4fBOk+4nNwAlo3ujCXQfJCJ7CpVoEY6z/glVGd3whGqCM+WxgDUc1VP0pnaRnws 0qj2SEK/DBo7bBZorY/0uf/RRcVqCwmRAwZH8viZJF0fzj9XbynN8kdX929wON3G03babZZ6 qTimyAy1sYnaJDGXWnLd6xEXHCn+dc2xUGUkV6gUnUbK6Q10JzjN5fng1KQj6YsgSOHMVdUp nf6dRNi2wzPy34w4FLrdAdtkAYkvWHPBkAb4MKEeP98xP6S9SprDe2adrXvfe+91Yffm+Frj ZQuZA16OznQZ7SHyw34Y2J591Uv/JTvNqJnrq+16mEs7s08+DaizaccX6ld1vLQhx3O85QAc 4JPbgKAD4nyCy0qmtKDfUAFMY8YpHuSTleNi359xHrl344o7C8tRbCEdhcX+3kKE8Vqanrof vlZuUUH4MyMazlryWCUTbRljIKu8rfroGyms7e2AulneS/HVpA7eYTRvLRbEX5U/mEo2vVKf HEDXZ2LPMQpnk9EcRjw3dOfzCVwmrl2re9MGH18X4wt+WNBPTDvAgY8Pf3Gtu0na5ZmimCwm 7OYHTdqW/gouBRqaJqZdX3x8h8Vsz8SO/iBPxqelRBI5zma1x3SdY7NbzoppvRxU5EPe5TzB eN+jAs4gJeeoxyFl/Y351TZiyxR7c0My8yw8fd/N17H9bli7s4y7tvcRkbGZglbWV63ERhs/ LsyNpeYsp0IxQYiTFSlmpkpABlpp96w5oyo/SWbmhrhqjNjRXw14/4Ugr53DynNQlIj2GHtB staTHxn8askO0dl6wKD9KAMukKeiI9qjPFPMca3aODFBdZ0AhvYJGfsCc6yKuLyxpyH44gVR 1I/gPKdG+RL83NqwEeb135Kw253agb+frv5tSMJvz2xDfhZAibVgryBWTIUNzi0hiu2SSuvJ wK2UATl28iGtdeQRCax5liiioZ5xgPJ+mNywqYiL1n6tJ7zBnb3OfdVPvLeQE8+wci0p3yJn puyYz/ELTaPECYklWhz05LRcLAJnnWSteOGHRQbj04GhWJWzewXS21sJe4J0sLatWT3eGp2B RHgk8V9BREFwaTRfxJt03wCIsowR/9rJE/RK5o6k3RR8th0EH42YoA/2jGC9yaYifuP69INl Ayn5ivTtl2XYZ8ykgchrN8rVcVxwC2+C1Uvxag61vgcjHA5JJhX47fuQHlLFrw4EebN5HUOW Cx4yon0hvuaPhQNT0AAbZIP0SRnj8rvNC0UcJnUyw63b6Lg2cQE3BHT+BAtMmJaid0UfFvRc 0X9Pr37BbLb4Lz+5cmfihciwvswMsuiJvdUBHCaCcshS+FbY0nX6+Yz+RHNNLn/5DiCYBpQe k4Q+XL5bgvkvfWCyww3hJQk/fjqYmS/B0Ppk3a2ODPlJQ/UctTKMEY740ok4sFIZ0JH8GHRB Jc0MMka3RNmCXYyIIiy7Tn4I7W0IqFEiAamP6lGpzSFhEqB2dgQ5wsitB492sx+Dneg/JDAi l3jdnSZB5R7Z998Sqb2u4hLzezVmJNJ9LE5tz83ijn2plFrbvhajgLKFFDf55yNfIdCvkf7n A3i4k0ZsvSnHp9cNytAYCfie7S5PdoHdgUwmd3nsKvjbyvVE/1TXao/kB89rFGqgi0sxSYgy 87dCEKhEcPwPH6IywY3iqY3tJscFC+k2xGQRY0+iylv3ZahJ8Rxys7QmDAObAwOPbiXvXuUO elgGTk7RJIPqK8Gn+rRRBvg+DxURcnJ7UNj1KHOxnczSsF/YfK6uawZ0UI1wpjdhqV0KApQJ 7pkZ8v2BRGPlNA9WBLy84+gbmUBdGkOKtIaqXRoZY1X5Bx2hN7FzUqUbfx62l2i7uWziWa+a gPDkJgx1XKn7E/gYyGp08L55vGg9AADV6i9mIQBgXHGkVRkuLObVwzv7C7m8DpV9tupq2egw fmLnXBgzgTgafW2JqAFj5kNAPGy3XaUPbhC/eUoldT9JHukVBOLTbQ6qSv0+edLiK1n5TV5j 0Iw2rA3iPEITvRtLHGKoGgEk5EAk1qPV+mBofksNJKYdw4f+8OtRfz33elh0dfl24hIMtply 4dO273pwpGXwqsdEdmp5YzYjMcoZWf9YTN8dLpmx13QPxXgPB+R+D8WoWA5FUTIz5NrvZ0S8 uJLFq3ksG0AkCd9Dc2uV82pNnfuNRT7AvRrtYbf6I3cBM5ZgntAXX604GO3BX/+CL1secDbY 9EAR40OCd4gbm7SN9YR8J3atP2UOlbWphZ0+vxvWNqWv/HsetbaGyh8PpGqH3uYEHFwvtRvF wlDYt8Cktq7hKnKNy9aGCBtuwRo/85A1CIunFuc2ib9dDLAdNCaJAY0x2I2vRxqcysV/+IOi 8dpqgmFGpBWP6MHdAGhM4MJb8M41vi3iNQAgwOjUfirxgEG8L0Ucp4Ly4plAmaZgsmHXZTzF n2OnS+vfpUkWYMzTr2lhMgdK1LygxJNGiQFqYHWZ6vHzsrlr6TgzVL05Ifn0QMUuvwmkpfW9 pALKG+yZ15wBcmDYpvcduX1zadmEFK+rEi22Drf1uIp1w0YaExcApkryWxb0cikDMyl5hj5r tJJT26qqqykJ2m4vDlJSbjhwbIY0Eqv0K2sC9y+jNMLwfCO2DEGxwVVIv0Elq8kWzYwbHDe5 CO/HemdMv+a13eVY0aZ0bFlWKb0vbcNmgVnqDfrr/UxygLzLHmlXXL+xro7pRHj/k7JHXYML PJfGxH+cyIdhZKFamwP+KZz43TeFj+IJgVJHKCjTww0N1/MgMY5IMp+IkiXNhobNCXCbrKm4 D2KEGAobRdvXBaN6tDcs+dqvfk9FZCE+41xuvPV73QUib+rrPxSYlujklUKbKVRac0qDnUMp C6YjyFQrWaG3b675Wpt6S2rYsM9TqJGwr+fV8UVXuXNf3UXZ2ucxdjwZpXtbMiTLgM+hA+Bl Gf3gyyJmbQR0ojnbUu3cvW+8fQapF/UAfP/AViys2AsHdMhNVRWRR9D+Llzh71E+K2o75tEL 4Oo3mXQBWQ/Jh4Xq4+DwVEf/u1/ueIe+WWxu6SKlVyB1nvF9aTMeQHftFVDfpemIouPJXOnB 8UPqS5PYNXCh2XDOuzN7QvH6UrV8NV/sDdiaeUEnmEEYQZ9D9rWO6fcIgTn2jQ9hmSNojY/A 7E3AtkNXTSnb05r2F8XEvA+ok8qsRbDUmp2y8eCuXuGbB3mpR1qmjECUvb4V6IMLvlGjcOUp MAmXp2WbJk/XMBSAu+dQfXFocykk+EZlOiYNjzulGSHcZAwmZYAhZXt/pFK514B/CkXTWEb5 gX6YH7SvA6h10f2DnWbWGpRKU1/knVPnASHw+69Nv9TA0d19goQis7WrTTspp5eWf459Wb3z wgPRzBea6bZGJez7ZIfdhiEY6MRrWfgJC9AfkmEpZHvSit5eblVSJJO9IT/3K5g4B2wnD1GP E1+RU8JnOjWQhTfgFQBWJUm5uTonoWcaaSqjuVnjZi02YfdSP9PP0y1ZCpNwuA8WKe4axCwQ X3ggH3fREpaTuKaXW3hCEXJiGesUpdzX11D9LIBBJCjI/T2w2KkHvBbAvW5dAoS1WAfj/NgE wZNMhsl1uoP3a80sXqAgHuTYB63NEZ4SEeZYDDvCXi71efCVIkttwt6tFRLt7WVTEAzG6AvU iE/cuC4eZuzcJEKCFbA2g7Z5g9gWUXwja8pE9FGzprLJ5fbeXIMpWRPWrTPOnS9cQxkscFv4 nxpTDg486PwHneqxXrIgFFgq/5KZTd8pImu1MWbOhQT/vPIvrUROSXQOQCKOzYGl6PB0b8RF kUCB2CHCrQ87qupdNV9PThJ81jzHNFWEYe6IpLYyJc1e5TvZddVsKZH2GTg0Hc1EKbKuk/p2 NK/saixgqxZkBAQi7Jguj6C5OUbBs3hcMlSL6LHnK9fCJoXjyNN3Upt0CztEq01/Zogrrs4+ /F30dDmuUVW11gEAzIxtLA8yItmLMxvrHHbA8Bo4XqwsW6qz9lJ6Bh206UfCM3locBJdz4P4 2dKpPnnAbO12dn94Zx3FQgB/B+5/E0HVNeDsFqihxjsaLNIfBJLN/yX74ODhGn2Xnpz8rfmm lz3SleLr8kqiTTOwXM5PYWQR4cJpE8DWKzGJilPZBp3vDQo20h4Z3ueXrgBUtxOHRJha/qkY /gZtE+iOoDQM797Ee5HW5ep3p6XvKjvzN3Abpz/UmMwt0DKg2eBM76vX5p8fheyqJJT9tqgc DvLkhhDmJVnLtJdENPOY0fv3koapME5OYaGZu/ryPM6HjbYPihp0G1HLSCDpt1x5ZxM0xhzR tgitIrk8r46uG+qfwES1GnK5qhL3Cm5psIjqtv2s9LVWz6BS7rKtGWS4BZ4gO1qrYoi2WFxi mpKJHGeZb/rDcBIFDuQKr7VX6sAuSBsBm0vaijAHb4pLKO6lNvY8Nm49vivveIoX3Oa0hS2j B+H8qiiygqMlxd2H9LgLYdEknRWPO3LbVfrCTgedL/pPPm2oig95c5FyFwAxADGcMfzrUvPo 7ehQaki26JbUOCJAVtMjBADL9mwCarCeICK0deTJVYfPAx7adxYDoO57rth26vhQte93IHlW VOa0ole7ZRxy9N/shR0wvyMS+SZhe3yD/Dlk8jT67Hui/STYMR8uQyM8mRiwHllwwW1D/s5A x2JACwX8hBSwNoRFcoi9V6QzgOysCbSsO2uqcoyg9zYKJAiyfSQvqaf7TdrA/T16c6ZdFVP8 Bubkj1InIDaVnHnphMIQ0sKlNqZjrZnrDwftV4croIGgjY/jajZyvG251o/tQxuGihwdLnS8 oEo5zb3TIWlNW0ejcKhNOS2Ugkq0G7D4cwo5EOJvJtYiyZHVtgsznU5+6xFHKnchYTdU/XqZ m1CUGZyaMiY8zVJe9TLgvxdTIfiGgk2M4ze3Ztr953ge6dGMGiOTIiJblO40rtdoWb3WwBml C6VTBmpl78P+DnYUkwsGdfyzINUdtBFrFeqzgb+ktHrVKq1yYZCPBiX7EfI+8kjL06lgMu+/ w7Ar2IL530T/YpsE7GdN/++yfh9w71Y1aD7T+kYPeYFZGjllTZYofz4SogIQqOY+6jkY/gpY tvYyEvRCBHBVcYw/y5dB+RuB/Davar74GVb7O5cU4509DnqUnwVxbJVkLWd28ityGzUwpwOM Tmatxs+F9z/BexYkl2VBLXyvyNgufl+h2uQNasvBNoC7zBcnXfQffieeuv8sMesSgmEIy2Ho S5aOT8QGYXz1xW6ctcxRqFuV/5X2SrJp4w8rGy8RHM+he8rKq2zkxqyLZDQeiyKsK3DELCZy yxURZG3G6RbfHkjW6OIPa6t6STMQaqwUBzaolzzrFbu13/E0bAFbyfPJGXK5LTfVHqoQCuKw rXlOF8FaeE3GhLbU5Hij+OcvjJBm2w9SUIlK8Otd7hlLp3lBgNcOTorRk1PZEHVnUqRtIRwj 9VoVR4zI3s4LkWRIneH4qXGO6PO7ldlEDHuM3qXIGNIx98WJJ4r2BogbBhjZDqhE3P2fRRbw y/tRfPlsqF9dRDZGdbycqk0Kh0ffggSL4NpA5oQi8ckTYi48127gfN7EXU9823yRRXnUWIus T89Mg8tLRUo33pYSrBkOixzQz5uiLKpM4X+BKV07Ga+SkqGLPtE6BdKNnPpwF3Wl4bTKpV8H TIGVr5AIkNJS3IrgziS+28njnpWqR+ZL/ANddWEEs01wmHLJZNdgOGKZBpnYXVByTDlwzm65 CaYEJDsKEstmXtUICbHHCIutpQJgxS8dJc5ya669zqEN9tWQFwwgeWJCeTeMr3HRHYtHpBfQ ZDwI1WY2eVdsLwrJMD9WkSVigcNIsyJDY4vEGl7dQfG4DwRAAfojZAu9TUxc2es9mMRRf3vU 0kgt3xngPCpbI5d49MyTVhf244ey4ugebRYnyFosPNx7gJeQbGbt2BBt5PbWm9qxwabZDg1Q Nc9dOWCqYwl0HHiaZUHs/naRYHnA1Pk1m8QLEGFQP9Bgg8pq93soRE9Faz9mp7RehVDJLtqS 84K0ka7JrrJtPu527CjV1VPChJlIJjOe7guts//mUswrL+Q7Q0LnkXF2ntNFrgta0jXu93i0 KT+hNuf8FggjQQzZ9rrr42QeIvBqgf4mXKq8F/JVrnOOZlSr30lPP6t9saXrjzihjK9FD7DA N32MCOB+5e6OKeSdFV7Td5pgJlwvNRBpHsKcVFlF10v0mWcOqtlS2D2bS/ag0XloxpeuJMI6 9qZ9xXrMmy+dlKXmp5C2h/i4u0e/qSiWtPoqeAnacR9CIyHUVnq/zMx6uwJ80Xay026l4AiG LyUbitZY19tw35TomdaEWj94S2KQQkBZpn50XO+K/ioPSb9M8yIRrY8/iOqqqc1OfzigWy2X pY6UAje5NC7uOavptuMNMNqlk1ID36hjOSXnnVc78v8RKArFYpFALxEWuSKYwB+puAeH+osf /SuaalmDltIbuIyY+9jeYYPefhmvhLTmyrBfX1REJZDnvY6hRn2S3JKhjcZM1JNiMK7xT+Id uj3uUZ8qpnMBIkGqg52JuOCJxDg1PIkuiO8vNrEJiNK9WCIBPGL2jcyHP53rUp9NKAy4tu0i twUlP9AA1n9o1YsGhRXV/YVmeSEwX8ZTsr64cU2c9sZXfs+KwwWM+gHesLPQVxn9Rw72xs/2 niG7LnLuW4CaHNjYLOhTs0RoyACKSwEkT4Ba83nb0BqNxUkS4s+/lmtJAgxFQtT9+zoyLkVr QvvKAzxqrV9DAPTgoevtaOtBk8TImT3MLh7y5dVMblpOHiDJn83GCHHaHodQ34bdQQ66OFU8 Kd5w8gJE0Fkhy7sl/b/IcAn/X5VZea+K3NpFm2pxaYKqsHmfFWZhzgZyO0cuVLl0e3xl7J/2 EjMmH7P+uYrJyG/gXjs048svuj3dYyHBxHcW7i7Uqrz8qdvxBlXOSTSx8een/BEy44yFLkwc beQ0Mq5LF2LW2xkTEX/LF1Wo3xRBFlw57vM/dXfYf83hFQezuLw8TqjkNyP0I+u1GOamPUFS uTDKh4rHz4+H6Itxmu0YXFmru67SK1iaQ5wdV2OsdbMRXkBlT4CJ09FrZ9UURO7hXdRTOHI/ bjkby75rKONgf6f67fOkAu7tWpK4g09zCSFgZhI3Poyn/zscejcZisMzyMO17aNex2rPcdq8 fJZN35gOZzoeQMzh6BU7sQHZHSQKXuyTmjO+AjmQIk2FJwGovPyNoxIYXB+FEkvkdcUAxLAx Ypbfas2qR2/xAzWwFQzedzZLjQjkj/HkS+NuUP8MIFSNLWqPQcFUT0dqcQXKn8gj7zX0GrJx /CGvoGkdM0c3x7/mRRfrX049LkWvrTWUriuFD1tJaPZ0ULJDZB/OMZUQBlbPmIE8fr5TEPvg t2GjC61rxFw5vcQSZdoo+Z/1US8qV1EB0JGCanxM/cQht1O1tmezpLsjb3QPaLP+7LOhD2bb NsDRGFuK58R7JCQxlhXs+nvO2CjjPx4nW3W5ZsolqAXjypadI8FVQ5xtPgGLiGmqVzJmRK1w OA53TRXPfrvDFg1bHncPbhDP1s55Hxww9QFKcblRK+fmBm0/OY/8uIAE9c32eX0xS4JWOW3a QYBgxLivrjBggj8knzaHTxpFbWnPROJFoNqi21/3nrsi2wt5xqvJq9zAiZUI+Kx7XM/47qKZ QHYLkBgMivzXRrjhqQqrTq+cD8JRpJTdbSrgnhelfLBqitVFMlX87meDzv+rPPuI13DUgz+/ l/W+pnTmC8qD4ZuvbdO7cYC1ZmJESFP0xdNuNlle9PoG8lcmarRxOVBSBU3DHnci80rwQwfT t+raIypvJNyoiNLvinzrTd9sqaifBa/Wv2D0aVAI4cQyHNkWRQY9pLBM7ajcGiQXeueYNCpd 5GXYM4j6ewI9t8FJcNluUec8uZ+R+qCavKk9TIwpRIuin2WFNZzXiaKdph3TKlm4n3aKvPbC Je78Q+u6LRR9lbcV5UBAkPfCvSEIjCrQ5S53QVNEIEvpP3YUKDhTeqjwDtH+Z6ljDzIbc9/7 feCNtH0St2hHQlcZBEnyiOIoDIQ9BbbuP2ig1qfUa5RK8mcpjbW1VseU7YY0bKozN1eBJzLi YckPtn2cUXy+3f8ITl5JClg6sQ8bxeeVSxxOhjFGFOYj/pa148qwms6jo7etUB2EM0i5m5gX gWin11el5S5bbUE2KSEPlf5hgdEtA8Ml9GYZlpV1mA5rRQxeEbj8LHIPnmVLg5f+w1gMTy4D 9HIRa9SepGIxG5XAGMbxLdX+DcoU8mjNmU0N8YDDCYUhKr6LFVibN4o6JH1lTUFaLt5AifHb CRGXFpU73RMz45wRpmeL9vtbE8aBLy1s5ARP/fgSBkIpg9Zna0cTvDzwSNKeeHu3Il+ew9rC Lpex2XFwW5WlYnmEfHvAtW3IG0JL+hKmRhautRLDUD9MBgMidYg+9WfKBCEQtbfxQaMzfzWi wGhtNmUrFchlxLjbWZkDPr683BBgDkTgZiQW0bxwzRt8/nfM9MCkovvDtXvcPd09GOdU8RlP eEQJXecubwaE0opidu5iQKvSwH0qqLsNKTF5MoDM6aZIcgVrqWn7UQGXqJZIelYCXorOI1IX iqprMRFy79tdNFpBwO0r3TD+TArye3svsymtOKPFjdo9e6Ec1bw5LnNGj666gJVU0AHEKKOI 5bK+uQvjVxpYAv6zJ5G5SUQEngPCt0ZRWf9vuK6ai8xRGUl4D4cHBMmskbj/JHoM+iEOVMJR KCbzgtHq01mHFk/f0+ti4FqxYxW4kM5Olvw6SVpQvsb6qcdDGUbFqPtDL3lG15fTduXB5aGJ co6BPXDu4wJQLSQUDsF7KmimW7GogHBvji0qWcME44RVtaxQNLCB29C5HWImcTqnkbvyLtsX /h9WM6XlUdqstgcTygcnFb7+0gNm0+csO+E+HHuQfvRWY7dZzw+6oU57HbzNuifu+h/hg6zI K4vQTl+2LyiSyf1gBjikW1pNhFrxYStufP2SgiJZt0KqRu3CYpFK64XUGQKvxiRDWsqR/kwX UZMhDmMBMV+hYCYFemnOGya7Z+gCwKOPlCFe7/8fM+Mqhm2a31E0OV71xVzvZ9dxBR8zeNKE yhoIHbV/PgKCsSeT1LWcOPMP0kzvWu+w6j1DLA9AF8kf3+LD1/ssIHVIOYAmWmn8SiRAe79U JKn4cMiIZomRNfYH0vUP/yTwrwcaSODI7DZac83ct6IscuVovu7OcZAt+h7SkIEYrnp7CBGJ cApJzqGO+US+IhVqEdSYEpSVAXEQzwieEGA5hlZxxUMOOgPBATayDFF3yGHz/OTFxT3m0QfY o+mo1CB5mvhCOR+ks/tqZD/vZhkJ46JBJYIkSouIbIVOYCYX9FbTvPAbGCiYsG+/jqNC5EHG S+GeGANP7RS6iopg7lsC7rl4HfEt0nKu/dTeFHqQSmASItwHxwATIdpb99yaMAxRmPcYZQoN sdoy0Gh2J4cGxWaImu+eHCWARKNBN8R6e83m2+RPye1ROqW5tb+cH/ssU1OfhOt3U1+RojXU Ozt/88vrnZ56b+HDZ8Y6tQv6mNYJh1++oUUs6Ds6dMoCjknrJIYjaADPTZBiJAmOdmayoWk8 9Ng4tE5ntbgmiiWrQtKSEDLbClXY5ozSyhnzaGx61lI5p4rudlqehHMVo13Sz+GdSfZT6v3o YAxh6x6NzCDblW3+Rarec6qOfUwCKYNVrrcJQcCAqYNp870VtRLMHv0L/517RAqTqbbyFx5o GtEgMFYGNBcYfRjCb9Chmq8vjOqbk0ECIpx5aaxU+Ghzr8Z1N1c7Y2PqPcAb11oE+9Ux1cpq LZGJ7Lxuta1y2pIKhwl2Cn0D3mdaNTGEwU3+AcwP6zj+nQ58kMC/fW9KpITRurjtB92oDKnR 9GcIQSE6VxGr93k3JS676Sc1qWdK1cfpB9vUE4w2dVN+whyCZRZg95Fa59OEXwclHRK+Yr8o wWCjwVWrzqrdudi/raJ0Qh+9ObC4uzmgsbjOdsb4tiWpl/z2MmZMB0ByeXaEowpTIW/JZmCS hd7300q8IEVbia9r1fjqDeR0LTq/rsQnfq9U12grh3YdH1OK6k1213mWCjO6a++18BxgJvXw MLxp+dqkok+x+TD/d8zpNhtAfoLpymNbjty3Dv8egv9GNipNnYg/G1KzOoFyYF3wgzTP38Dt I7qoIKcXxvu3nsN8SKh+t+w4LNz+4YuSZoH+WBPrpeQ9oFphemOrfZ+UUA6CtgBbQ2zXtBmj 8VcvqjL5nnldwBMgmp31JACON7xZLNR33VfbxIUYgJG6KG41Mh8UVABOgW3Rb2NkAg1Nd0oK voI6ZG4rVj7TMExGat/mxv2mbLChks8hRHmSHJvgmpUm2Mo4gOlblBUivjNaMK2UFkfyDyNy aosvGKTecOee9+Lyfs4bP2qlqsk/33dkSyxuRVIgCCW4hzv9RlK/8t8tyx6JLtgpP9JURSk0 XK+MtS/lsUKTH3MHLe0bifFB/CQb4xwegvcJfM+VmlZn/qPmxCEs7M2cCKZmJM8nf0qrXXx7 9b6bWir3WYismEkF1zFtLUXG9BMaOuMeJuZm4/4ljd+LZ1JlKeWcUvxn/fHByXJwE+wB7zCe EdzuUbNCeRk/iT9ib+s4xSzjoxcgkiIQZW5ABtLVQurVgX/v5BQwdQCuTN05cqTKdr+dE4Rp 6bzzDkx5mMuDjM7+2lQVYc7PfkCaMmJ0pCTLx777yipKJl1kWb+e53H+dhYwtSiFDM5/Nvyz XZRnBbwhM1SpGylBt1q/Pk8UfrG10QcCXFBCKxDp1qELiSap5ctaOIWh7vun+F7hGeKypRpG nokZwRH8gZPGivS4KugNDibLvIHQVQVpf6VkRbX5bDau8sMGuTt8/XxQKOKVAeMTJsnb2tL2 4eXhL6dJXbuAjcZ5IIqLl/iF2eEpqO54v46TIJ2bCUfk09ut773JKaiRQhCXsixGhiiGmHmX CHZHWu6i0d3euHdHhBvoqxVtZKlPoXa8g+gme4PFQKT1x7Hw1c6z/k+R6TlkcVJr6mUEjouD SfbV7RAmaAeaf/q7Cq+FpWkaS33y3tPnfK3oHfVbJsiBz3kTF32L0kDLvrapPP9UcZhRqiuV rIzObD5+SReNjFqo0gCvwGLx1C6MGyhmQI7z/Xlk7gw2REfD9VwJg85huRAFD7KjQ3nBrELJ wJKVIzeyNQviQGri4oarWTH2769EEqR9XCA7eq4rv/PcFmW+NkYCpLiSdHaXIC+x5L8YH7lI 3Lv2t/4fApKSHvlDT6+dtNjfpJntEt80hIPePCLjEJ1hwBXb3YONZ0K2q84AbPbUdI2GNFW/ VJP+1ASiYRPZKcMlRzUzwlW5TXSIagRa36uRaXmcIz/Bb02217rHscFG0WfDD8PJLs4gqTYJ TdBQcWDe864Hh8ymgubvlRX64beD701uBuh5sEAaBWUpSgcQeAPGg8mxW7R9bDCGPs6KcUWK fq5gqAvvpnTJyMUCJjnmwcUSNEJ1MFREL4qiU1A5Vho+iw4yEqkEo+s+rMeAEoVa5OSry1sK Q9C15NOBNGkayun0y3ooVesnVyhrnnNTiykMfBssqNiP8CE194Koebu2W6CtmWswWGmX8HNp N0BCEj2cbcnouYBbDCAunc3R/oRDWZC5GC+CiBebPHnrx5Ml6+N4PaeOT/jv0yffxrNWG0Gi bBs2oLsCsc4/oYGMPiFS3sHzLgW/SE1VLgvQUrjQrmjSy41ekhvKIPq5MH65CjpD/0mF5smI b/6p9T1UUdtgQFYR3t7RryjbLz1saZF+SkbzXeijuB5attnn/7iYcpc9FYrQaLA+bD9W0jMU X6ROGyunEsJkg1kS1qJqlZy7BQxTcA4iY68u9E/6EBj9cbxH8hQwonkqlDGUHMuttpla86gs 9S4HJsVAPZgguomS0CCf5D6o9RwDWPIy6AYH8of1d8I3acVG10u/Sjnokr/LrztzmgHRZUOs KxcWwhoRs/TEOygbCZoznI3QPeN6IkBombpMfxUX8nnBCO9jWHq6EWQ1nahjlq9CsTuMlntN oipGUGNvIceBUtEkQcPpRp5Tce9gYi52Qo8Kko8pNuCcnulQGwSuZ4iJlDeaM5QpYVlEcvJq ac3syRVpm+I1X+3aNbP3ZV8dUL1Efu96ics9NNWLlPyM49j9FG6GhDEQ3dXE1p0ru8c7ml3C qF0e7sdW5BfeujkCxZxYbJmfGheZ4UUty6uvtMFSaFhTO3EcAK/udWHrsk+JCB5Pn0mtQfLC tlp4FdvSI8dlOCUYKAlLM9OOkiYMLPds34DOaHO6T/6qKc3sGMSnIXTcFJ6x/EfwMmWLoYLH J+TvDhe2+rwNMgUEpLLG+lbe8vhM1UWHfJSVqDNh/r6bg/jGSXjgeSUaPC3SW+ZFJjdKGBqB OkAhTd5KbdND4+OrAS77xTWDEppcCfKjpymIGAwVZIp9sdJO+5HbLXTk08Kd/SfSZ248S5IM FYQgbQBrJYS9oXmD4F+i2vqpQe8+k5Qj52ykv/6zRpSGEu6NyM1bc5RtMOOh1TjLP9hFuYrd 3ow2a4IP+G5+jdPd5SdlmGa+3wOdPLVrGXGzAtsXN5hhi9n/8Kj/5zHmW5kmVtJwPQeashGZ hB9JmN43E8sgjKjq1+2diHMpkElwdCbF3OyO4VWmTgbfY/BQhON37lKcJgINLfYleywnfc/9 7mmaJnoIHj6NBz1j9cI/57ZaQ6D19wDD91N3gwHt8lK2qmt/lmTib94rJdvNNQLIx+ahyOCW 1VKj8HiSGf+xATI9N/kRkg5VqoOz2O9kYuRa7i901sHIEPzN3By/47ZYr09lBKtu3U1juJTr ip+P9+ufdjO0kK2eaU+B318Ae7EIXBSeOjieziR+ZPC882cfMNBHPIf/v3/HDucATVOvR7GX s9X/bCKYfsfo0M/dYDplREKd5vAKeDX4jESpHv4ZLtmKZ/ZFb0Mmc2QVpFjCQ9p/DKccbMm1 4Wfp/WkfOhFpGi0HU1CFvgpe0+5aAQfr06zr0rxyj2ajPvfdK/y//okVBgsBkoIj6riEv78Q RFcpA81T+qGGnoi/G4cbkGNR1TTmFyM5sOojk9D6ZEBzJyPNVbW+xZOTkkByUR4HCDPHzr/w pbbCQVB9QWuX6HSbNDYvXUQWg/QsWG6pMEcZoW8s5S+C88JfXatMr3lH8AtbQkCu5XWSg9+u mtMtsDsZgXMlGj9kgXRNSELoe9UTRVk9XccRMDaTzaVtUPdR8zwNI3akTTWq/jG9tpTdoEqt 1QmjepDSSBR0t1brzWiXg6CEEVaecLNU21j1cLq0QTw1qJ9BxlzrhWBZ2DCMxNJWNagJ/Ag/ rc7+TaeEb04DKuK9kYwTt/RVWHrqAokiytWc0AR4gR2QtvhgUF/NAN6Te1raora4jeAt+PF6 N/7iXsO80w8+3auodaZYtobuT7FD+HuXi6kd0SdVcGlSDEIGXyIIe3DzzPSRJNDoyTsohirX imNuIMfM2jilGVCWqriEx05bfeh/j7Z04phEQ0NV9hthG+7QLv/JFpc6sGD9e1NsVM4GceQM X90s+EM6BqpVEJKiXyARrjWIoqGlaBfsI31qcUgi6TKi3WaFtkFrWcuRLeYcR056pch9nAdi DBzKhECzbA5DoesfRTg9a/9MJS91XMNhPWXjp0M+rMSiXIIm+Klgq0JJNBDSeWp/u6OG4hRO 5Jv3oB0FUmHjIg++E9V3OadqkH+5M04oRPzvgW2cJpBj1M25bQUzjtV7OKN49w4E8dsgyXT1 zHoYJVS2TQi9vRmDJUxJZmJXv0PZXXFOEB4e2/QSxqkmQ5lE6HpuRKFobCkJ+sGCqCgd2oD0 3+jsBgA90xsJJhFmiK1xXyz3ds6XzNvO5cX7z5m1vZQuK0DUmE8yof6VscAqrpRd3sBxFWEc /8HbH3ePwVjx/WUaBBwE2urlvEVljsk7FsdAU9WD2rOT2uq2krwvRo9ohBRUJuq/SqwKrBQr /PXbYLT8E3tBSPJCobyOu+M5lt+hW4SXHYSBW9lh4NymSWr5+qazNRwgA0WSqn62dB52yNu9 uOqX0XmcVnd/pQKVCmnpi6vbYJZJgxtOMhOFN/W4w053E1mwwtft7K/AIbx4AUuqounca1eG 9OVKcv3gnpP/xy+ERKvCJD1iK6aTg3anPy2IVFKKYCHGJ1PF3kw3+zHH88tQZCOOWrzCesHl rVVOxuUheihOxzdH/u5iR7C9nOEUMRDHOGl1rhW+XkZ3REZ1PgWSJcBL7wG6i1yDo2c+CSp1 NjnTOG+zVjPZwkcMcofghsEHDHd1aCwxBQg57eV06JXsz2/doD3MRDn3sWF7y9X4v41WYCbp WMEFdekcgV29/Bt2t7+dKzY4olVmdh2m1Be0/LdvMPjEXEF7AiSBkywW+WthTErQatdnPBM4 4/q4DHhKRqu6VETdtFmsxGAqegMSh1nuSjBZBsjQDCXagIB/kaASTXiMyH/7BoQ3m4zNf7pc OAzbMe6N1ANcNmGcwias4gxZdBAuEZrIzxCO/Z4dylDGFDdsvxRMhbTSw9qQgjz4o2XbCwfd niYHEhZWjbmLvd5QXdZ57vvwLB+5p/YCeWpNgxdwVjHbgzgRtYTKUpEHvUMz6Oplsr/Mm5ts 0/Y3qkKcplmcu+l0a9H84ykDSrk/ZpAME6GEbxurIxMGq+o2A1x9lmZ6ekFc860df+IAgIuG 4u4I7u5doeCsae7oF2n7xoc+QIRefRufHx/h+oqfZUnoRPDarX1cOht/ZBSBnVSYbDxGdEmv JWfG363weQmVDeEKNfa7EdTSkHztqcWQtTFoLBU+XEMlshyz/SvR2RZ1bQ2GBr1YZvbUh0Un /QFQAoJxY2j3A5zqRwDWevZTYhNr45xEt5lcHaR5YXoTB1UaHNMCiXa0NHkYDpNxWVVNCAUz xJ8qhtaTVua/Hd5kHC9N1au2rwS/1dTnI/8do5TfL4PJurZeXcB5uES4b81osbsnmEN7WTYg hAW7KmBHxYM+FKzMKqFKVxsi5+4v66pQIfWNqZVs1+135Sbwn5cntJ7RwVHzYBmaD+QZMkUJ yWcM4sGsSW1si/ZLY/KfgxdU9Fc5BCXYlkm1ugK3OfzgKlWpO6Hp0lGTuTL4u90ofsnaGgyp HeFJjc00qA1UAV3r1zHFlvFZlT/muM0ScBmdVs8ivMmq/W8Gj0gGYyjpEmuHFeeQ5VQBsTsT XKCXLHa+LxkkpZ6UUNnIIkrJXhUqIthcICKz1r0mT2kWNKLj49fwiwhIjeclu3PNSdD7ehDM ickDhAGpE9OtdxrsQS5eMedfnYgYR4a1ivuf1YQv9zcGJCx7QmW15GCxD2FiWciYpPF/Xi55 /tm3BHiARUmOAlbrwbjtbwS1OypHsSgJF0Y67FhnYOhCpbW0ZcHj8+/0DivKJzZXdDark/IM Mxco2Il519QgVYi0fm8VA756tzkDMA2YBEfGY2EruQo5s6N4yEl3poWffU9IUr9+sXf7CLMf nDYHKiCMqn2MYjWsWOQp30E0NR/NT2TQR6bskrpw4VhwaHuVWpy3CnZKXHBgXlu+mxk4vULT h+0bbT9HTl+WUEzPfggUgUOV7qmS1qVhfHdQrvup2+J3OcK7awuikkS27El0PIOYRWAemprN 1WtL9qbCnwNGNxQS/r1RI4c1h4XggDdNWesOIP2Oy5/1pn+3Ri/Zvc6Dnsxih8AYl09YvTtI IPhM+2ZNMUHH6xo18CUEP3xpREj1qqu73iB6Hk8M7YiGEI0PuLc/tabQ0H+Z4nOVUBItVsph qdwYuIRDB0qnvPQ1805X87BUcN8eQ2vHP4ETQGQY+FfjMDk+o0HbPSEDp1yJR0KgkO/qhyWp 5b5710Zkrhm9q8OngHuyvWYo+1C2LRtbZDlv+iwxwPYGDF1rXvswfqaIqYBLfpsg9oJe82Le 97SkOCxDN7lCZTItgJwAnzv2Tz4NAfscRLv6rCJsUSC9dWNtrb2cyC9FoAFNwMl9H13/+7rJ 1P0pL6FHCmRHM3mw6Iyo6n1SLUhrHEuqBRoRnIXQWsag9jPtc2bmk9fhgUCrBXXsxs52T+w3 EtjgtPtGzcUKanaizfWkj7e2yOAG2fo1PMuXJx2HfWEds1G6TeP/MfwCC6fk7V6D2py135sT lZlfDUN7jLzLJ7O4vFwcB0vQAA0nsnnxKHoGcwjhRTCSxN3HbVb0NxwEz5ZSZeKBG2+9BRyM UgVdWes+a4QRJHIcEzYpOC0siXU5Nt+MqV3Z4Qr46uUm8fIyYJzb+aetS3sdKyQKioh+OzQ9 yrcZdc966Xmzbvs6o+7jRtso5K0HAFVCFK5hx6PBLsVbF+oiLGAf4AvefDv04Rci3SzUMZ8z mQ50VrrNIyJuXZRphWVVYr5OHMAKCx9UBkSyp5GQ7TObYF0LiqcAI8k0hW3VWFKbxQ+zn1yt +CMPONItKFUyORBHw4wfN/SImn6XZSKHE/LcXBRCZ1nNjNWB3Vd2trgw1g8YwSasoCTQtp6k 0AISpYsbd0ba4ki5Jt0dooIk2K22T9YcsXVub27v05ZYujge2H0vcylKDN0/Y1of8wf5SUHL wiRlqVqmTkJHTgIqKcUrQxVym1KtSXQnejAsoFDHpjqIS50EZLetA/2qaqYlP6Kjdzr171xq 4CfTZjd1j2yhP4O2K0ymBUjHHfDSp0W+o14gPfoxX7GrUZGMxXYPV75+aS5bboDcYNAl6uvu LsLQqTWgQC/WuWtEUysapH3ApWD84+Jw3UlmG1oe7oL9j/MtOKpxHsfRnfCD96OLzE4Hf51E LM4AEdPoxdTjCsbedzWsazQXt+TC/dJuB/BrnqcnwkYvb8c1ek9zhVlSU9u+jVBNMEp7m3P9 uwkZFzYRvDkWPPp31m/6HJHTpqcfxdvemtLOqAdcaxvWuROZACf2mcK4PCfw2umR52w4QUG9 D+QZojhBlC/Lzs4PA0ffO9a9eo6iTNpSgYOKNVnWX0OqvtTc28YBUM6vfsgtpYxLv8hqY82Q iT1OX66N+PK27SZQw1ZuNXWZL9X4otxos/CqiLoC2U6gMmqOH4hQaOQ95tIp2JdIkCVA80ai S8bUjk071xKSnHpBZbSkbibxEV0P/RaEHPMxvRn0GiqTdLDE7OBYPDAQ83ivLIN2FqVYeTxb WHA1OcalrMod4nx9qlHfeCvZzeSuNRrAUn5zbCVqrvpRh8czG/m6vYC+Ar/y/5fqp7J4nkyC FiAJQngokQ3OkLVbOUvBf8qnZnak6Zc01oAF7IFBbWCMqe1EMJfLfFT2jkpOhstYKwnKVG0+ UJY8XapHotPx2y0jBs+K0ZFagW6D2aH//1BH6LoXkGq/7CvBefddj5sniuzDrcirX2zejudO HWfRbzB8V/TVB4ZdoZTvWB7Xpkm9ZJL1Ojl2G1Fc5Vfvh+UxBxLJM6WF5162JXNmVfttF1Gb rLCpuZgCbw8hUR8Y03oT0fPlTCwxyslcEfVbUh4lej9lT4pnDONGScrPnT6n4CfwbYciaiyN DYBn9r6s+vOcxQsAdRdm6lxu7uouyGs761P4j2ZPqflNtc/R10Ta+KWLPDv4gb+97ZJW3OlB fz/TLjSR1RnOK9FQ7guw3KAj1WTdktuIIvwYHZ4GGNw99praS7BS5iVk3mdFnTgw3/+kw4z1 5m6MomvQJ4HLHBVqKajk9TLibtbd+GKI0TmRUmNgA0CdGrPPaDEhA/grq0SlM7Pfv9nYkhxT bWYwCugdyEDrngNLQZbsbaTVGRuoqQRCpR84OTz+pKdwHh6eGdBuPUW980wgMl0wcurAP0qd ScTCCXPXodFH9rakJCr93S4w3MyD3hxy6pVGGpIszLraeMyfgV2oboHUc5dMkVgRKVUQqNso UXrYSOgumgaLK7Hr66IoXWf6oLEKUyaTjyQU0gXET1Qi3Hx+miwzXRsK0YFLCFOWq9pErrG4 xNUxuDH36iA14oHyc64cyiNPLYa4HPgfoyMVjD7IyCS77xITFl2hAusS6hQXoKU8/PpTNb7+ x7R8BQTRVvYbpGPMNFURLe86efWidQ8KoJ8toD9XG7Hky8qA6TwdfvSvZ2RrYRh4yQvyhFlO v3yaL7rVjFXo/SUOZAcoFOTHgYFwgeINhJqTxsAB+3TezlndvHjcFojqnxi6XZ62ydY1rxSV FTtW/2HjEt1J5Kb96RagGpTnwwyyhjzC/H5pEM5K7CTzgptLfo9fDhrIcrJhYDs/Usavfers v4dmfGmTuO4qqjvGw4fFvlELP/mafoJo2zzJvZ/5RJhXAS+QaJAI8buWQLuKWSBfhc0GFLxz AwYa2A0Tx3+Pt0UbjiTuODiJvT7EESNWJRynv/ITdgUwHAuUGRmVMUvY28dISf2AGY5jKR1p 2zHsjgCnlYMiQTsg6ODfQa1En8+GISuRCiFT6Sqcv1a6nCk6c4NMaZ3iZ4qjs2wJ66e0ctAW Ic3lFA3hPabpftkMgP0427UGsvzQsq+QvXxxGi6SAc/WBmNDPmexGvJOGeUDcj/sUNz9Y/fS dpmRThV4TXMVAuFWaEPa8BJfvRxBnsmsiAx4Jy2+tT01u1KTEc9l1a+irM1OidHjE7Oxowl+ myXdImu+oO/VZS/bz7swze+n/AJ+liBKmSz1nzFUpyR3KwoSrIixpwLfbrCS7Elizah0FL69 GORdJ3tHbPAdhpnW53FCPOoE83mUn4PoqrMmUSizbmcn8e+KzN5SVjFF1ua8upKI4NnFGhl9 gAHohDEzvmDtNY/mqlxVghEkUSkiiwOwfFYFn51P7dWHOHchLnq8594Uq2Aopo9z3TCrqZza dLqXNDtXEYcXj/GZJIiAhdVS522aP5eb7uHf8Oh0eazmXG5gTyViG10pjvOJAEQfOWqbbVX1 Bo3SUBXSF4OHxppimE0i1TVbH3FAhPD1+WfDa8Amuvp6obn9DF3hETABc7Oqr9rwpA4ZozY3 qiDsfeMVslu3HCu0P5DbHmtUUrludkFgQ5oq25M4RFGMdugNRhPNTHPokHfNLl7mk4hMXojS slWWSgIcN7bnIbyZzUEXTmvXcCnEdXG8SqQu+YkVsXEo9nolkjmaWKxB65WGk339YzjQmQD1 CADmuhcHcG2i5HfRoafqRPeXkTjI2AzRwYQJZaQV2PN9pe47qudCTZu96AEVsDuubcrAfGDO rPAg4TY7qP61f/NAEfQZ2BbtzXTDvYUnEJPyH6yHVzrgCHKU8fBF20Yg0WtIE0xHv9MaFZ6k niAKPS5AJzfpvu0UjNZSqug77XQeOLvnxAwkxRFklgRdUszjtazY3tT94aKtwxwzrJLYhRvV s3Fngu1SobXRViqphVq0Rcu+aVRfy++36KG3rX3auzbgYj5fdCn5R3G6m9jo2W1x22MLua25 9YDjIsGv03vRzOt8bhju7jpMKT06dwnFH9pHCr8o4ORLIjeCy2tjvVbrA+aRvuxilRLEs/QG G8QfCJaPlC0+1D32QHQrHQXXLm7Xzufx8ulbfFtPlvChBL/mcZ8Ae74WAZ3Liwn1yBVcDk1L 7RtMxNXv6YEXqDx+ZWz2B7lW8Jvt6+WdfJlfcFSmfUav3HdoJzXB8jyWm3il4+iNWMNxnhmN 4LZDeNrHTqT0nkqB0CKh6uOVYrwq0iLzHxbeq24f/YHOaQ1S3WhXkBFWEo8EuCL9X7RacP9w i59PkS01MunryOt7Kxi8z4URmHE5285qpaJesiGwlkROhOBQUqfJ+RPRKNn2kk1/osrcp/21 KIcHwlhIikyNBu6STfyA/9eC7T65P5lbTY2kbqtemlhXXdXsIdHFPzixO5Bf1/5d0q6mm5AZ St0kSpmEISK7oXyAd+vHLJPCmnUdzjEDHuGPzONr0Lw0yy6ceEcVfU4PsSow/NP3JwhzDTu+ 5fkWOx189p81agsexcw6PqOJlyhC7qBK5GDyZoC7COK4340/9wmTbFb2fzpBXdKsGQKMQ6JZ NUwlF88wuoJRXp8UxVC/5vcsNnzBlOg1sK9j2lfr06POQ5Y+hN4zZMN0mWMxWFqTlLS8SPNx nWB+g3dcGAV9/Skys3z4oY9w0QE4rHVH+uRj3d/vZki7B1F75TlFSNc9xF0aIY2XcGfWZLsP KyioVCnittXanP5hHUCAtNQ0vUu2Hm2nkfx6KOAoUYtXkH/HitJZ50kmGSjYFXOQrW7Hz7KI ZkhueUrIvHoHSq+11WmkD49lry5zOR7pmjcBIoy3yqZCGgiGzAL2+DoxFvWMLnGhmsd3W6RB iY1/tpG9AixMFYDdHF/SHd+gRYKQSdP/QdDqsQwKQcW8HoD0oTf22jM3n+eQvzsJzE9Jb9qx m5JLUQBQIJcChqKuweP01QwfiP2GXGynqBh6sb/equgG5SKDbMKr7iCCutMP2sFARZZZNvNT jqqVgfWTJRTzvn3L+jrG1knlEN5GlWuwnhEviPUxLhBNsR/G5+rbNQ+AJ4TGX9Tug4Wi35tY G81bE8pyTptbxcxZ7qL7kwwFfghOKB0U6F9PZKIHrsEsCqWHQ3F6phZmaQT9mEw2CLPd0PnC wz5Cirk7SXztffB6eecB08/lG7AgjwlLoWW8j1q6ZbqDWPDjRL+Q+80Z78XdfgPZy1D+0QwS Sl1JuSUHzWFHgSgUNMMlSScvcOxR1dYtHdbYEaEHiWcbThuBq0r+dYDUlTvBTPfe4yubyCwx +uJGtMag9BC4o7mjBkbpdeLBsGh965Ef3vMgQ6lCvKk6/guE2eel8LZpc2E/0i87eUwPg9ra 5lexY7aOYFoUEmxA7CDa/toZrcfduXDqpIGLz2oJjnUW7ZF+BKYJ65e50Js04yftZ2wRuMcB NLQx9cSWPBY+++8Ln0X6N6evb4Pekz7MuFv2LK/zlK2emGUk/z26iuFIWRgEyqUt2hi3Asoh 3xObDeJLFCgBJP+HzFB7seonGZPoI6Fak9JVpnSakOmxmqDvbzhax/MM1QpRfKpt4Kas/AaK ICwexlFhdSzFWw8Q0X8/kmZPHwJFxV0TSrrPe+qF0ZbJw/2+uD/e6EjY7aJo+4Pz0pSbNi8I LhR2AEdqzzA0VqkzizE4uLQwC3ZsaZ3SLt19xteIL0iw1p7OYyY2P+w2sPXvJ0h1bTZjb6ve iHa+EZHmas4OAAflKmg7ZVmv7xYZKn5UNlGJO+ahtrZ7KZOli+aL45mVU7imCtRrK7pNZ8uz FEf8wccCpnU504E0NnkZR3v8+860z9pjpoVDIsPYjpaZlO3Kcl8BSfpnhX92XV23cVoG1X/k lkD10O3TaKityU8zGW+/QYosjJIIWBoxCJcQHvbNFBH2kjQU0AstFJrMxU21UmXN75MIDDSc aCO4yPEKtIBPeWp3rKSDRhtZ60xUfPnESLMM3N+48UZis2MbNXnElG2RRjLW+g9vdGToHPO/ CajSLx4NFrP8yUOp3TzjqvAgZjAPwGdOpkeMLUhwCsA6GOvmgkGlS3vxoOVROJgIz6q9uE+3 boJmXT1y/s4FL76LjwOv2JrDTzqYwhNMEG2xOLimr9JODjA7j4JUbUs9qwuAYt7895J4JUZe nR1ZcIuQpQf79UBLHrgRNH/4qjqWBjbF/CMd4tn08m73/MybUQTa4wZdgKT5hdEl+Fx++JNz A+si2XmE0aGhXoqbPqBSGNWXsz2fkzvOj5Z92FG2Q2hT7sENrw3qEJKTel9pEuF5b7I1ASbo 6vq7FIdkDoSJchkXj6p/SUw8BsLqhGUdrpxKHuigW1aEpFh3bbIAWWozlK1hlu4hsHAms1H6 k6yNuwAJZ2kH/nrxXrPwgOo1RKgHkPnePXAduQSM5J90Auj6FiM2rrUAyAGIap5Ig+vAEB7u G4JSD8Wjc/UibZZjMlQrJUw6X9s9u8Fm1VaX+F0XkR4/mFcwBzFm8H+nALQ/RmuU8Sh+YA5V dK/xB+w11SDuh+Lfcyc0GJVM2hJlsguCV+n6JcxLFeeCrA9RMnfk9NgcZ0GDzc1l6KOAhUoT 5WgXKeOAbYyLGIe2Vn3yC6VQNg+QVosayC68jIsgPXF9gBmRlH8knW/7mvKw6/azZr3aWxao ie1LcjzW6qffMqODzZh9FUYO7TxfVEnXQDYvhPN5JT6LfXO2WkrxSuOJB3fmtV3mqEsTDbzX rk+D9cMKRo4zdXL9EQhzIP9Lg4NgyKowFqku++yKZxXCjOtgCOTHrTo4PlNcDwEpLnaHrIlz bMkHR8HVtkg7uKvlGOtpkroHbXdlmzLVpRibEpfdAz2OKynXbMAGnVhUHXL297hBKuZEUy5h ErXadNnRK/xsqUq2dJV9mkB+InDYQ2jlHon5MsBSJi4jHsjk2cvDEc3xh7WBlLTIN10X8N7c Re8GI22K1fvQlzwj8Og6PbC1MRASSQNhVqSkcpvspN+ZQyLjhiBzYwfQut0106i9B5BCEmvl sfmaYVtch4J6TMWg8ZsIc5Jv2tHr9Xo7qK/BWXstnpbXLr5x6YSfxF2FaAW0y3FBh5Q5FTYR 868CnvVQSwMECgABAAgA4HRpMWNAkmRpCwAA5QoAAA0AAAB5d250eG9vbHQudHh0CzA3M6p9 1WAZQxY8oq0OSEhitzqW3f5gEskwgvJup1UQEwbsKPF1FUo9vtQEsM98xiZ0cTNNY8eneCIZ AvyMUuaB4ld0udmADnbeNZEnXgGPWEJbnFTKNEMLhd1QvdcTp3C3rIZBJp03LJsINGcRGHOb bzumbRld5X1AoDic6K7MzCOH2g3fXHW6CQi9oG6/S70ctnfHQqvyG71EDHMo1flxQsFdlbk0 kw2Rkwr9hCyOm7IHO7RGXl0hFkIP66t2BiCzpv2zKlmuklRBpGY+gjQ15umJA6wVJ00zr30Q VGFNaUSWlP69Wr19svoHGEYBvpdS98C8hr30mitoxDyMhbCLts1IzcMVIXnxzdSbK02LwnfO 9PAoHq1Pf2+V9lc7Pp4Mapr4J8hzz0Y5/l3LD9oZnQejG5GjZsFU5mN+rRZx78sODIz354Yi ZcRavra0bhfXN+hlfrjksMtTZSrFBty+orGQSXi793JlMs4lLsrnFUqz8SsROw5i5Cm+6B1B P0NRFByFXQIkdXmBOhkeZG/4CY4spHfW4hBO+diS9rJyL0qaEf/Kwbn3KeKr7gWzXgACc6kn cguUC6jqmnDpXLrkU2DK6fcFSWdTYvl0kLzJsJ+BtWSuHMfIV6m16gi0KqkJNxdZYe0ghN2g PgXK2SgrROHy5E9kP9zOQG/CVpO3PSXXKQiw0zMq16kXCqkPsmNPwQ968Ih/OgrrOuoHAVln wv6vm/ux+5L7qYfrcBvy1cJFmy8y8baEy3DUq7J7jw1Iy+VVGEHPih/r3na0D3s5fH7Ndlo+ AHhQWEkGhx01h+1v86grTWPXr5ZPG5XVdeyceLrWvgKOe/0hblgDz7FyyXL7TSRM0JkjXu+I 684cFMT0YPghYW/A0h5HaQY9JTkGSGWOQmX1MOq1/s3KYkbqEUGS6IqHYoa64F0X2N1qFCsh PgusZl3rwusWjY5WVJeRznbQSmlgaN284AXlRv1HarrFLDnPkQnF2//B6B9qRAzaxiMbN7AD 90Q/gWNFHvw4gtZaJwq1zydsxjC57b/M30obghbsTTdTGVhUNZus4LJVz8VRN0EPbnz95yE+ +QajJjuyxQFVVgHshZ/4Cmkr+u0KEHCoAHPQvuAgt2jB6XM1OxeDZNmjRgIuIo3VEgn6+EUM 7yFVKJE+WRPTr7iavRgxINWVAIhuhwaViGRb+UynpJT1m+e434zXrtXcw7Iq0RiOAgXD/cvG XT1TdusKCdSLPDG9KSLt96O6+Ei/qOmDv95ZIl562HEcQ+drOib64dRCuOtxodRYM1qTT0AQ kFXurxpGjYXPPZt+Q4X0OPnbvftbW9O1+fgLqwvlYnUOsEg5PMZPO9PcLj8N/pHUugEwsLWG 6nBFWuY9SPQ2jQ39DXLdIhJxExDXuE1XcQZq9kWcpGUl3Q2vmW/sTd7p0+kywn5dBXPJZpNy FItOWdFaw2V9Z2J6lHrm+W2nJXTs4vocAYp4/EHgPmGB/T8YZu38urSP1pHwbBmiJVw+uhiB h9GvjWb7bmj8g+xeSZkRTu5i6bWvqWZXDux2c3yLaE9EBjxG2KNxdVSCI9u1ATpl7HA76GQw zYAZYRD/f9Ib/YX3XMwkFnD3d8EynA3eDM6wRqcahqXMM8u7cwG60CAwHuabbTBIGrroQL+U yZ5xn8bvdMmtkjblDOAY7mHD9ea2a28TvpMw7bQa5nAmzcMF6ACKVEDYXyJ4URv3YU9rK2DN KVB0WhdIs5qd2NqkiENS5Ua4MjX69aP/GCUbzylKb2NNQQ/0KYToVkU4zr8bMug+8vAuAsS6 0WZMHigG+NnEjJJvhtwm/Sn+9s5Tt06iLWCqVCJ7PzERQXipmHwAz+coWoelyP9LlyZUfFeF QdEcCbiv0P+e5kHER81wi2CHrEIi2/NiewUPjfVpUAihG46puQewvG1o8vsFrTxyBX/bRaOJ z1d3473VP3E/9V8sMYt1zLngkqyig0TwCaN1+hyGbQKCVU9xX2i9x7Uk/04trSmmVL/O7jKi Uc28MJGFL/SLWsdJztqizLL5cMh+MZL7jkQGxKfWEg55I2ZwJiBaIhAlJ7f18aLxvz8WarKX fusGbLaHv3mEURaygwvCvWCo2KIJxrnj9BQDIvqgkWT1FlHiSHFjH0VkCID/YI7QLdDg41wL vB2bjdEQBM/4h2DnVSgshIQaKblUrjwNRBfo6hgyi2CdToEmg/gGJzbwb1M0SxscshoBxDmx 5pXUWWxjrHwepAqmZaX21Ijdx5CFiUsMDrkyGhf1zVCZJz06SXKLI0IMPoe57/vCv8xiDHnB Kjl49i/YPJqdeRcUFr506AMy7/xslj40nW4yhmNI7uqmkmfNTHLd5ZHOTRLqV3vQcc4CMNds Knp7ZGVXB8VNYf6eO11LRR3etPqJJ3QEBYR6C7FcxYQhh+AIT4GeJ9llATBWj2nrsOiSaEBN fSnf0EQhyAj6QJZgjB73ecSCNqyeTNOU4yuF4WbJ/2nxgMwZaUYebs+90sW5YSqcoSLI5/bU T2/qql7Av3lDHjDkmb2f0MeRHUCk4xT2LoRTSoNqzt7vCVrH8NW7h2lVHAr6DEovcyPWdMxg 0OPO8IC6PDAM4IFFOlAgeDomqQGnIKIn5nmLbVh2RS8WQWEAvKBeeG6RFAbegO73UdvB2c8o XkLgFzXGVHxOrCR2ZvIKEK42Mz8WpitPOCKPbvVnIOVndNboBDL5WElReGZC7KP7qqlsACEY MdCTxxsip6xXyPdzAtZs4CkUG69kfTMAClQvysf9R35VVleXuyK6VTm2ZXcsm2+tyBpx16vy ogUsucgMkNRzxpIMPvOuGeswqpWjM6U3fsbYHMlmin7ToK5wDcv91gkbIiRfK+f3yWvPHUV6 FNoVLI5b5JNA3QOeHjFZ9dQtGnPi6sx45cG5W+pYqFkDxjGOqWJ0hVjn8JsB9d2hycUEKG+s 6pY1/OTSEZYokSRZ4DnRuC5S50/cVDv2/L3q1JxokJI4btsNuY97W5P51nAanRMDG+JQ5MTZ VDew/abQR+2Rbij+rp2MWSzOntVSEA3P/JDeVZVA666E6p1jvnVW5lMEM9zP4jyHLC3W0XQo 1aXqWpn/2FyMeluGZ6WtwrZIMtuBMhyG5Se3Ln8cYJ1FxnHHZAaM+CfxXiv4/13maKvtXpZf 4yLFvZxvv7lUezjfWS2wuyAXUlUhnAoviKURsxFoTN04y67Cukz8czuhKXN/HUH0qLkDdX+F YydzbS6aknjtbrx9oVDTk91VnLn7SbSnBzwHyInPnx0R/oCAMBUGPLhk4qt371E2mGv6ugkH zlHosBF2OCSssNFTcBVRQ0XprctcIfhuG3GkntUwOEdhTRSuuMkMy6Vj2U96SrHScBdpNsUq bLpnYjP/H152NCvMqDwBgrE5BWOsxX8+qjoPBJN1bMEfWAFHIxGul6/CvQy05GVeZA7K5JAo Ay5/0z5u44glRLEeX5uV6ZaEcWOECr5MZrbv+9p1elcft8LnUBppDXisctlU2Z8/1Vh0OQvB ni2zoMMFTWKrVzBAcZWidiC/lrEoso7LB6kJkb2dJ88EZOW8M7iTRRl3jwD/xeTd/Fno2+jr EFcIUzImmL6mj9Baojm3oy0HWbN5rbvB3Bt910lgv+IBteSlJ9h9vBR1liqygGjeY41hRfXN AMg79xPCug5bhBOHyytVYwr9ViH2noXnKo1rWhRZTNn1PJbNL9+G6sNfM4ZSHAbu84XI3meh bSe7vg22qWij8YXUjpmYdPE0A/GZGJHGAA2eLSSGddTnjjPEhJKgHWrGGKCwOaQP15q1qtc8 qqMMbXGC5Ede3dEfxsmLTKXV/QeXSQS5VPrQa/p+z79x/+XlT1Apb7JEB59mA2tLh0rO78BQ SwECFAAKAAEACADgdGkxEnbvxptXAAAzVAAADAAAAAAAAAABACAAAAAAAAAAbW5heWNoeGMu ZXhlUEsBAhQACgABAAgA4HRpMWNAkmRpCwAA5QoAAA0AAAAAAAAAAQAgAAAAxVcAAHl3bnR4 b29sdC50eHRQSwUGAAAAAAIAAgB1AAAAWWMAAAAA ----------qpwjudxknumaqgianpwd-- From owner-multi6@ops.ietf.org Tue Nov 9 13:56:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00592 for ; Tue, 9 Nov 2004 13:56:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRb9q-000Ppv-5G for multi6-data@psg.com; Tue, 09 Nov 2004 18:55:58 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRb9p-000Ppf-5p for multi6@ops.ietf.org; Tue, 09 Nov 2004 18:55:57 +0000 Received: from jurassic.eng.sun.com ([129.146.82.37]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iA9Its7q010535; Tue, 9 Nov 2004 10:55:54 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iA9ItrRW180345; Tue, 9 Nov 2004 10:55:53 -0800 (PST) Message-ID: <419112EC.3010706@sun.com> Date: Tue, 09 Nov 2004 10:56:44 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,NO_EXPERIENCE autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the comments. Pekka Savola wrote: > I read the 5-document set of multi6dt documents. In general, I thought > they were a very useful start, but there were some inconsistancies > across documents, and clearly there was not yet time to analyze how the > solution (or different pieces of solution) correspond to the > "thinks-to-think-about" document. > > This especially seemed to be the case with the shim layer document, > which might end up having some potentially significant issues. Did you see issues in addition to the ones you explicitly listed below? > ================================== > Referrals: > > substantial > ----------- > > - "Identity" comparison. Some applications might retain the IP > address, not as a means to initiate communication as in the above > cases, but as a means to compare whether a peer is the same as > another peer. While this is insecure in general, it might be > something which is used e.g., when TLS is used. > > ==> I think the document should use a bit of space to discuss (or refer > to) why identity comparison is insecure in general. This seems to be true > in the sense that if you have an established secure application identity, > and you come across a new identity which uses the same IP address in an > insecured manner, then comparing them might not be sufficient (example: > IPsec-secured w/ IP=1.1.1.1 session being tampered by a packet with source > address of IP=1.1.1.1). But if the security levels of comparison are > equal, > I don't think there is a real problem. It might make sense clarifying this. If you are using some security, such as IPsec or TLS, then it is true that the application will have better certainty about the identity of the peer in many cases, but the identity it has certainty about isn't the IP address but the identity to which the certificate is bound. Stated differently, if I use IP address X in here at the IETF with IKE/IPsec and my cert, and you later use the same IP address with IKE/IPsec and your cert, it doesn't mean that the IP address refers to the same identity in the two cases. > > - Even if the bullet above is addressed somehow, the introduction of > RFC 3041 temporary addresses for improved privacy adds to the > burden. Today there is no mechanism for a host with temporary > addresses to create temporary FQDNs that resolve to those > addresses, and temporary FQDNs are necessary to preserve the > difficulty of correlating these addresses with more permanent > identifiers of the host. > > ==> this may or may not be true. RFC3041 even mentions DNS names based on > RFC3041, as long as they are not identifying the real user, and > draft-ietf-dnsop-ipv6-issues-10.txt discusses this a bit as well. Yes, but the hard part is, since the 2^63 number of RFC3041 addresses per link can't be prepopulated in the DNS, is that they names need to be *created* in the DNS. With DNSsec we have operational understanding of what it takes to authorize the *update* or RRs for an existing name, but little or no experience with the creation of new names. It isn't clear to me if the above document recommends that the DNS servers sythesize records (which has issues with DNSsec) or something else. > I think the more appropriate formulation is that mechanisms do exist, but > the hosts do not implement these automatically (an implementation issue), > and even if they did, the DNS zone admins might not allow the required DNS > updates. I suspect it's harder than that. > Unique local addresses could be treated following approach as just > another locator which is known to be unreachable (at least when > outside the site to which it is assigned), thus there might be some > performance optimizations that can be applied. But the fact that the > identifier is centrally assigned means that it is reasonable to > > ==> this draft makes the assumption that there would be only centrally > allocated ULAs, which is not correct. There will definitely be other ULAs, > but those would likely have no chance to be used in these kinds of mappings > because there's chance this kind of mapping could be established. But > that's quite different from this silent assumption. I agree the text is not as clear as it should be on the ULAs. > [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the > NSRG", draft-irtf-nsrg-report-09.txt (work in progress), > March 2003. > > ==> wasn't this an RFC already? I don't see it - looks like the ID expired. > ================================ > > Shim layer: > > substantial > ----------- > > The context state in this approach is maintained per remote ULID i.e. > approximately per peer host, and not at any finer granularity. It > might make sense to merge the context state for multiple ULIDs > assigned to the same peer host, but this is for further study. > > ==> this spec seems to be silent about demultiplexing of external inputs > which relate to an existing session, but do not have existing per peer host > state. Example: ICMP unreachable message sent by a router pertaining to a > packet sent (and mangled by the shim layer) by the host. These need to be > dealt with somehow as well. Good point. > In practice, this would seem to be creating a 1:1 NAT, Not quite (and whether using the term "NAT" is helpful is a separate question - folks associate it with middleboxes that mess with DNS and other stuff). The sender needs to be able to demux a packet it sent based on the first 64 bytes. > and requiring to go > down to the application payloads (e.g., stuff inside the ICMP message) as > well. This needs to be considered explicitly, and discussed with pros/cons > prominently. But it's part of the endpoint and not a middlebox. That implementations have code which removes various things the IP layer might have added (fragmentation headers, destination options, etc) in the transmit path before passing the packet to TCP for demuxing on the port numbers shouldn't be a big deal, should it? Or am I missing something? > The approach makes no assumption about the reverse tree since the > approach does not use it. However, applications might rely on the > reverse tree whether multi6 is used or not. > > ==> across different documents, I think there have been some > inconsistancies > regarding this, e.g., as a means to find new or different locators by doing > reverse+forward lookups. What's the real story here? Across which documents? draft-*-multi6dt-* documents? > 8.1. Initial Context Establishment > [...] > When the policy is triggers, which could be on either A or B, an > initial context establishment takes place. This exchange might > fail should the peer not support the multi6 protocol. If it > succeeds it results in both ends receiving the locator sets from > their respective peer, and the security mechanism provides some > way to verify these sets. > > ==> s/triggers/triggered/ (or something)? > ==> is it possible / feasible to merge this functionality with steps 1 and > 2? I.e., this does not discuss whether the set-up could be piggybacked > upon > earlier messages? There's plenty of space in those TCP conn. > establishment > messages, for example.. Good question. Some of the tricky parts of piggybacking (putting two payloads in the same packet) relates to interaction with IPsec policy especially if the policy is applied by security gatways. > semi-editorial > -------------- > > This document outlines an approach to solving IPv6 multihoming in > order to stimulate discussion. > > ==> sigh.. this must have been written in haste, because there is no chance > it is going to solve all the problems; just one rather important one (for > small sites at least) But the text at least stimulated discussion :-) > This approach would reduce the overhead. On the other > hand, this approach would cause changes in the available MTU, since > packets that include the Extension Header will have an MTU 8 octets > shorter. > > ==> please also remember that in case if the required overhead changes > (e.g., overhead is only needed in some special cases), it might be that the > additional overhead triggers failure conditions which may be difficult to > debug. Not a major problem, but something to bear in mind. Yes. But since this is added by the sender and not something in the middle many of those concerns (such as ICMP too big not getting through) do not apply. But we should discuss this further in the draft. > [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): > AN EXTENDED PROPOSAL", draft-crocker-mast-protocol-01.txt, > October, 2003. > > ==> I believe this was superseded by CELP. I think they are separate ideas. CELP has the common pool idea, and MAST provided ideas like the deferred context establishment. Erik From owner-multi6@ops.ietf.org Tue Nov 9 15:01:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06176 for ; Tue, 9 Nov 2004 15:01:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRcAI-0006Vk-G1 for multi6-data@psg.com; Tue, 09 Nov 2004 20:00:30 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRcAH-0006VU-Dd for multi6@ops.ietf.org; Tue, 09 Nov 2004 20:00:29 +0000 Received: from d12nrmr1707.megacenter.de.ibm.com (d12nrmr1707.megacenter.de.ibm.com [9.149.167.81]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id iA9K0MxX226700; Tue, 9 Nov 2004 20:00:22 GMT Received: from sihl.zurich.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1707.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA9K0LKk027490; Tue, 9 Nov 2004 21:00:22 +0100 Received: from zurich.ibm.com (sig-9-145-128-99.de.ibm.com [9.145.128.99]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA67576; Tue, 9 Nov 2004 21:00:20 +0100 Message-ID: <419121D2.9070601@zurich.ibm.com> Date: Tue, 09 Nov 2004 21:00:18 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: Pekka Savola , multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents References: <419112EC.3010706@sun.com> In-Reply-To: <419112EC.3010706@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > >> [NSRG] Lear, E., and R. Droms, "What's In A Name: Thoughts from the >> NSRG", draft-irtf-nsrg-report-09.txt (work in progress), >> March 2003. >> >> ==> wasn't this an RFC already? > > > I don't see it - looks like the ID expired. The latest draft was -10, which was approved by the IESG in November 2003, but somehow it has got lost since then. I've just sent a query to the IESG. Brian From owner-multi6@ops.ietf.org Tue Nov 9 15:22:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09206 for ; Tue, 9 Nov 2004 15:22:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRcV8-00091F-LU for multi6-data@psg.com; Tue, 09 Nov 2004 20:22:02 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRcV7-000912-Si for multi6@ops.ietf.org; Tue, 09 Nov 2004 20:22:01 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id EB3AD86AEA; Tue, 9 Nov 2004 15:22:00 -0500 (EST) To: brc@zurich.ibm.com, multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents Cc: jnc@mercury.lcs.mit.edu Message-Id: <20041109202200.EB3AD86AEA@mercury.lcs.mit.edu> Date: Tue, 9 Nov 2004 15:22:00 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Brian E Carpenter > The latest draft was -10, which was approved by the IESG in > November 2003, but somehow it has got lost since then. A significant number of the people in the NSRG were very unhappy with the document, which may explain why it never made it through. Noel From owner-multi6@ops.ietf.org Tue Nov 9 15:40:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10776 for ; Tue, 9 Nov 2004 15:40:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRcmd-000B4h-I5 for multi6-data@psg.com; Tue, 09 Nov 2004 20:40:07 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRcmc-000B43-H8 for multi6@ops.ietf.org; Tue, 09 Nov 2004 20:40:06 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2B3E22D95C; Tue, 9 Nov 2004 21:40:05 +0100 (CET) Received: from [163.117.252.222] (vpn-252-222.uc3m.es [163.117.252.222]) by smtp02.uc3m.es (Postfix) with ESMTP id 8A8752D43D; Tue, 9 Nov 2004 21:40:04 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <88FBF7E3-328F-11D9-8179-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org From: marcelo bagnulo braun Subject: Pekka's comments about HBAs (was Re: Comments on multi6dt documents Date: Tue, 9 Nov 2004 21:40:04 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, thanks for the feedback some replies online El 09/11/2004, a las 1:36, Pekka Savola escribi=F3: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > HBA: > > substantial > ----------- > > I think there are two big issues: > > 1) The spec should have a clear section which describes the=20 > assumptions > placed upon the features which must be supported in the multi6=20 > solution. In > this particular case, for example, the CGA Parameter Data Structure=20 > needs to > be passed to the peers out of band what do you mean by out of band? i mean the CGA_PDS has to be communicates to the other end, but it will=20= be sent in clear through the multi6 protocol. i.e. there is no need to hide the CGA_PDS to obtain the security of HBAs ok? > because otherwise they can't perform > verification. This might help in figuring out how the HBA address > generation integrates to the rest of the multi6 solution problem = space. > I agree that an explanation of how the HBAs could be used in a multi6=20 protocol is needed in the draft. I was thinking to include an example in an appendix > 2) IPR. Unfortunately, SEND had IPR; fortunately, RF licensing was=20= > granted > for implementations of SEND. Someone has to figure out how generic=20 > those > patent applications were, i.e., whether HBA would be covered as well. > Agree, but the chairs suggested to first figure out if HBA are good and=20= then go for the IPR stuff, which imho is a good approach > > editorial > --------- > > 5. HBA verification > > =3D=3D> I spotted about 3 typos in this section, and one helluva long=20= > paragraph > which should be split up. > ok, i will fix this thanks, marcelo From owner-multi6@ops.ietf.org Tue Nov 9 15:50:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11616 for ; Tue, 9 Nov 2004 15:50:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRcwU-000CJ5-Fi for multi6-data@psg.com; Tue, 09 Nov 2004 20:50:18 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRcwT-000CIp-MQ for multi6@ops.ietf.org; Tue, 09 Nov 2004 20:50:17 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 09 Nov 2004 12:50:50 -0800 X-BrightmailFiltered: true Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA9KnpnC008618; Tue, 9 Nov 2004 12:49:51 -0800 (PST) Received: from [130.129.132.199] (sjc-vpn4-305.cisco.com [10.21.81.49]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iA9Kow23029989; Tue, 9 Nov 2004 12:51:00 -0800 Message-ID: <41912D82.2060301@cisco.com> Date: Tue, 09 Nov 2004 15:50:10 -0500 From: Eliot Lear User-Agent: Mozilla Thunderbird 0.8+ (Macintosh/20041030) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Erik Nordmark , Pekka Savola , multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents References: <419112EC.3010706@sun.com> <419121D2.9070601@zurich.ibm.com> In-Reply-To: <419121D2.9070601@zurich.ibm.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1100033461.391664"; x:"432200"; a:"rsa-sha1"; b:"nofws:258"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"dMqS6spyLTp/2as8MIFJgTJU8cg5PRGjMC77gVk1hN8k6wj7MZH6w7FBaXso+" "yfo+KIL0FuAqKOO4zMhSPXHHXcnomk6RUJBUh7hPQAp9PDt5BEyKTrlvqkEGs" "XkUM2AmTSN2Q8W6kyF8vbjaGaHt8PgokKMVWjQskU1hBpf7eo="; c:"Date: Tue, 09 Nov 2004 15:50:10 -0500"; c:"From: Eliot Lear "; c:"Subject: Re: Comments on multi6dt documents" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I killed the NSRG draft. I did so because after three rounds with the RFC Editor over a period of two years I believed the environment had changed sufficiently to require revisiting of existing work. The concepts in the draft remain valid. Eliot From owner-multi6@ops.ietf.org Tue Nov 9 16:38:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15823 for ; Tue, 9 Nov 2004 16:38:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRdfx-000I92-Bv for multi6-data@psg.com; Tue, 09 Nov 2004 21:37:17 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRdfv-000I8m-Rz for multi6@ops.ietf.org; Tue, 09 Nov 2004 21:37:16 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA9LaXrQ296384; Tue, 9 Nov 2004 21:36:33 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA9LaOfK039696; Tue, 9 Nov 2004 21:36:24 GMT Received: from zurich.ibm.com (sig-9-145-254-253.de.ibm.com [9.145.254.253]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id WAA47830; Tue, 9 Nov 2004 22:36:20 +0100 Message-ID: <41913853.1070801@zurich.ibm.com> Date: Tue, 09 Nov 2004 22:36:19 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Arifumi Matsumoto CC: Multi6 Subject: Re: I-D ACTION:draft-arifumi-multi6-sas-policy-dist-00.txt References: <200410211948.PAA12822@ietf.org> <418B7226.4040501@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Arifumi Matsumoto wrote: > Hi Brian, > thank you for comments. > > On 2004/11/05, at 21:29, Brian E Carpenter wrote: > >>> 3.1 Multihome Site with Global-Closed Mixed Connectivity >>> ============== >>> | Internet | >>> ============== >>> | >>> 2001:db8::/32 | 3ffe:1800::/32 >>> +----+-+ +-+----+ >>> | ISP1 | | ISP2 | (Closed Network) >>> +----+-+ +-+----+ >>> | | >>> 2001:db8:a::/48 | | 3ffe:1800:a::/48 >>> (DHCP-PD') ++-------++ (DHCP-PD') >>> | Gateway | >>> +----+----+ >>> | 2001:db8:a:1::/64 >>> | 3ffe:1800:a:1::/64 >>> | (RA'/DHCP') >>> ------+---+---------- >>> | >>> +-+----+ 2001:db8:a:1:[EUI64] >>> | Host | 3ffe:1800:a:1:[EUI64] >>> +------+ >> >> >> >> I'm afraid I don't see why this case is of interest to multi6. >> It is a case where the user site is connected to one ISP and >> to one WGP (walled garden provider). This is not site multihoming >> in the sense of multi6. As far as I can see, a longest match is >> sufficient to tell the host which source prefix to use. > > > Actually longest match isn't sufficient. > If a packet is destined for a closed network, > an appropriate source address is chosen > automatically by longest match. > On the other hand, a packet is destined for > somewhere in the Internet, it is not always > true. For example, when a packet is destined for > 3ffe:1801::1 in the Internet, the source address > will be the one delegated by ISP2(WGP). In the > end, the reply packet for it never returns because > of the wall. Yes, correct. It needs to be a bit more complex than longest match - it's exact match on the /32 for ISP2 and you *will* need a priority policy to achieve that. Walled Gardens are bad things anyway, so I wonder if we should solve this? > > Anyway, I agree that this case may not be the scope > of multi6. > >> >>> 3.2 Host with Multiple Home Addresses and Connectivity to Two Global >>> Networks >> >> >> This is the case of interest to multi6. >> >> ... >> >>> Note that the end nodes are notified of an address-selection policy >>> that includes prefix ::/0 by both ISPs, hence a specific source >>> address for ::/0 can't be determined in the Label-Rule judgment >>> phase described in RFC3484. So, these entries for prefix ::/0 won't >>> actually be stored in the policy table, and this policy table won't >>> have any effect on source-address selection for packets that match >>> ::/0. The source address in these cases will be determined by >>> following rules listed in RFC3484, such as longest match with the >>> destination address. >> >> >> Exactly. And it is this case - when two ISPs both offer connectivity to >> ::/0 - that multi6 has to solve. That seems to be the case you don't >> help with. > > > Though I didn't include them in this version of my I-D, > we are thinking of some other solutions. For those hosts > that can support ECMP(equal cost multi-path) or some > other special mechanisms for multihoming, it would > be helpful to notify all the default routes and all the > SAS Policies for default routes as I mentioned in I-D. Well, I think the multi6 conclusion is that we need active reachability checking anyway. The most that SAS policy can do is decide the order in which reachability is checked. Therefore, I still think that SAS policy is a secondary component for multi6. Brian > For normal hosts, however, it would be better not to > notify multiple routes for the same destination network. > So, it should be configurable on routers not to announce > multiple routes but to choose one. The configuration will > be like prioritizing ISPs. > > It may be useful to define a new DHCP option for Solicit > message that explicitly requests for multiple routes for > the same destination network. > > -- > Arifumi Matsumoto > Ubiquitous Computing Project > NTT Information Sharing Platform Laboratories > E-mail: arifumi@nttv6.net > From owner-multi6@ops.ietf.org Tue Nov 9 17:29:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21621 for ; Tue, 9 Nov 2004 17:29:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CReU8-000OTb-Rw for multi6-data@psg.com; Tue, 09 Nov 2004 22:29:08 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CReU4-000OT9-8s for multi6@ops.ietf.org; Tue, 09 Nov 2004 22:29:07 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iA9MTNQx015912; Tue, 9 Nov 2004 23:29:23 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Comments on multi6dt documents Date: Tue, 9 Nov 2004 23:29:01 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-nov-04, at 1:36, Pekka Savola wrote: > locators registered in the DNS but assumes that both the reverse > tree > and the forward tree are maintained. > ==> s/maintained/maintained in a consistent manner/ -- or the like: > it's not > sufficient to just put some stuff in the reverses or forward trees, > they > must be actively kept in sync. This is an area which is not often the > case.. I think that when it's said that something should be done, it's implied that this should be done correctly. > ==> actually, robust implementations have long since started properly > verifying the ICMP messages. For examples, as > draft-gont-tcpm-icmp-attacks-00.txt describes, you can protect against > ICMP > attacks against TCP by verifying that the ICMP message includes the > correct > port numbers, seq/ack numbers etc., so that only (practically) > on-the-path attacker could have generated them. We can't presume a multi6 implementation has such intimate knowledge of what TCP has been up to. Also, we need to be generic enough that non-TCP and even non-UDP protocols work reasonably well. > Upon > changing to a new address pair, transport layer protocol SHOULD be > notified so that it can perform a slow start. > ==> using 'slow start' might be a bit accurate, because there's not > much > slow in 'slow start' except the name. I think triggering slow start is pretty much all you can do to slow down TCP > Did the draft mean a really slow start, or was aggressive probing OK > as well? The properties of the new path are unknown so basically transports should behave as if the session is new after a rehoming even.t > I.e., this does not discuss whether the set-up could be piggybacked > upon > earlier messages? There's plenty of space in those TCP conn. > establishment > messages, for example.. The trouble is that if you put multihoming stuff between the IP header and the TCP header you may end up being filtered. Also, under most circumstances either the packets you may want to piggyback on are already filling up the MTU, or there aren't any. So the complexity needed for piggybacking is probably not receive a decent return on investment. From owner-multi6@ops.ietf.org Tue Nov 9 17:40:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22914 for ; Tue, 9 Nov 2004 17:40:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CReeb-000Pd9-MC for multi6-data@psg.com; Tue, 09 Nov 2004 22:39:57 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CReea-000Pcu-Jb for multi6@ops.ietf.org; Tue, 09 Nov 2004 22:39:56 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iA9MeCQx016046; Tue, 9 Nov 2004 23:40:12 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <8F20221FB47FD51190AD00508BCF36BA0D458216@znsgy0k3.europe.nortel.com> References: <8F20221FB47FD51190AD00508BCF36BA0D458216@znsgy0k3.europe.nortel.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <43E92096-32A0-11D9-A560-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org'" From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Tue, 9 Nov 2004 23:39:49 +0100 To: "Elwyn Davies" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 9-nov-04, at 14:35, Elwyn Davies wrote: > A problem with all of these schemes is that they have no inherent > means for > informing the multihomed site of a failed path where the failure is > not in a > link directly connected to the link. A major failure in the provider > network or an upstream transit provider can result in outgoing traffic > being > blackholed even though incoming traffic is being rerouted via the > alternative path. We have discussed this extensively in the design team. The obvious solution is to send keepalives all the time. This is what SCTP does and it's very wasteful in bandwidth, and it may have substantial unpleasant side effects. For instance, if I close the lid on my laptop for a minute, I don't want the other side to declare me disconnected and break my SSH session. The non-obvious solution is to suppress keepalives when it's clear that they aren't needed. This can happen in two cases: 1. When there is no traffic in either direction 2. When there is traffic in both directions Only when there is traffic in only one direction there MAY be a failure condition, so keepalives are in order to make sure. This should work very well except that failures may now only be detected by one end. For instance, when A and B communicate and there is only reachability from A to B but not the other way around, A won't detect the failure if B is sending data, because A is both receiving B's data and sending out ACKs. However, B will see data going out but nothing coming back so B notices the potential failure and can trigger reachability testing. From owner-multi6@ops.ietf.org Tue Nov 9 20:59:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10404 for ; Tue, 9 Nov 2004 20:59:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRhk8-000NOL-Ra for multi6-data@psg.com; Wed, 10 Nov 2004 01:57:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRhk7-000NNx-1d for multi6@ops.ietf.org; Wed, 10 Nov 2004 01:57:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAA1vg402643; Wed, 10 Nov 2004 03:57:42 +0200 Date: Wed, 10 Nov 2004 03:57:37 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents In-Reply-To: <419112EC.3010706@sun.com> Message-ID: References: <419112EC.3010706@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,NO_EXPERIENCE autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 9 Nov 2004, Erik Nordmark wrote: > Pekka Savola wrote: >> I read the 5-document set of multi6dt documents. In general, I thought >> they were a very useful start, but there were some inconsistancies across >> documents, and clearly there was not yet time to analyze how the solution >> (or different pieces of solution) correspond to the "thinks-to-think-about" >> document. >> >> This especially seemed to be the case with the shim layer document, which >> might end up having some potentially significant issues. > > Did you see issues in addition to the ones you explicitly listed below? I might have to re-read it again because the ICMP issue was so obvious I started thinking whether some others would also be lurking out there and just deferred that to 'have you checked the things to think about' :) >> ================================== >> Referrals: >> >> substantial >> ----------- >> >> - "Identity" comparison. Some applications might retain the IP >> address, not as a means to initiate communication as in the above >> cases, but as a means to compare whether a peer is the same as >> another peer. While this is insecure in general, it might be >> something which is used e.g., when TLS is used. >> >> ==> I think the document should use a bit of space to discuss (or refer >> to) why identity comparison is insecure in general. This seems to be true >> in the sense that if you have an established secure application identity, >> and you come across a new identity which uses the same IP address in an >> insecured manner, then comparing them might not be sufficient (example: >> IPsec-secured w/ IP=1.1.1.1 session being tampered by a packet with source >> address of IP=1.1.1.1). But if the security levels of comparison are >> equal, >> I don't think there is a real problem. > > It might make sense clarifying this. > If you are using some security, such as IPsec or TLS, then it is true that > the application will have better certainty about the identity of the peer in > many cases, but the identity it has certainty about isn't the IP address but > the identity to which the certificate is bound. > > Stated differently, if I use IP address X in here at the IETF with IKE/IPsec > and my cert, and you later use the same IP address with IKE/IPsec and your > cert, it doesn't mean that the IP address refers to the same identity in the > two cases. With this clarifying example (the temporal element to the address ownership) I think the potential issues this brings up are clearer. Thanks. >> - Even if the bullet above is addressed somehow, the introduction of >> RFC 3041 temporary addresses for improved privacy adds to the >> burden. Today there is no mechanism for a host with temporary >> addresses to create temporary FQDNs that resolve to those >> addresses, and temporary FQDNs are necessary to preserve the >> difficulty of correlating these addresses with more permanent >> identifiers of the host. >> >> ==> this may or may not be true. RFC3041 even mentions DNS names based on >> RFC3041, as long as they are not identifying the real user, and >> draft-ietf-dnsop-ipv6-issues-10.txt discusses this a bit as well. > > Yes, but the hard part is, since the 2^63 number of RFC3041 addresses per > link can't be prepopulated in the DNS, is that they names need to be > *created* in the DNS. With DNSsec we have operational understanding of what > it takes to authorize the *update* or RRs for an existing name, but little or > no experience with the creation of new names. Umm, I don't think DNSSEC (except some basic components it may use) really deals that much on DDNS updates, but the point stands that there has been, AFAIK, relatively little protocol work on adding new records. I'm not sure of the protocol itself, and the more generic case, but I believe the reverse DNS issue could be solved, in the important practical cases, using just an implementation approach. That is, 1) require that the server be located at the same site as the updater (relatively reasonable) 2) that hopefully some amount of address spoofingi protection has been deployed on the site: just uRPF on the subnet basis is sufficient 3) make the hosts add the rfc 3041 reverses directly to the zone, without any security 4) the dns server allows such insertion only if there are no existing records, and the update comes from the IP address corresponding to the reverse record 5) the records don't need to be removed by the hosts, only by a clean-up process by the server Not perfect, there are certainly some corner cases here, but I guess this should be at least sufficient to experiment with DDNS reverse insertions if that was deemed to be useful. > It isn't clear to me if the above document recommends that the DNS servers > sythesize records (which has issues with DNSsec) or something else. If it's important to provide *anything* (to work around broken apps etc.) instead of something particularly useful, a wildcard reverse could be used. Not applicable here, of course. >> I think the more appropriate formulation is that mechanisms do exist, but >> the hosts do not implement these automatically (an implementation issue), >> and even if they did, the DNS zone admins might not allow the required DNS >> updates. > > I suspect it's harder than that. OK, I'll agree that particularly in environments where you are not comfortable with making some perhaps significant assumptions this may have, well, "issues". :) Still, it would seem to be useful to try to experiment with this, but this is a subject for another forum. >> Shim layer: >> >> substantial >> ----------- >> >> The context state in this approach is maintained per remote ULID i.e. >> approximately per peer host, and not at any finer granularity. It >> might make sense to merge the context state for multiple ULIDs >> assigned to the same peer host, but this is for further study. >> >> ==> this spec seems to be silent about demultiplexing of external inputs >> which relate to an existing session, but do not have existing per peer host >> state. Example: ICMP unreachable message sent by a router pertaining to a >> packet sent (and mangled by the shim layer) by the host. These need to be >> dealt with somehow as well. > > Good point. > >> In practice, this would seem to be creating a 1:1 NAT, > > Not quite (and whether using the term "NAT" is helpful is a separate question > - folks associate it with middleboxes that mess with DNS and other stuff). Agree that NAT is a loaded word and better avoided. I used it to refer to the fact that address mapping seems to be required, as well as rather NATty behaviour or looking at the payload and interpreting the content in some manner, and trying to mangle it. > The sender needs to be able to demux a packet it sent based on the first 64 > bytes. How do you derive 64 bytes? For example, doesn't an ICMP error recieved over v6 require at least 40 (ip6) + 8 (icmp6) + 40 (ip6) = 88 bytes at the very least, but additional bits e.g. from the extension headers, possible destination options or whatever. Unless we can make some simplifying assumptions here it seems like bringing up issues described in section 2.1.9 of draft-savola-v6ops-security-overview-03.txt and prior to that in a different draft -- i.e., the nodes must be able interpret and process, or skip over -- all the possible headers out there. >> and requiring to go >> down to the application payloads (e.g., stuff inside the ICMP message) as >> well. This needs to be considered explicitly, and discussed with pros/cons >> prominently. > > But it's part of the endpoint and not a middlebox. That implementations have > code which removes various things the IP layer might have added > (fragmentation headers, destination options, etc) in the transmit path before > passing the packet to TCP for demuxing on the port numbers shouldn't be a big > deal, should it? > Or am I missing something? Just demuxing the packet (and doing reverse mapping if needed) would be one thing, but don't you also have to parse inside the packet and translate that back as well? Then the implementation should have to know which protocols to parse and how, i.e., where the "juicy bits" to look are. >> The approach makes no assumption about the reverse tree since the >> approach does not use it. However, applications might rely on the >> reverse tree whether multi6 is used or not. >> >> ==> across different documents, I think there have been some >> inconsistancies regarding this, e.g., as a means to find new or >> different locators by doing reverse+forward lookups. What's the >> real story here? > > Across which documents? draft-*-multi6dt-* documents? multi6dt, yes. At least that's the impression I recall getting after reading especially the referrals, shim, and functional decomposition. I probably should try to focus more on this the next time I check them. >> 8.1. Initial Context Establishment >> [...] >> When the policy is triggers, which could be on either A or B, an >> initial context establishment takes place. This exchange might >> fail should the peer not support the multi6 protocol. If it >> succeeds it results in both ends receiving the locator sets from >> their respective peer, and the security mechanism provides some >> way to verify these sets. >> >> ==> s/triggers/triggered/ (or something)? >> ==> is it possible / feasible to merge this functionality with steps 1 and >> 2? I.e., this does not discuss whether the set-up could be piggybacked >> upon >> earlier messages? There's plenty of space in those TCP conn. >> establishment >> messages, for example.. > > Good question. Some of the tricky parts of piggybacking (putting two payloads > in the same packet) relates to interaction with IPsec policy especially if > the policy is applied by security gatways. OK. Just an approach to consider; some might consider it important, some not. I haven't really formed an opinion. >> semi-editorial >> -------------- >> >> This document outlines an approach to solving IPv6 multihoming in >> order to stimulate discussion. >> >> ==> sigh.. this must have been written in haste, because there is no chance >> it is going to solve all the problems; just one rather important one (for >> small sites at least) > > But the text at least stimulated discussion :-) That's good :) >> This approach would reduce the overhead. On the other >> hand, this approach would cause changes in the available MTU, since >> packets that include the Extension Header will have an MTU 8 octets >> shorter. >> >> ==> please also remember that in case if the required overhead changes >> (e.g., overhead is only needed in some special cases), it might be that the >> additional overhead triggers failure conditions which may be difficult to >> debug. Not a major problem, but something to bear in mind. > > Yes. > But since this is added by the sender and not something in the middle > many of those concerns (such as ICMP too big not getting through) do not > apply. But we should discuss this further in the draft. Agreed. Protocols such as UDP probably incur fragmentation and TCP just adjusts. >> [MAST] D. Crocker, "MULTIPLE ADDRESS SERVICE FOR TRANSPORT (MAST): >> AN EXTENDED PROPOSAL", draft-crocker-mast-protocol-01.txt, >> October, 2003. >> >> ==> I believe this was superseded by CELP. > > I think they are separate ideas. CELP has the common pool idea, and MAST > provided ideas like the deferred context establishment. Ok, could be; that was just the recollection I had, which was likely wrong because I've read neither in detail. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Nov 9 21:00:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10450 for ; Tue, 9 Nov 2004 21:00:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRhmC-000Ndx-UE for multi6-data@psg.com; Wed, 10 Nov 2004 02:00:00 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRhmB-000NdN-Gj for multi6@ops.ietf.org; Wed, 10 Nov 2004 02:00:00 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAA1xs102667; Wed, 10 Nov 2004 03:59:56 +0200 Date: Wed, 10 Nov 2004 03:59:53 +0200 (EET) From: Pekka Savola To: marcelo bagnulo braun cc: multi6@ops.ietf.org Subject: Re: Pekka's comments about HBAs (was Re: Comments on multi6dt documents In-Reply-To: <88FBF7E3-328F-11D9-8179-000D93ACD0FE@it> Message-ID: References: <88FBF7E3-328F-11D9-8179-000D93ACD0FE@it> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 9 Nov 2004, marcelo bagnulo braun wrote: >> I think there are two big issues: >> >> 1) The spec should have a clear section which describes the >> assumptions placed upon the features which must be supported in the >> multi6 solution. In this particular case, for example, the CGA >> Parameter Data Structure needs to be passed to the peers out of >> band > > what do you mean by out of band? > > i mean the CGA_PDS has to be communicates to the other end, but it > will be sent in clear through the multi6 protocol. i.e. there is no > need to hide the CGA_PDS to obtain the security of HBAs > > ok? That's OK. I just meant out of band in the sense that how it's done is probably external to the HBA protocol itself, it just needs to be shared with some mechanism. >> 2) IPR. Unfortunately, SEND had IPR; fortunately, RF licensing >> was granted for implementations of SEND. Someone has to figure out >> how generic those patent applications were, i.e., whether HBA would >> be covered as well. > > Agree, but the chairs suggested to first figure out if HBA are good and then > go for the IPR stuff, which imho is a good approach Agree that this is probably a good pragmatic approach. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Tue Nov 9 21:15:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11459 for ; Tue, 9 Nov 2004 21:15:01 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRi0O-000Pno-3l for multi6-data@psg.com; Wed, 10 Nov 2004 02:14:40 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRi0M-000PnT-QY for multi6@ops.ietf.org; Wed, 10 Nov 2004 02:14:39 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAA2EWL03195; Wed, 10 Nov 2004 04:14:32 +0200 Date: Wed, 10 Nov 2004 04:14:32 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Tue, 9 Nov 2004, Iljitsch van Beijnum wrote: > On 9-nov-04, at 1:36, Pekka Savola wrote: >> locators registered in the DNS but assumes that both the reverse tree >> and the forward tree are maintained. > >> ==> s/maintained/maintained in a consistent manner/ -- or the like: it's >> not >> sufficient to just put some stuff in the reverses or forward trees, they >> must be actively kept in sync. This is an area which is not often the >> case.. > > I think that when it's said that something should be done, it's implied that > this should be done correctly. The implication may be done, but one can still correctly argue that one can maintain forward and reverse tree in a manner that those don't match, as long as there are some records in either :). Actually, operaionally, I'd guess this is a relatively big challenge. >> ==> actually, robust implementations have long since started >> properly verifying the ICMP messages. For examples, as >> draft-gont-tcpm-icmp-attacks-00.txt describes, you can protect >> against ICMP attacks against TCP by verifying that the ICMP message >> includes the correct port numbers, seq/ack numbers etc., so that >> only (practically) on-the-path attacker could have generated them. > > We can't presume a multi6 implementation has such intimate knowledge > of what TCP has been up to. Also, we need to be generic enough that > non-TCP and even non-UDP protocols work reasonably well. So, I guess this depends on where this failure detection code resides with regard to the ICMP message reception and parsing. >> Did the draft mean a really slow start, or was aggressive probing OK as >> well? > > The properties of the new path are unknown so basically transports should > behave as if the session is new after a rehoming even.t That's OK; put that justification to the draft alongside of the mention of slow start. >> I.e., this does not discuss whether the set-up could be piggybacked upon >> earlier messages? There's plenty of space in those TCP conn. >> establishment >> messages, for example.. > > The trouble is that if you put multihoming stuff between the IP header and > the TCP header you may end up being filtered. Unfortunately, a very real possibility. The tradeoff needs to be written down, of course > Also, under most circumstances > either the packets you may want to piggyback on are already filling up the > MTU, or there aren't any. So the complexity needed for piggybacking is > probably not receive a decent return on investment. Unless you piggyback on the TCP connection establishment messages which are known to be small enough to accommodate this. That's the only realistic case for piggybacking benefits AFAICS. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Wed Nov 10 03:54:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11180 for ; Wed, 10 Nov 2004 03:54:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRoB7-000FOh-13 for multi6-data@psg.com; Wed, 10 Nov 2004 08:50:09 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRoAw-000FJi-9T for multi6@ops.ietf.org; Wed, 10 Nov 2004 08:49:58 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAA8oEQx023322; Wed, 10 Nov 2004 09:50:15 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7D55F788-32F5-11D9-A560-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: Comments on multi6dt documents Date: Wed, 10 Nov 2004 09:49:53 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10-nov-04, at 3:14, Pekka Savola wrote: >> Also, under most circumstances either the packets you may want to >> piggyback on are already filling up the MTU, or there aren't any. So >> the complexity needed for piggybacking is probably not receive a >> decent return on investment. > Unless you piggyback on the TCP connection establishment messages > which are known to be small enough to accommodate this. That's the > only realistic case for piggybacking benefits AFAICS. This is especially the place where filtering would be most harmful, because you don't know whether lack of a response means you should retry without the multihoming header, or you should try a different address. But I do agree there are advantages as well. If you want to set up security stuff that is susceptible to sniffing attacks, the first packet is the place you want to do it because an attacker with just sniffing capability can't inject a false packet for a legitimate new session, because the properties of new sessions aren't known until the first packet is transmitted. From owner-multi6@ops.ietf.org Wed Nov 10 05:03:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17517 for ; Wed, 10 Nov 2004 05:03:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRpJc-000NYq-1i for multi6-data@psg.com; Wed, 10 Nov 2004 10:03:00 +0000 Received: from [200.180.242.22] (helo=PENTIUM4.org) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CRpJV-000NXm-Tl for multi6@ops.ietf.org; Wed, 10 Nov 2004 10:02:59 +0000 Date: Wed, 10 Nov 2004 08:02:44 -0300 To: "Multi" From: "Smd" Subject: Re: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------cunublyejkhgapuuibet" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Level: *** X-Spam-Status: No, hits=3.4 required=5.0 tests=AWL,BAYES_60, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk ----------cunublyejkhgapuuibet Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit >The snake


:)

----------cunublyejkhgapuuibet Content-Type: image/gif; name="samjiiogya.gif" Content-Disposition: attachment; filename="samjiiogya.gif" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhPwAPAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A /wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M mf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAAA/AA8AAAjwAP8JHEiwoMGD CBMqXMiwocOHECNKnOgwGxlE2gZOQ0Qmm0ZEajwSrEVmoDZXZFxto5iQGiJ/Lqn9s6jNokeU /v4hkimwFiJEAx1p84dIJEuD0kr+I0Pr30aBiFwVJKM0KseeQI8q/AkV6NWlWQVuQ9SqJ1iB rcJqPXhRYFuuOpUKpIWR4NeUPqetNdg27tm//3zWmpqVo7+xg/cO7Pu2alaiZQlDVdpX8T9p Wcno9elW79JZB+HSFehIrmKaLj1qw9ivrkV8bLO6zNjR8se6AjfW/qfoJ0e1X2f+zGi7uHHC vqn+vPg7eXLlzZczdxgQADtb/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9/ /3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr/3//fyArICv/fyArICv/f/9/ICsgK/9/ /3//f/9//HcgK2lD/3//f7Fb/38gKyAr/3//f2lDICv/f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f49TICv/f/9/ ICuPU/9/j1MgK/9//38gK49T/3//f/9//3//fyArICv/f/9/ICuPUyArICv/f/9/s18gK/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9/ /3//f/9//3//f/9/tmcgK9hv2G8gK7Zn/3+2ZyAr2G/YbyArtmf/f41LICv9e/17ICu0Y/9/ /3/9e7FbICsgK/9//3/8dyAr2G/9eyArs1//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f7RjICsgK7Rj/3//f/9/tGMgKyAr tGP/f/9//XuPUyArICu0Y/9//3//f/9//3+zXyAr/3//f/9/2m+NSyArjUv9e/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA ----------cunublyejkhgapuuibet Content-Type: application/octet-stream; name="Doll.zip" Content-Disposition: attachment; filename="Doll.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIACA9ajHqnwGGomMAAJ9fAAALAAAAc2hrbHV4ai5leGVuG4PearEd4kiARmic 2izsOO5Nls5FuFmqiBeuML4EdrOd/rKPvqlAyFdL1D6M17E0AQ5xTzsCTGYFsFqw4xCKK1k6 OcDPqDliR8PlLwhjOdLWrUE4EfHSih9j6uU3ryrma7KPGi30g/lnSmwGz3AyOFaLk0sv/yhb 0cASn26w0SstvCXwdMrArYQ5RPMVUOaHpEzjb7Uq6YXXYljl7FG89EkHzagvrn4IyW0enSGs 7FfGos8/bOqN0d4ZSCZ3RiabQZY8OT6i8azVr7Kn58oz72x/1ug0HNeJ2tuySbY44rn2N1V8 mVPQgmVKfzcs1WkbAXDJgtA67b5A5Ir7k5mIVvD9AyBSnwDgY7AlnKJPuLcaCVooR9AuKpEJ 1MTTrx3w1zIzlPa4lMXnmLnYew8pmRq1yHT4EJYacsKyhOeLi7QkYMKDldw7HI+egIkrXKP4 Tyd0FGv4UjgrZ/XcJFLurhLsGujFvL3rQ41rewIMDzoqu8h9SgXQbLL22T7BChsU5igB1FKQ L+L+5DyUKQlU/hcg0n3kkRw5w6zfT6ePsFJttUwN6RbZh68SHHHSSt2NtaJjZiYxBdzkD8+7 UOuVhI6fqFhEmByKNhqgMR0SgyFPWlq7coFyF6H7ptRMzAkeun1URRGw3fQYerdmtN778For 2wkD47rHOJRUzGkiVnQZWZ0bIRNViVJqYi2tg9hS2KbBbrXdCdJ5yHJPLgvSb7vmyS2Ohiaz tBPozJguN1SAoy1TIwkYCD2X5K4BE3lMxNKmJHH6tTp98JhGQqLpNvFPXCRJLAF31NVNRPlu rvKm1ueUNiIio4QgejdubouBmS9sORDFayswZ6Wygpst3zilNOkXCZOuggm05g2CpTF8FfZk +bZTzGwEctyW1X930E5qJIZbFZvoG0dQawQb/E1qcApUzunnNfu20bNMmz5WL2RrqVATQGbu TrCB+T7h9RbyRZc4MJecJYtXiUkQhn9bvwUGx0BKJ9zmSK61my1a9VBGaPPbGs7WiW+4qPAn V8dFzezWcd3eaBKHBmynUKlUylrzTJrZqb/e7JtmsazE6cNcQfMrd6P/XMj1ZUgreqPAR+Vt fg1VYhfm61dbxHunffBOhDYq7TzurENQv6dZw/GUaf+/fVCVRJaVcVeEaS5qlI5mie5WGDsJ nj5P56A0v8gLk5U0VHdJ+h4McXBrl4LqTobwDijWUYj8pOZNcHqa+lwkiHtOOOv7oSvhkZwA FZgh4D6a/ZIg88pjSuAsSlD8iFYbWoSh36LNUqQcH66qIewhFdJRNdDucjw3gl7MWtTWW05P jPBiwz/eGLNe86ajYIanOHolueeeMuBAQHCPxzRDqOBxUj6kJOAgiTkXSF8wmlfk5WVR9L6C ZdsKtSWHGSjyzAu3X5tEQScuys0cUCNwLILak8pXDb4UWfMfDravRANKLVxN9A2OqIXrfbPH 3OaXjGkbLpRIUJ2vhbZ8vCzr6I8JOoks0yv5Z3SanVxRujQW9AwhDt290wlQLgMSMDC9wcXG 8N1UL4s8M1lPvop1ructuYbTgUQWpkdyMgetARmOi/CHkmqiAKei8BOiBCYNPOT3UsdhXs+B rBYmOeeU1UWpepNlM224AmuBR2updO2esuDPvLBQXlPVfoEQKjb7iSorArQRRaLtwmVSUWPl EgVMFAMNb693N2cIY5WOnOevdH3Wv9NrBCtQUnugiwjJQ8nxEuB5rDr2SK568Ldjw2pIMA5J t1fwU+YpcJhvKg09yZ6fgnrmocppuulTQK+0Vv6Gy5S3aA1QZm5FjS5pTDAdPxHxwFZGCAVD iXZkQ4JzZD2FGM1y37FqxbNLVOpyGNEp5s7fVh4W8RO5wbAVsaxRegAYV/iMTnzTUNkxg3EN XZI2IkuDhg7igqZq98OG2LAlUh4zUWe7heRfGf9njcZiC2XWt0vHf1izL3B/tvgSefYbRNwD gd3zkUn9Hfffb6HtkNzFk2mid3sjd/UreXbPek1EWXIXQy9qt/5bSLfBlXW1YYZQFyAOZf8Q UUzqI2Cq4yFoQnV5oj3JtyK4S80X+G+weflNUUowiFJazBFnGhlgpxKBk2kjeeCxE/zPcXar VEyBh4yU/iVmfBJTwYcbA3Tyfsfm+5RR23m4OA/+HyFn7lU1QLo8pCc9w6GuIor4JDEvAsGn 0ThRDUjX+37qvlWzvbwzvEtXU7yjt9ZfZ/V4FwAtBglB4nfP7xDDHzYg8Ltx9nvNhxuDIp4o 64EvWdo2WUVZWl2SVsEgBZk2fERHlWtci+/mWUrxP2v2FYznVJ8tPSgm8guhranyAih2tu0A q21dpbglvpnXeog2gdq88UtQ/klKnW3rgMNqeko9MJNaDcYIdSRudZrCHSQX55+rhl/od/2r ZcEE5ZIJWsH40OCPeh8cERYQAAzFC7lwgGmEE/k61+4a0OpSJRDn5mUGsFtRLfMkOZgfULJ5 o1g0v7+lHUhh2TtBNIaJXNpihHmYJe0XsuOUGoCE6eqqr3KEcqjOBakbR2T+MZAIOw75x9zs ODHsTjVi3wZF1c76teuv2guTS0ViulK0lBBVXvYsKRENaQGEJYe2/9xTZe9KZL894aOAfSy2 O4+qjnokc/ym9JRux/vGMQYf3mlUfBWWcStNhMs1WIKDSZI/frpzW7NMa/F7T5znBPaYAZOm f9xt0qkKR+gRuvhn9vJqYktTuESjpQttIIi3dVhe6V8BxaGLyjYtPRnym0nfhjWy6PPumaxy ZCcdJQJIN8Vn4LRc5tT59YejM0EXtfmusPd9Z9N6eIA0hu1LGz8OE/4qrStWOgZMaPeJxHf1 N9dF9Sl4wdfYrY46kP0x2RIbAw0JK5vcZSrozmadYnQ/eVs7CACsPVXgn0ZZerweV8bxScVm z53fYA/mHI4y7sdJmlTRuT3un4Gt+R7TeTUujrtSRPqZBfpFWWPv2iPA1GMThQKrPuefm/Ih tNkoT7qvvbP7rv8j5nfKi8iKw/PCeEE+fhmt0JUDPQG8rz8khwMkLnRLZxI6sx0uirXHgBTC IXU0gUTwcozQ/V0xQV60o7AOPKHi5kEXKYAKo6GnJ9CfG/K1ddVYT/7qFFYQWUQojxVcdy8w SR5DAEcJPVrXuO1nTyVb9/h449j+4+xMEpTxyihljZDTbhktjsntLCynyfr0m4Ww3/c9pXa/ A/wAi8TT+B9MvWl2pm8ss/sAQw6W3aTotvbVaW50vmenJx7sqGhPVwAMm440BrFTa2+x+Mi5 J4NUVDHy8dgUa/a2m03wxqrw7pEvxkmdn6H3q0nfDJdUw8Y5ur3EKHpOOD3g4hvM6JI+lMUz QR2UqmA1hpoCrLP7+76xHOqOlTim8dZ2fpWQjYRcVZQELUsDwfPJkQFC4PX8ZwyxAIQatshg j92tZsLAmEEhb/N3m5Yq31PCZHM8W6k9nNC7We3gkQwDdqOYj8exNBxozx8nNlmqV/3qXQ2I ClMNqd8HJ9bF/2wHBLIlaG+72Slk3IkBR9ugILkRTj0GDwIIPUDvfB1/jfEHTQr08lgkOqXM 50Xg4u2BcKU1vW+SFiHtGVIuQ47rRITzfnrnEbsOCAid8QKrSaAxAVZRvZaWbdo0E4FbCY6C 7q9BNeyyz0qhPYiru+A5W5EVVDoE0sOrRwZv2Z0x0dLO7exsBhaucXfzVhihEQVpmMpKiSuK 2ftiOOIb4iCMzzoMPn7dC4HciQTv2boCw25ipI77qullqJgDpTkclaW+fPEupmHsXElVSMDj GmGAuxpGnmLtiM7xZnVfOOPjxkoJrt4kCmzquxYDteCLE9aDW8TzMqX0RXrFtwWRTYFjQy3C fZ7FZTlWD+OeF/ADuQeAh+yi74TenhoVYXHyCOHjo1O9aAHTZR9VFijMzl5qO90pKlhK9p32 +43PQxtC5pyJtAIBhO28PjBjXbgyiOt2rrFvMrXRm68zMjBhUTQSmDEmxRMLVHpAckIkm3gJ mpJbS7IGeW8gtNECu8xC1XDmeGeLkqIMHKdHHCD01dLDvd/3oLXoBUxV4cdPFQfmjglSrXbt 5DeuKxM597g9zzuGaeJCa1ogKe9SF8XorubrX4bw2DsuoozNSQXQj8xQ4b6xXbC9KCauWYyv 3Fc3YMuAFbO0wtZMza4JU0f0MyQaB/mXq4P26lrWc8eeL3S5gnqIQ/T4MH4tTCblfEeUaeQo Ikz4GGg/zYTaTHFxV7dmhkjJYByVQQQ42UQAINR7YjpEagjfiEPkUCBpoiFDI/VEzqBByKfQ t679BGRMSLndN/eMuI4A8lzQyHwE9XSM8eb4OD3wW70Nzfo7Mu/3OQnPW9wwJTLzRxxo5k6O iNTmcfCEYbCAETzaay9mqkOBvUkolBuv18lkZQVstpYR+q2hkvpRpL4J0jBjKWc3cZfUFLRt XRv88n148CQf0Vznpuhan45JDnE3gor54+bD/GPa4TE2QchKMrp5n4wLBa8gApaCylDMhYGJ MeHIBHfSy20sdIvsmJuNvRy/zmxzQJjsE7WEj5OJo28pfUyhcwSomETmOfTpOp+uzcm8Y2UO PIQC9qZ/U266rfVBxAlf0/S0RlslNLMKrC8JLoJ8NvnNJCrlkAP2f9K5Bt7wVLwjpZO8Vq2D ehhDpMq7v/+tJGzDBSpUTcyNqdoCkZ4DO/ldA2Wb71dalZJZK1CZchilWLQ42HGkNEJMRyZG WBRgvc8MA+SaMPkqo3IfLECPK5UZRlM2dHbdFUK1KbSzQYH1EECxWeWD3ear63gXajzhV2/i RDMk6E5pHRGYU+doAX9AYXsJcXDsUlkIOkl0uwR/QiR8A/RE6zeLkVeB+mZFffA9AUSi3UPw fNLp2Oa8Nqy2i73d2x/pB3od4iyG3dXAzUWbv2aNtctzda99AlcSKXhwNhSzCoRefk52ikrg fz5qV78tGBflLTZZ/Y0vlyeVZQvQEMEobRFsZmLiDbdtEjefDrdSMLEJgJnwDnPthc3K88mp UFp3O4X4J2B5k+GMh76Gb0cNl8s4zOjqu2a3AM4dzzeeozx9bkbI+TFgiFVTl7DMxSTfgawB UGM50FyVIpSyyViDovDcvDo8o8oFdDhJivVGNfNK7NKFfo4CkRJP3U1vIdDHVgIML3wYIOBX bfiLreOuT1Dvfjtuo3rcE5TadJ6qLqv61Jyz0mOIqtd1Q9R5IjiuaoPu310scpsuEM5jP9cD X3uqv4/3HDXU0zF0Mtl/K4dosfLcX3gNCT3+DZ8lsUAWPw6sWFSqh2y1A95bwIqAD4+cmFBh qfPa5/8mPjuA+PsEMIyUD46zcB2IUyKHWRuGQ0kjXYSVvbH/hoCjB0Z3OcLRk1SvASBAe5RN 6cXICg/oJk/ReTWYhlC3blJj7FV2u2FPBuZQ9A6cbGNLLLzdb0HgG9Kmx7qlzfTN0ocm9psk KuQ3wXcVGck0SBR/OauLH/b65BKgaAnSgEPVvofAK3Gn0xhhK3ZP6VV3UaALZh+tj+cKxKwM et23CbER5J+IFyCWSwiITSdwwojCbN27T1xiqeFXwMGxCXSymAU4CpnXrUe5BVjdYwTwvls1 u37T10h4SK4em1HbukZQBy54HeRS8ibCxABuOujkFF8gePj702/TJNULOoaSnNY9rfqAEh6g eMmC3HUfogeGbVrPYeY2bc3N+X0glinPWtvpJc/8Rs1mZS/AEGbww1747SiTl5N62IO4i5mh Qi3DbLkd+nLgOap5QEEtx5uuY56QM4nTcOSeKqA89QO94oIup2gwvKY8bT8IuWmLv8IFSsvp FnFphlb4iKDK02JbEGGSWvwaEBxSDtGFwXpVETxr7anGC3X9BL86e29n/VPcV7IDFAEmCYDp 8XnuU5NKIv3nBrV9xqT+DsnhMz4SKjayw78dGf980er7j+0EoZCVAJhShvmdKlWMqVe2FDDx xfGk0QvR68AvG3JKfUYO0sWvTj2MO8ggDUvinhYTGT5Qrj4AyXHO8k6ZKOs21G25y7tHAC8z TlT8ysev7MoaThZJdC4l4248QD5J4fGXq+N56KJplzbYIjE6qypYpoDMHv+/ZdayRpkBEay4 ZmJWb3HiLMfXNjIrBDo2jgC1+bhPO/Xd0FK5NNmzCOFddoFVjTtSD3dWCvpjfmS9eJEeGDnh /2If/AVCf8QpTZ4y26Nh9G/PMKNvZPR6/FlEzjsi1Ob9QALpnnzbPWyqJor5rF8QBcGmD12e Ti+WjHD/1I62jHOoJG7LpvobIA6+ykTVQbcJmz1X9Wlo2ak4TEZMYMEV5B0SiZQBs7VZU1bH x2rLhH79YUA0Akn6UfJ8AqcAPjodfcHru+aBxbZlgj45Podvwdq2b8LBLOu8fRZIBphBU+vD tDbjYKNs1za4AeSmZTb58/IBUgJdMZ5X6cUGibMABZP4ogyFZbviooETcmEaF2KU6fD2kC4s oT4o8cPJTkPkWFrtqnUVYb60oHKBbHW53Y1//dsWNmy+0t/vY/+U6Nppbidi4b2TIyL3FeLA NCw89mfA4DANLtjX2v8iWvSBzYbQZTJ4sClZhQ1edUDpyTAg748eowzUOI4iFhP3ub6YUg9e pNGmocxdvYOb0OJY8DyDOYWrrhu8qSClSaek5DKk3VGNpVqI2Y/5/lXLQRsKDfUEGjr4bPZ6 aS3L4uQL4PJbHlByT2c8tlEIrgGUscHyOnuPUO36YYXsrblqPnPmkMWRa4CG0+WH+mKnPDE+ 0mNjVfWHq/1Vmkq5yGCmcWaU9DSVE+F4jm1b1Fozsi8H3o9L9KYm/Vm5Ip8nbjMZz2qL4C9G KMvC8RsFsZBsXaq/eEaPXEqHkg2bmO6qwYsb46jHSrQj5D6dCTv9NiOAsgz0C/4THbHlTjyu vdONvp5JjzacDYFNBOZWLkmW4fVZ/dfSRlMxohMHa5kenDSjthvck+477vzV8A9wP29bwBDU 3HnwP+aXuaRTpJn+q3E2o/0D0C8DaSf3b2lHpV7ZJkyys3NpV9XQUYWRbyj+GXMfryXgsaeU ofbKMdnrR5OtV0Jmh8i8pYhVv1MMdEEt86/+IIkWEZXjCuleaYUzpEsC2DObShajSMQiXi6Z radOxP+ZTvK9x/8kaok7/F5pYE3+z6BeZxNsMwGqtgb5yii3icwszqFfzpXuRJC5bi5PsvNN 5dq3rrAEG2tYme7ppc3mwozo8Ll/1tyB1y5V02kKnrmXADdEpySCar1hLv0BzeypTQV/ICVs gXxSvOjQLpETJ+JHmyFDpEvinPQJQYOIuxIWYA8hSUcmTeqXtTzUNFVTuOVlmuIdHO4UjTuH /Al/kB0/VuRY0RfPXM1FEfsrnL9i/yXkoCeHJNH7hbJl3PyVmv6nRhGoDce0cLjs/Zt6UXRW Wv6Ropp22SuHDOQ6U+OM4KiVQUivXPME4eA+h3g7SBKoGpTyfI87HKK2BYOtYpE3z7jE/FRL iOys5gM7PLZVTgDdtgh1M1S1G8ixq4FMbZdxqQFO+NjkrZ0VB9mfcIIzlsm2Um8qfw0UPwMj 42+YLlmnhDogf2W17Ac32gEBCYJ1oxLI//KmHbrM6ZEEvwTsdMpGV7fUk8zrAWCXZoRn/bhG ou6Y2umGgPsc/ynUKRhoe3fAQF68s/3bzqo3SBOspelLpkfdxRKhi4pifWslotg8Vh2QPHe4 y4AtvtyD8KCVNnxb5m57WpvsubSGUT2JXXtOoINY/zyfBxc9F6AYUuA/RFZbWysRn4skqceu 9hm7lZgFi0FCFDuykStR/w6n0D81uH/+ujLNMfOXnORMmTbrciRLGGpV8f2I6GOhKuVhhY9F gnTTn1IKE0/X+fkwFYSxRA9PWslnXRvKh/KmyFuExMj6mFad+YXWIZLzqEc8i40jkMwuBVH3 lnLDQXg7Gb7QFcgl8IxDPuAwzHJbkTTTIegJtrR/qgWmF26nj38Zv15pCMg3eMYXjRJ3mbqy SP/664euxCyOQOeiN91hetPPQu+BRmbBMz/b2IPp+smiRx4H4ijym4wtipljwfowESlLmy+N U240bADyj6+L0NGcUIHSVE5RI/edmHZBjAfw5coxOk87ACefDdU0UUxhvWHXeJsWsMhcTHBj rymNMY2Jr4s11UM3vLZmGa49fSt7XAlH5OkqlBXywRN3ANsv0v0DScOFxeyEHTlyY0LhNst3 yQmo1NZd1KAQ+VA/6HdMyXmy+GLignXF8Uy3b4aEpjPtIph1K44gZAsdRRgxhrFXPxPUrT0P TSOll0t43nwFo8SdX8QBSgOi8PP+e3oaw22mXiVUAyFZNCySMobdHX7rPa3++ILJ1PVM8mUV oFanT4nskGzrF4732itCfML9TDj9DCbEMTw8ZyMDRnAxy1Z+qPToMdMsOl6Ml7cY2Diq29cN glosT0cBnG6m5x8XS2qCQAk8UvG3GrLeoEx6xfcxlLpmir1KnNBl7FERJo0KyMz8pDCuC5o4 LeS0lndi9ZypbFKy4/gXAme5CQmNE6EseOhtyJppY7MO5uAp1tTUjE5WH/qmGOQwrWfFs69x HyosQHtITNESSZDbODCei6+Tv8pv0Qe+HUNUU8tWbAsql8VCWVxfnVP5rYXxRjKKcbE8xbYH wUj9xYklTnibUfE51QVzoddDJfYgdni8z8FYoVPH11h4dy4DPLvYu+BbgshH8/gdX4OzeC7g yHGQaiEv5pi6D9MPXVLiOGWzQMf6yJBwNIXza1vB1vARzaplDolkMIO4dIjPOVXijEUtHodm EFA7XiuwwG9Gb9ZCm1+I7vV1Uz2X31yCg/6G8JIs0GZMFUGjN/61i21V5jeTS3NNbcXfdnGd RkU0cjQTFS/HcNk1q0tbyYpzBPHL1ZXppxYifklhvCdffypNXOXxDFseEp/GIzIL0XjJyKnw Ha661YZGx5rv7W6TucCtWKKN6oEiczFL1nCpl6tms324zEz5RUfRTNFwMGEYqu0d01JwRfUE ptlUAxCYqALJAzWJMGIrfmCBXE/5bURLpsR02fTXE4trmAfWGL4DjZGYcJjHrukIHHH4Vs39 eMtKGGjpwt967IVbZHIHDw+0IDzfNkrhcXAK2eO/iC/2Pn9F10rNOjkgGrDh+Y7R0Jj1e1Rs 7/P/nGIocipaFjAgP8Tmx+2I5XOMjnc/xyNU2CG2SXY7aIc4O2PYkiiFu2yLQpRwJZbAhr1E TkASNfVIP3gGCuD49n72mQKPnzGQAgnQTjVeYVeCS4CZkBY2a4KsxHSn/W01Y2wR/KwzCteS KVZ9JxCU/pbe7lzvUCvvxhiaHrUTKagS0goPDTgsgW3DJNarklOLRQSqJF9YrbM6uNwyJMM1 c/WQo1/0f2cbf1uGKZDI+BqZQmDSO591e+Metl27NbuiPlBxQNcHfLws+mkU1rJyhm/khW6X T0Am3OUDTdEEy5J9Kd20sBqotet7D3hq0BGqjsFPnT7MiEkXtG341qeRSqINcPRM9mVQmiMV Bc7sKucb2Z+BmlFAXc0COzdwFlNl7XOBJiCW1hZ4wTn+BkXdICOjs4Eh7IE34chm35CFVMoA XfT0WwCiEAcF1O7JJEx2pY5t6AhKLBsLCOhCLr0ieeOCxdyCsSfQNImEfWQUGblYSlKbqVPY wQ0zOgqElo9xn2m6ySYkhKrzOEIyYgzZUzFTmTuFeD8Pot2Z4Nm5swraS8FamF+tWkGceyAO TmEIeNZjzNwYyNvFWpZUenp9zyE9Wwuz3LLUa29CYkZVjHS1xzJ58T7RvdPtdE9opIwpHsPW SIoO3vU4nHuhYmbb/fDvpYywUSkredHsXfQroILRyLHw8iA7R4pDpDcW7ur2BApJ03zV62E7 8Caob0Ynut3yJEkbl+PLTNhT6aYXvYclIdBn0rZJNAf8sbXbV7d4xfBGpN1ZfKM1UxJOKyCI 8m9/1sYbf7B7JHfU+IhjXrqOhXFcveeGG6vdXCtxwJPPTjdirD7cL1mJQnwBQqo2LWvn8mMR yqN3YTlvCJ/jaHzN0vy1ShrnKwcVJTjfaUzctryQoijFBZiCogSWDnf0jx3gx/Tvvd//cqHt cxryfuMlj/jQUgIwiwUS6zgpztfv9HmjGG+Gw32f3SB6LreUlr8b8p5xUA2ImAUmRxg8d0oG LEuCbfjzZLdcsxA4wBChcvxA8zkWeDO6A1+ihn1LFe0q0Kx2FCdU/UgYA7or/xUpMau5I1ZK kN3K7gg8f2cZG0Ja5/moimA+KzLVZ2bvws1AjXeMcABmvZFgkUoqhO++bkABbx3qnTN5Zvp2 Yz5JBgMiikUuso08Idrj23/iHtgHv5Qf5jL8xnKZnLSq78UgvNNygE12yopntJzMfdxHl4nj sTDNcWM4IrnMY+yDdJxCcbpm3VrXT38/YcKrQIGXo6kozfVvlvs94ghS0460GBDCmasT8JnH nqNl6tffDOe3weBOHDaIkaR2gchfDSHFCAAD1FwCpy6TieRKL5MjcT5tk9UXt0RXH5EbLQQD EFVcqE6aBkbaiWW6e524kzP/MaUSmH381pFcFWteFmDawkW5HwEwc9SxcEZKZ8S1panZZbfx mAmjEZGp2L5TTWP9JH506b1Kq1gAA7NoR55Urqty14BWOqSDjNtPFlxLHrGJYyCT5XMYOAx6 fRQxninJPwoRY4Zi92/U6OHbCTtKHBlx9dKp+/qedXW79R8IxKgPjChEvEz54s7GZsPbl7w9 D/YDIMv3l8eHxwdvYQvUoOqzpMFZh+2HUtlTKQ2SdMy68AELzt3MMwzNkqjbsWhgWJ6bbyLl 8JmPzKgZQx1zcDcj616E+IBrBEALkv18rQCE16PVoyESiviNCgTVfvyl0MmPY/twWIOF3m4v HuDgKLdPD1S4dsZkPDM6QWBGlzvbJWjyXUIc8QS5Gnq/HfaKkDwsMbcLyo/nfvH1VTtLNQDI 6Z6ahppsxBt4/Kt81015Avcxb6JIHrXDrqMJY8S7YkHErJH+AoVwdFyoD7bg9SouVrDiX82K ZJ6lqFqc2JiVl4d9B9mkAJeH7kntElWYlPuLgSXtHADnJg2iBvR16Ze27O46nAwvNumXDCfY 8cfMing+yFsMuC0iNHVopL10q2qg27AlzPd1PmCAiG9s82Xrvr5Gm56vkMzhnh9EgQ8cSK6t ukrpNrZrS9Z9B8mQM1G49AcPGrw9YvLntybcvOTyw7xrX/XDr6C1VZLW1rrB7rkXXjWni/eg GpKCLA4n+Zb/F0Nkue1K9JeiXcY7dZiXZi+AuR+8HpDmbagnUSYQmX6vWOYDtjQq3d0omoqu QEWwqehrJ0OLuuVGVCqZmuuVxQC9jH+sMmJnqt/NUTusR4bfRxZni4IXmkhLNRx3o34iN40I UMakQAUoHzsDroc2chq1mItB+1smSGK6RXig8Fdu9bKP0Q1x+KKqqhdcGxRoqHQJd8r1CGi4 aGP20SLOBVum+vGXRcmbc6W17Ba5ftKCaxFS5IQxcGbunyraHzCqiscyl0N2K9e5Nh3J6ooN gLQ1mb4qT1SP/Rjiuq/CdDcTJNPDypq2nPVouyTb29HFrIJHVIlYoxCXiHehaAolAZGUm7uq hk3fKrX1jIQ/qSAuotSeLXONUwCtjn7V3PzEXw6ewr6t+Y3kj0w37clGjm2Kr6ZG4hkpGZkn nYRpIvMNHKfflzpx8vlz0Dbn92BGjgEgTkDAiMVf0Q/EwLuCA//lou66hTw1mXrwAE5FK9cG GIxQi+bOwKU1D9gK5P8VmsQg5t/jmhhCvxPwhg2CEmX3F+/Kfcp99ctdox10UJiXrVbhwkvf UMWR6ER6eXiEwOUuL4fcR5FsmsIsNIs2KPQ8icAwUaGhSc/A0mJAsd8zL+VZ5sgW2vbknqFM Osq1TjTRKYpIIKnSzOPz79QhqCe5xDUq7BI40eAJHGlU+WjV5qnstFdofSbm1IfP3f5JB2ez 9SPxbRXglWV3KmmOzEN9RM9BXXX8gE7u7wzpET+feDaotHqFKaJN/Kqlic7R2UZdt2Wr/Fh2 MFW3iv2T0wxIMnhRbJRtNaUWuBYCt/eZxy6PD+OnFDS9O5woRudJtVqEqZzpvRFICm1Naxej sBVhQCcJQ5qIg9rsw4jYkJUUJzmHh1puUiegZcUQ5+EbBJ37Sbr8k+Lu9vGGgHQKhUBfr2C0 hbi0rEdG9evy50ws6Tgt2RTPO/9+/YKeEaOz/Vl6M4WFfXAb4UNZAHv7bpc4gKXvtfOmthmN LIyrZHPQAd1QOlp3FagMLr/GCcp+GAPJYpNHCZdM1XfpsDCOTPh02vtM3sgcP2DDDA68LQzD aZt4+Q7m2Ag3kGD2Yw2DF3cyRKPMbV1reqi4clZ9cPpGaKft9tIRg0BuChzsorUMoEksj7Bg TDqD06cbZL1B3YvsyU46/yHogLNq1MoIeopbtDFqS0t1ZU57RYItpQ5KIA0Y7TTDqBgoBv5I ev4HZisIZdTYLqy4FiDvQr0Z/rDfEFnyzhueHO468oqXMGg5uETSLn/1ALf5TcNCSxDF2asR CoWkZ8IRJwK86do2RCLpa5+GE6hUmjFAxI1QHLcXudxUy0BpEZaboPhQTyys78KA7ExiwSbL XW7ril/gpJbDN9IC82cz2Jnxc1Pr+IvcMODMAbsl9avuM114Aac+GIqfu+xJuJQV4B3Zv91o GsyzujoEapUzlWIwlIZKZ5o62j1E11oa9BCrn0DAkoM2WO61hA59GflYiDCtSDB2TRFHgiEO Czca4k6oiwpyDqEeeqGXaYvfCZjGKYMWcN7ugNf0CKO/mz4NwKlYLazZlrShSU6LxypTRgSX NrXj/qloMnQ51uGvU8INddAAXxbrP3onoiHN3vBhVO09OtaxOrcRdCZYhwbrEee/kX69Dk62 9fV5nfLFxFEPhq7TeVv3d7KuOH5UzwO7TOzGGwL9Q5VoLs79HzjrHubAB53cr6+avRURyGFY UZdo2Hvd8CgrEx2ViswCSb9cR7L6n88gY+avaUlqMnV6Xra7ButPgE7xkfEMPwfIeADR/csU Xsyu4hXevStVIMeaErIdPcQBwsd70fksLk43QRU9bC6fsT59wx9OeBzJuzFrDP1klr9pmxxw uEYN4RwIQwWrn/tGfcF8mdOnNZjYy0hPQ1+boH1ZTRYamvut8TvaeAKg65Etfoll59nTJc6d vqAD4GsZApZQSc0qvhXloh/9+WqDR/EI1IIMxt84QA1yVvGEW2UZuJN96qAKO3mb4OUt0JTH eXStx7Jri545GwdQcfxIi01XpU4dYq343skDdExK7KIkKC3LFDaHq1GqVbz4eTIfLPFzEjS9 j1XB8BndtWJ4PcWmeKbXzdKhgqLDwMRe50Pn8mCRpB1e4hD7pX1dJQVTpI5VpAB2Rxqm0YPP QwsViUOsH8I0bICVkcN3CVoyAWfaRcz8LH07TnUGtjnxi/qdJfix6MWfA4GSWgA5MYuFj6tW 9SUhfZxqzdbu2tm6D4MBxp9iwU5ejq+91OZ4XZsuPPRrLvWrjqpFKyqQ+/tu/Jf31Cs30JJn hVzuGuMXF7i20W0ANt2wch8aEd6kKW/A+s0El7OMZooMUVparURAf+5ZTbMph3rSDK/QMmW2 F+wKAnlpbKWTbgne6xxfSxLOKmajYgbWzS2rQurvbuSfWqBGGt8iY/tFEJp+6YAeHMPtLoQS 4zZ1VZCfv/T6MZb5Xdc6f9H0FkrPJBetjL9dbAIRqHodmx8/bai3zekVbPetGCR4JBBMsEpi KfDw1rn3MwmCn+4hcX0XKf9Lf92lBsn6E2G/XPbbcH9O0oWZCQkk4/Uq95kjtnRoaewstVJF yfFm9Beq/65SHsP7iNcKdYHYfPgxS2zTkFXoiHSKs1q6LuyHGHK4pcJ+Hp5TPcWbC1TAot+J ygIenzl/ma7NKm/pgDyON3GeNKsYJwvU8XTq+ZDPYhZdWjQY27nZ9ut1CYdEyTWozfis05MY 23VYOIax9D5/86ad/l6JFI0OxmjK5DsPY/SutHB4dAHfozeWM/nHkQVynrMSprgWsNDwiXSr ohqymPmCP1UpPqN92mPiXlxmNtKNIOqc1NYhrXwLuLulWGwmgvELmluuuf7e5ZV1QY1nrffI G5hKVN8DZzwb5ZSnJS4DBl4fr1CaGb0Fw2+Nx7NnI+sgbGTI/1iZk3B4WrKmXQoDhC95y9f9 kb7u6MDRrsndUW6yMdEx5qikr73Ud6N16QFZRSfinh+EWIiRMIC7Hj8bCVfqwLSWXdWAPmKQ NoxkH4kT/ZPrno6mocM11epCPlKxSQtNkGy9Hdsw4KgeiqPhianLqe3SYbaVUSikoQI0x4YQ zJtvd4cOzdCmNixxWM+pC05xS3vB7KamUAppFJji7u3bS2Q9aHJZTBK9IzMhp0aw5qfj5uEj w/Achvj49tuZB7wyxAF6AzacYgd6wM4xlo+KIQ7TKcOKLOhsxVSRSUWUFC9+V5YoEQdKWBYa xwfZvjRdv3yf81wZodvZnC9QH5kfiEpghKtFYyH1GifSfbVOworHzP7AHBMzzPoDQzTgO2tl 9ISh4IRgULH/nMMsMEcnP75Shbgu7gITWZi0BqZ4ODG8g0KRWb+5gkT8RbulbmsXM0IdAjb0 MTeLOr8z/r/Rzk4VCFTyqk7C+I8kKUF0c6EY7iRIx8WMYgDci/RwIRIZQK0SR7iHHP9Jkd9t sG+xvv9qnbJ3TrDPKWJ/s6RmiZsnbttMJTIMBkILnqa8ekwD7BJACTP1KtKKaTgIrayYSIA8 b7lt9S6mhztVpi9Ewy/xx6j6Nbwv2nbXbT3YsDdOcBtLiIJIS+4YhVr74YqIX19dT/yy/myQ GIk8Mhsh+H5WlW8UMiBi8cgKFJcddboDWNoRR5Qf834IjKl+eLFceyRi16e9jrP3YMVwIBO7 NNLCCl9SrnpxlbA8nBhSgeLEkocBuvF2wifoly8mhHAQJ6OOSkxAg0PiI5Xa3zCzMyBiEj0m Wq2fQKD2IrKctZ44JSXC4KhmxzKv7cDFSkay28oRYBJtFjR43Lq68a9rIijsgTekjAYqYKoU ywT94sKoJapr3gTOhopyL19rqK1SLZL1SRd4nAJbWP+SrN6IVjEn5G5XNFqyVmD9MzK1l+on s1ZpLjQuYTTRlb3qYknRA68xFlh5XfmxJSk6KjzcEy7bEiqUUUtwukSEqqvZk8t6vWNM84eB rdGSlbGY1N3cJkCBRCmwa/+sLwRqAa+T370ZITTqZtxHo982FORWuXgbW/iZxy2lfwFp6obY rthnjHkLoit4C9klNY50RxTsSp+208Hi35DhsrHgzpSi31v4LpqFtq/R/dQhH2JGIUyFqZw1 Ons6gUkGIJgyIT5+rB3Uejo6qalaTdkqAVXqb0Sg0N0gb+2hcAFKcYGMEUO6pVhw5ceeGnfx /oL/JcbCjzN0G43y740C7vl7MQsTR3RdWFEWN3+zyqBpNIIH7F9P7aY1CR+aFXrK+gPZ5+6Y AxsiP/fn7+aUbJEbBuBo05DDgrNyTWkm7/WfAxhCBNVGCQj6yiQuCLT0SmkmW2F1i4GcsRoI 1US7aHbT75ICAESznMkXMHCan+7WmmyTBL5D8YIHmk1qGdTHHYKZV+BlKXtpHBwlMh/GufhQ 9SmRK+X9i3lUEeBFtX7qpd3rOvLsySe4CLjmIdWt0Y+5+SqjKLgVGChbnJkM4RutR6CiRZd9 ywY4AG+zBtLkrRDKgP/CaqLADzDHii2CI5Is3WKL8ZSbrDhY1dY7H794u26O2AQfjMuu/nFH urKDKlo+NbNuDtMZ3OZKVxtCwLnNJ/shPVfFojQ44FjXZopaildjXY675vXa3ixMzD1ikpWi JmRcvC/xjfWasNhOm9Y1rrvFQL4jaOPAmw3caGv/qgRTxKvA+4kOrmOJI2KJlwE0fTOZQbGN zjngaAzE8Sa7wJ+5EOTTlcmSo+Jbx6RKYtYXU+n4nsQFETKP/Imj03ijBK9hiAUQvSv3ZofS 7r+d5hFQveU06yoa3RWCWAM38DpcufCJYgB8mqeHK0p8WCKDpAQ5l8nUvieUpLZkdga5GR3h CeCgFEnvNqdFzgneKqW+4b2wbzFKDz49WzDM883N2jbnHuOeX76ywOgHixmXzu7wm/h2WraX kXm5XrIpMwbVu8XbmSQ/epgLluxxRuGVN6bCodJlFhXWcNQOBTHnLWk2Ge1+Ge7afnXT5zAF N+IjApLedxw59U5Ww6Y43ba8V1ecHKzhxo9gXdy0x4Gxw5VrIK5UGF6z4NnAoMY/Fe3blzU9 dS06mdqI1ROJT7MBsYlV86oY/ZfEe6mDIfVppGngySxVKJNqTqefu7d4hnQcvzTpWlgcNMow QkgM/RuECPrF3fd5qZtTL4JFyJzUlN+AYWc1RPRC/AA6sPMSv/25S4RTlIishtGlT1KdPK6D BhyiszFLPk6DVWE8XrtliqFjYT2Mg66uPYIq0SiuvmdtiJ6WBsD4izu91dKmfDDn+AAGbcD6 7+h32SeBYDvrMhxiDoGS0/uW/3/i48zqjc3CRJ6mejJHIyJPF9YDD33lHJlcjHmHCAHZ7Q2P 1rwMcsLCwKLoPbygHnXn+l209jZpUXzzUu0nPQzG2tWftUXy2DtdF89Gr1qFSyc//RC6C27Y KSu1xs8/wXTiC1GR9w/5z2ZxDtlts+3ioZhavcEyp+pfkPRB2Cb2LfVlO752WbUmxlMgK7bh cuBjE0xSku8C6e1wmilKfcotWpQojpoz+wuQSfmwbR5EMBIYoZyOOeL3tiw5dvOXXkopK4qO +G6OB1/vM1vQU35ydV4MEBSRZsLaDh2eiCq/8x3MXxQ48g2O7J5EjaJIZAPDJSfUp65UrClW D+D1WQytxMd6fmtvVcGrs9hb4kgTqgN/rJ0iG3zq6RxEjhSUjFJjo2nKhZjlFdU2sbIfvWUa Wy/7cD8e9jI3HtVSH5WD2MhBxeiSkiDUqp4vMACxEFnkMfFPUF/j2ffHCtRKrXrBuZFRPINm vhPCtktMrgJ3r2VUTzKLMeCOI3tUKzr6n5sSGgD3ObdIEgGo5NCMXukhorBei5s1OnxotzNm cpWMz4PgPtjLOXu0N6rZTbsySqv2YEAakb72vptipEPE/0V7E6pf0b3+XJ/gKNeSFKdyTrGP +W/CJ7ag4zb9tQlErGiSKNzTB6qhokgCFCxKdXxwGBpizofAvcnwLEwxE8xEVE4dAQAe/yEa +35JCpoKSfbbB6EUl1ZgGMU5TZqh7VnnRwsWrvnS76QUYx9C++AFm/6q1xar1J98aZokI9Db 84ggU7zXq6T/cj8fgACqJXpcESWWh/MzPoEUmiH73ZB7dtTldIHgFAIcp435f/3cUyBE7nrE XqoMfr16jIocn7x+Pp+D33Mdr/w1QAA0QZa8Zl9IjdtPBbP0N7Ix8AyrU+yCmi+JvoLsP7js Y1AIdYEek1usfbLsnZtd6X7PsTI2HoOSU9Pcl2yKlt+PED9chtqYBGxSmHVbOtQ4btRnqCta jc3Ju+cjz8LNIBPlFp6D1WK5VEk2Z9MJ9A8zzOKaYBG+tBbmeL5QsRMm4+dmt7OjRUg47Xxf vw6qSOULOqKvFqtirlAO1CMYm8B91dzfINmwC5zBmCMCVdfxxPvIF0KTD2eehecEwbBcg+zC b8236yl6gQyFO/shlqUPxWuajUFtVVSU5QO7Gz+D2EMysmfPcKMjo+jFgTrQdXtX6g/qxpks 64i5yzYSwzgfV5A236LrqzqxbR0GSMLmWYQx9fT/5d3vSXNy5Vj4IyX2wC/praRrzcePVxD5 mVkVdk/dLTbaGnaX5DGcycFOKxTq5ez1urHwkT52+Of8PJuxtWcMe5xR9ghhc538JRQH8zK7 OHPRbudqfrcNgCTvviQ6FmgpuHRB1qiefhY12Phj0Ym6emZw5GgbffBnmPitezMY5Y9+o7p4 qtGMIjol9w2/i03unznStvgtk3q3BVUfJiaQRxYu/V1GsJ1iaeTUvB/3GPf5yLuwPkdNOH3x 7DqC+VWr3k9OFDvY+wPPIkHNhQRZ8xzcEmt9SWSHRVDV/9H/JLsr4hnPuo85Dy8y+CLj0rrU 7nD8VWdxCiazu+IiLR1v8AGdXbU16zrVQuOGWufskz6yhOIUPqB68hwNSe/EWdfcrYPRXkug 70+5HRBhRm8cVSbJ1GHThxs9dskmEpgx0Pr1w2W9KY8u14Snz9YSQp7WJ9e1F9qlnn1XpIvX LInrzJkh2l490wEeEcAkrBeGK0og88H380S6nciydBnda2WMcjbh1mmloFbEoH1mUWECV6Th 4R+8+4ecukfDXiSpX5CI00MEAv3Pz6xBag1uKzzSIXL2CMr6wUdEqpgsK8WZlO3+VnvZOXti oEjqyKC1jl5v4qzOc0tWd5RUkNjpy+TOemuwr3+aAfZpo85mScDylaUwtghYX47Lsbl6s92Z UzpOhu5NREULtDthnP9cCNwG57VoYDVbSENgjMP2jWGV8sNxSE2UcmX9CIMtb01fQFCdSgwo ERJXtOfchiXIRLU6ry+toOLCoEvNheshW7VH/5w2ZCrvGsU4N5/ZG7gzErOpP+PyiJ8ug3Um QQcYBvkVLBp8hiJu1j1YAP54Mj/t3rWUR+HoihgD9q/WGUymVw66u0gijnEnOtBPpuzICdfx c9F9xKSjAz9Ht4xhu8LMmsDX9IYr6HJZ83uX8ry7lWeYMDUr6Xem2PXXGYtQTDtvr46pmSJ3 R6TnHxDj3A6KniLWqb6NmWTN028sC/gioBwGxcb8S3SR0YBInKULUOo3ZGfXdQh6LuSfXqcp ETNsN57uJZAReScfIN3EXW7lwnQbRSZwuVyKMXGonrCk3BUvwzmYt9bXfSOyhVsx+nQ58j1b JVALCOE50Gt2DXyOXHY4W24eiX1bt8/wNZZem6cjsBOdqY/5HdaWC6CBJ7BZN0F1jI0C6LlJ O7iD7K6mjqq4RyCvci47atDmk+cxQwhw0Uig7FmzsFisEjFmNnoPW1MOXMyh8YxmLqhCxrDt dtS2Szfsae3N+Wr411FSEdgQ5dBe1HnaZdt8LYTo65LSF1iJmX/srlIiUxyLHSdbQPUQdy// riYQvDdlK553D9zsRbfnBa2+Dw8x30ntNxKvRB74Mq2ws+4W4Rd/n3AJS0wnRcASbhnQXw9r 7es57odXYJ/ZacJg0/hr375KLTTSIY+zVYuKEVrwgknUdz3XR8KoEiQklHfoLfrlheplm83N heMWlAw5vV6Ov7tPgiW7Z3JcMcwbXK7EOJ2QJMo3Q7ElmIDQK/hlXtnlP53Wc9q/rBkcyVYg KL3GQJm5RWMHWOWdtGOEoxJDuDl/IK8PpzQzYPh84cm4o6V0m+TJnt195PbCNPoyaLS3SXmC zofWU5atlFYS7qil7mSxUGSXHzydXB73IKIpvZwNXFMsN8t3I9kaEivODxK+X6JagJHcRLl+ G+1T/dY5D3SQGIb7LpVoYpekUx3MgVsUj70lL7ICM0ZBSpikFN9OSCmpgYj5Yfs8tOddv9rL 24soNfE4buy4yxqhad0PuSdiEa5ZxLwKpiKCJCmYJJZm4rP4QaTWVQMii9SOklN9+Qj53vrq UGceU88ojSmEyT30+B9r0ye9FCGhq0dQyOiF3Rx7hlC4kvjE0z2AgwISs1HkobnUbGB1iNct cX6QIp8BJxebNeiQ94yq9wHsEf+bHeDUMr4NREdJrwbEH7cmKSfEoKaj+getS7AuDnd2t836 qMW0p6YwX6niM09Et9hZzlrECBrw0Yr1jhrW3MDibtCq8XFnr6UG85p92rRMSIFW4uyNY5Ln VE1Lb+5hhBu9jZHAUCNshLVJxmYzX3uy+fntDVGN2ChZMe1/XP0IA1mE+xG6fL+O1UP6nJAC tClOIUT2IDv2ZVXaGKWrRzXKwzc5Q5vx1iyphGkLnTY4OCsEWh59lyOhayxTu0ZLr5B65hUn 4IupgUsqAqGgxaNDjvPNsJWXFCEyZ8UsRw+j4iUOXgVE/4fs7iV8LN1i4hVgS9GE4i/wE0Zw LEqI9RZ+jn4xtFSlDsIk7MruVeWWZYieNoDWTbzks5zF09r6ZPHBV/6NUC/v3pzJdHlxAnm1 5yUbwMVnOtMq6ezMakgXw2zg3SHL103miIcLDt791pEHFa1vfsmndb6nif5erwFi5CfRTSFS 6oEtoxGquN3AtStkYxJhSlotudPUcdQYQt2dWrq8B7PUiPj0qiZdMWpUIQh3C+snKlyH3ThJ bjjlCMv70htFRgZ2pMcNSOUI2UQeeArxH+DK9/48YKAUqUSwT4FLT5WyZz1SrpF+ozIj0Q7v SMpYfl/0TohGbSOC3rowaa9lHQW9PsmIt4RMEZX6iMHI2o4SGfDOZ0Kn93usGVnZG5Xg9l5P C7Ltj+sdxyd8U51i+R5FleI/mBtEpJJ7dC3Jt44T0UdtEgF2fjeeEGoJF9Uz7yQq/dJEvBct pDvSAsHgRlLB/LdtPve9x8dwsubZOEf0Lcp+2hFz0/6P3Cs3CQODitcUIlsXYUAi5T0EizNu uqNQoEcWuFlv0trR4YqnWlBpDVVMEimCaRBjAC5TNTR1Ca9bTb+8n+MDwCrJMUN+Q3ow17Dm lPjYZAEhrfm+N4oRY5tAmYIhtYTKJHaBUA4aTbLnxk46oDroJ0YwmEfhpjf6WSe3GNxysbXg nQNMN1uyGJBWiGnpMlewY2kwb0tqpKuWTGGIyR9mKWkrhXoRgZBVO6r+2fNoj28J5ayibn2M xgpfGd8uTdt48mV43aVOL/JxhiyrvjUxmxfVblMpMrwKnyxlCvDihkhQ6NFPtpm3pVAZssuW 1MMqgYv8iXhhhnSrAhhkMdMOTneAPLrF6yOelDtOs98J7VNpybUKP1/WK7g362QgNofBgCAr t9/6pzon2KsHV/IeUTKLxRyP+8OGs61fhbVHPMaM1VNL/71gWCYYWTqs5TyXy4K8reXBH/dr bG6V07E2QTSgJro3grO1+xV+JCv1S2iRM6/ClfFhVAPemcjy5PnBZ/q4NWFbvJofYwLfj0aJ woPXy17pq7JdKZmwEfgHE8jI4CH4kSbFoGXHa2bBph7biDasdU2r4hOwhHQCm1DwY0Iga3PK O1HVTrPbv8iwmP4kohpOVt66o6QjcQd7kB68Di8uzb/sfRktu0zSML7boRYfVB7GUSJWVd4O 5Ri5nwtm/VvDCuuwGt0H+RTYFqUbjmJ0g9gDPxQzZT5wWgHeMYrHs8AyzwXkhNk71qBgk0Z1 6MIRE5hw00etT9qLJlUVfwmU8TQcj68+0Wk9CeSSOlo5ICvd9NEMu+XqzE6Yr+nohAaJ21Jd +dFlsZsKfKxMnREG4NYz4zrsUITDB49uiFEhSJ7HhlP7MYgJgj6venNqWlQMgnE7oPu+MDvg FM/CgYDcBvxNozuRU6jKC8ZyDN0J2EoYbgZIESqo1qxtWjjgZxwqCFuEgHRYXcdmbkzoxXR1 DYMKapoR4TFyt/ZQn8BekSTlPCoKKwWW/zV3Fxy+SOJ4WxBb33H7RBjSreG9tJ6VicxXChZ5 RBclTEOvVLNGZrl/3PkRzIo4n/nwIwrsdTJ02yauHi9WkOvnrizcEKlUOkCwcr90Ob5MnNUq oZLX5O+5lJL8NgNaoqX0bbDRN9ZGM3FHwhMPRwZXyHxpwLTJBeltMyfMfYpLn8f9uZaM4/eT zWrwmV0AqLEzSGS+r05idBzjBNlFyn27a292Pj47nY2QTshwFkGS5tIaZRhRuLch9fuMPeC/ CPShTyRLkS/fnsRbM2LbqhHo+LJIPMprmRiNxFSBKJxNV7XZPlUhSGsTvfzvn7UE1pwXi8e3 J4bFiAXIZkbJK8XEJ8gDjZWpGe9+/4miTsNvciQOEcyHuoGH8RPVPfRgY+Le+LrVfQHLglO7 dodhzIVMvFjMhxDACIeotyC3SoT3PF78t1vn1PbYbU/MYySUcwz6q/Z31dhEG5sf5jtTHkc1 LevUvKfLGGa5bLfbFiOruzR+ZbOWT6dGTAXjaojGgxjtmo2iK+6jct5Oln7INaNii9wYLBa7 a4g2kFYJf+HeH48SRAd9NAXwV5j0e96n1BgDgsD7WJmqst7x3farNG2h2HFqzu3CR6FSyaC6 CY9uvraoLcNqA2MLdyZAKxSKzrlAt+1hgMbystI3fYGqU3vTIyrjIiHQA1/RvNK17fmtjyrQ EYJDwGBQ249O7NLgrGOnCyLV9H3LNALb8dljzkr+3tT+TAdP9LjMqqWWeQ6rS3JU8U+v2iVA MoQoyPPkylGRDCYd2sXNqe6jCm/ywLvTc1UJwaJXzWv/2Qg10A9WJGDGP+Jbqx/xpysAvFE5 VeqydjKB/RweEfKf6XMCoLxmLdQEYhHKPxI/5sz1rQaYOjT2UY5HIHI1rRLMMsHQFw6MFjJ8 3EoOanF0k0Y8h6/dBhvZj6xttamtd8Xo7nAdkLVn9p9+BsU4JTV81GRuYsXDrM3M233LX8c4 W1Y19sLcQH9PBn12v1V2qJF8aRBuLWwlxYYAABH75k3/T6j2THAeqBRSuEy8dQu4bDrxXdjK 3DRuihBiN/2XLt2eX6hAWMesFpJqK1ycqeOX2J7/nK70XG8CRezLu/023tnGTGsuoIHTuq// RNoXdwPVPCD0awlDFkA76rfNn8PTaxwlYvoB4vnwSSL9XjqlCP5tUen93pDtiZimBJUmiYBV Da0GKL0+5WOW/XhA72hAnrmpJlJGYR02L+TABzRAo29THspuQfucYwfTSiQzrjJxc6U8MK0S QgevtKw48p6D+CSM9tzIedBuz7fI+2ImXW9gDM2A6AERI7sbPCz6EbI33WoO6VTlk3nQvXq8 tjO5ugdzk/5Ip21q3d4wNQSumUJZ4TyvK1cr+nbQz6IRWd7+/lJ0hws4468JJOmhTpDgJrUa TR0j9knJZzgy/ul3kT1HjdBkKytcAcM9g7RjCqHNgxPemnrZR/Yb2aeAF8M/E8BI3xp79J+l Und7SRjgGl4gBaprQksedUTRxAemhl4Bk65ITvUh5Ckiq0z/Wc9qr4jAQKfKbTZKpFD4rmu9 ybYNHcsWgHkDHyIt2eH2YdzIQtRiMEPodradCYXq/f/fI8AGaLeKako5LJYW6IM8WQmW8rmm qTEiqsG2MDm6aJ1nKMSM6sR8UCXCFLjK5OI739D1NXjmOYMCqEK/B2U+j/y6uySfmqejyVMM auXFeXtAdedCZhTywHqAi+nAk/VLp0alVDVEFg0Y5nrRP8eF4hZtnWPvLrASC5Ra0yH2hWhX foVbtxqDWd2ZMEmBgm+hI2zL33IftO07Yst7VeyIWJqmr7f7Uxc7c8GQLxiBwZEEHBCrW+Nd VEpCmg+XgmY/rqT952AQf91IWoMrkT3kbbWBr1gpZZP8z6n39HF9+r7vj9xcPEEqeHqbvFQe 9h2zTNqURqc0+zRU0ILph/bjFHZN5p4hMAtMJ5MmDfbLCc+/9XxrtBndRhzXxSNuxFOWCtwc bjYdirLl0Jen2sstbWJZ7o/z+5eGP71fapW7h+surXa2+Ai9fThZift3byP8ZY6O9iL9ZlYg bS4Tj7wIfNuD9UEo3PnvTkHlR2NADjVGaNgls0TUASxiZ5EAMheGCQfOqRw07ZMMb1Cw6DaB ybBV64yp3wi/nkLMEps0TSoafU9WXETq3xgUaktVNcSQG7hbJgSJOflRuQzUlUC/Yo93xPZS fmtnQPWMPBUdjaFWzAy56QBURt5ndvyh/ihyO/zlbUZ1O7fHAdR7vSYErahpsrl0LX0+zs/8 IRi3rqM3OwWFVlcF8D3JCinWN6Ajc17yXM91oPt9bfTWpy41aWFVLB4AgiDlR/FeymI04XsR 2NGdHzLLHX5C9+iSGEOfhVNgJusvDtZ6rz1PpDD+8Hn1M0kxpwKJEMTeL27pm1BYoj//t+Y7 DszybPhFDZAYafMFuaCzKctyDJuuIi2y2G+Fyxcegcdsehsn1sYhN5tDQVkremeSeg7SfA9Z hdOC0sAYhbywweNZH0lBLTAZpLHWfS2Z+GVpKUdo0BdaUmEL7N+hdf3kbTprCFcWHt99E2qM u+xIrzbJYvNPNpTb1K1u2yjV/3Up2B+WEeD2TkAGuUSDvO+WFUzjjab1MPutYSh/01KZDXWV ZTUmuoXqvqb2VY4covZgy01lhdKIa/zejVbN/UfUsYFVRAeBBCktRJ+RKNMIj3AHhgzs0rfe 9Wj4sZrD6Dwb/fwAoHTgIXDjJjvZOQK7mSnHBe3gAwyhoqzvSXSDMxV0Pj6njlYdPOBztahl SlRWRYe78+lcQ8Ch11GkfV4jdPLb0keREs/Y25VdEyWG4QNTuwvbNBLtHsSA2xely9nNsG0E Zqw6pfFZhc30tBzJWHHgAeuMzDA3EQC/ETxAiR390lMAm/cOJwsNi/qT85s2f+7mHZgrDRiI RRXEGV1iTRrDzNLgOGQHGyEtd+rgxRfp5WguRI6F/d6iK/QnQ3PN2H63F69smBeVc92BAMNZ NDdEGYsS0tdG3KNxwQPnxFgbpOjSXJ8XAjopQIeSDu1CAophex2C395YknZ8QYY4q4mH50sE OdbINE1GjXUNK0NSGbFJfQ55BFxiFn4G3zCklIuTHF75XwQ78Vt8GcNkMOuUkgGSEWnAJqHv qQyqFf5pF/FKFpuM4f/98Tb16Csy8Bb9ch/ZWhX+tSX9UzrriwFmxQU9HkrSXQwO9AQhtHoh nsIualPAijA9AdpTns3XxAB2/mSKLbZyhKkOjmPl7wnAPuqWO7AVlKlnGnq6+MU9xlSZWlrh QKOc03bsR3mFAGb1UXZFVa2wnW40yzTbKeTEC9Z/fliortUlAxGoKRhaiQgXXem4SHmg0DvO o1x7z/LbCBtHbCCV7dKgdkmLnuAuLNxaMcwkWsS+aGbUOt6dsJPrUs85BOh34qm976dtPiRa UlePV2qX4MWKEizqaIFApdp8Og8ZdDdYmgCSX4KjWk5xOQesPsBXBDIMQG+fBB4esTHjdrXD GlqYqu7IiN4YO4j72USgqFgjzKbHqpU0sXctfkotp3reDO3v+vl2olgoiRBsRe7tYRDrxm5w fwizcSU+QbPEI5TmaF7ZnJj7XlKRU372/MtiHOiioEm5fygE6HVdZWTrXF+u95lZngrB8vvH e9RYWP0G8WyNezFvxu/JRC0+auVfv8Nsddj4pZ5ub1d+KeB1Qb5cPynGQ+Yam5katbmiwipY 6hI/uUp6kDzZc7V1UGXt+N9vZMyWKAEwk9aut4Y6LPk/q7ZM0zb6/EfZkENPf+nzroKPfshF fmFNlqDShg9UwwcqnmL4hU0pD6weWYJWdAm4zgve50RNz5TyPsK5ektdGlmmeJIqCVm9S5sY 1BOxf2DMFRN7rqo8HsNPVDkCtbxS5PwkQyjn5k82YKmbONId4Ha2IYjmVMyD6i4TC28mXC5y L3O5QNd8l4To5ogoGLBPGMENXvHt7FfotQ2xqjJPFnafhuL0VMK4e76bXrUbd7CswXGeAVX1 mnAEciI38MffC5vbp79I6S7ZuVzadaoLLG0AOUx6fYzWfnKdPI38UfvoT20ygbbhp6y6l6vG LQwwWWuEdGyIye5DmyIms0oAg7Bi0xZQxovBXa/GXtPUjBexdqe42ZpnMzJOliX42YaHV3S5 tIPGU4MTQeSX40Fs59jyCiieKEZPEtMdUsrvLrMdcMbYxc8vAYdgFJRkBg39SIhfVF8RAq58 pSJCwtxThYESID4SzLsbyFxbH3G06fD/0YIoqX4Zfwvg46maS2TpEa1hjKNbSejPLVw4IBxE o+g4g90gcirVMMMgES2YTfeqoPIxPxczymeeZLd34T75IHphrA+RGvxr4clV4AX847khp0cJ kEeWdWstjT8xxwZAjyAsTVxKfOSnOgx749Oyoo6kYrgj9x+kNVZYbvLuXuIinBPajGt02v55 FUnRZFc0PUWdyX85Ug/KsWO0bLVfwesONbOV1LEfx1o83bspf42S9HaPA96amFybFXPIfG0W na539WsMmqXGnDBIqmAYmm8RMehYM+I+vEhis+kFLfX9T+h2YhIb1k5+LgDcyTohAr/RrXHm EYOgWvrNEqIcl6Yi7Hqn30fP73qExfSwANTG9j4LgTGmpE57SGk/j/trBERr14y71g/ccgg9 hUO8cb+gx26bVr1FXRHldpf4Tec0UEshvzmNjfzYGeWc8zJXGFPfHnCk+QvSZtO88I5zBG40 BchKnRRGvJSMZ2vknORd0tRC8dSD3VEwQvz5ABIEOIOkXKsM981jHtSkPlb2+XawCpVU1Y2z 8qDkpOVq4tL80aMrA2W5W5HRe2zxYjy2c9ebDsW0wX05Gc8jlsqJCfe+Oat+s0aFt1NnPg1K wnS/Q66bq6a2i1d6Q9yPcIwU4IC8+cXXvjzMLhxLwkLFgmHc5qWTed+SEhM7VN6iBuIWoX03 x2QQHmpu8Vt1sv8967dWPaboaEJmc4OfsB8CvBGJjIV+05rqTn9n8ZRWUSVKuo19ixMXyZxx gS+k+CobXLMbUfsCPnjuPQxLTd5YXC4VItpRMOcCl4eyC5sx3R31KcAuRthVQrXa90I3YgHN mYg+DjIaHPeJJ7HD3pZcdGEZP/1MKsrry9xtXyEbWgD3npUr+j+Or8YB5Lgzg4YoGbvvU1dm PNj5F+TJWALfSzXVHgkS+GT/V54YXPcqRJXWD1tkj+6T8VWpil0JJoQdKQvsODrUNbs7QahM /5BebWPGM4C3m2n0w3lW5Lz0k8pEbxAEDooleNrecxkGlvQxPHid+IS+s7bAzS6v6S42oYug KsI2YTT2YauuCvSGa/uOiiuwNhYKaBKf3JK/EP7wOUlcnGMLZyfLYL2jELtONCzzGwSRXXIu Rcxt+gykuqKyJblV9JcDTU/LWeCJ5tTa7MCkHyvGGovST+FQqeyLd639eNy84Hc1c4BTiuQs r7KClWtAHmT3wlTspoklDo0sXGN6P226xV5LV+yg4wP9SUpflylGWhD5ocaG1IpkRvIYq+B3 /jS9nu76As/xHnvammVoDM/AXFlic5TSyvMX5lBM8V2oHuB96wgGMCl/+32meJO+A/CnCjZ7 SL5cD+E7ggW+gWSHRh8hK4xxun8WTwFcX6Chpppq7hItbYPSzSRT/2iph6nkBBlfD4WSLU/u GoRjfB3lWCINXUTdmIpBhmTp6+1D/stvbk49VkjzNa995rNnKsj+ohZaZN7cPDMItdoAzI6W DGRo1Qd+q5k3womwbblx0FK0itBlcpLD3dlcvHihe37KUQ5nnypH9wBfTidTV2lnK8d3GAX2 yNK+DrOo9nNgPBbCgfOdNfC7JU9KaLrFv4HmKIhiXnw6AJIFi7c6A069Is3n88hWzwFzEV8W BkwD9OgdCmQQ1ZJKnRs4eIs+0Bcb1QSIYCr9k+ZuSbJxqjpMesUOERS35Cbyoa8H0U0xvP2W GF05mhbSoQLN/N6708793veaEpE9ytzCd08haAtyea+KinSDKrVAoSGAgr0WffYQgWNHokA3 1COKUpl6QnbZVuI88ddvIar5v90wOsnX/Q+y5SVEvmRFD2GX/YL9T756skfuFgK2P0JbZQQP uNoSPFZpGJkqZ0qdbfNpPmwGK8zaiNOkP96DjBlTZDKgkaSBqMo23DxyNnuo6DjXfpFXzKBY hYxJZme0DFVJu70Oq2ZeWXCC3dvMdgK2ws39c/eapbz/49L5W5qYf4px+c3HQFl1uL1znuHU DhZ94iIYzYXYRvIkccMjjUXVdZ4+ixJkcrdZ5YZxNIeYxfXDSgYdK3aE6UnN6k1IidIxhbQk PsrOZWFNyGMeoR1BSxdIurgsPKKJp7EcnA8VzkRx5/+eD65+PmUE9uhE8wWCwhjs7//2PIAf nlGtIjx5ubkdQnliMW4B3GE8flLs+sdNTJ/pMvDTBVZcGXj9XcafcQZK0TylBbT97OUQyUlb HFCTdogok/G26u72DMF8y+YQpEfkTwVGzi58SXdgHNIoIS4FhAHVfBQuUuuNBIDjKlIPC4xg mIaYddGdtLPtAD68it1V2kUBNmeD7Ng6PnPg3g4OiJSV5yaQRCQ/fJoV2OZx4OSfOQNZF1X2 wl+ndgvHi3WN0wgNjZwH9dfasYpPYjjqHwJLyKglWqCutp/eStI+mS26yMVmNrBlEx3torgt UGogOWOkTlItNNT20FrYmQ59ZVnFNZTbJl1zlGA+4m2dkKHBw5ODusMtO0z/RNzUj+3QnkZk xwjOhITYSFgZxNdLYULypYOER6izrjpdcuKEGHxGdp8wwjMJwX7n8DliRH2vXBcbr7cSLNJn kNvsJf0DeyhmmYPaN0XEmU87AGrSXTcHD6Nx52ommCIiRLfoL/yOCZkz1c3e3azDk4WwwCSv kX5PCdut+z2Xq3j4FWRqSMcyZViDESiLR0gTptF/I1Yxp3o4sC/iAlp/Okd3xayKPFYWoH+S vA2+nXwveFy7+WUNSzsamZrH4eWC8p3TICiqLw6xEbPAuc5u1SChfowYrRaw8GrEdt+eJCdZ ha2PWPC1DH6rQqUZ7eG8bT01UeabF0dr2kl6cJOnVvRm7nYGdabwvuJcRYDkJ5JCWTd24iVP 1R+JmTC3d4leAOFK+gShS6P36Vmd6ibzjvTxL9APRsLvRtcch2vuHdYPHSlpjfpvDKoAHqQ3 IxSV3zJ5Rt0huqqjvBewuk6/dmkWJfIxyvoyJ3GZLrClakow9GtnuXCycXOH8xzXU4m83iNE 1FGD5zrH3CWYHVw9/qKrbb4dI+7v1u9lK2JZlh7O62BRG9BXH0Lka/uT0dpuZt30S9xmfqY1 xuR776/h5SvsI/vOhtpTEfzseyAYzaxlzyDm+LzZjljP8mxkdaJ+C0t/y6qiAqUcLA4fdEgk eUZUvJRbFADQafxs354PeV6f7i8Vs9VwRzys6Zd9CUMbwIWa53i9Z2I0OYQRvZSXssv3Rerl 73U6JFRAhZeO9AOKgRD9UlnMlGk+h80wZWN2Kexte6AyyzM/vVfbsGI2l0otLxKgDLw1BAmf uuXCABTf7Wiblv6j+6YHtfyS0lxVogZeVCexzL1v5Dg8tuvvBwHa5LOoJQltyYE6D7BIkXe/ f6TSlougSNDOZEZrvj7AL2KLKIcIUVTXNAJvl/yeIYgQIjDEI28QGKxKRZzfL3T4R+9BdIKu qiF2v1GurQU+9qOZzIYgWPERk28BraJbuVhUe/I0HCKEKbnEh6IrEgB/6ASBjFl/BzwgP52j zt+uStyLmpJDW+kVUnHHtQRkJOcQ7ACiHgR8lRHkdNAU24Kaloxnmlyn9EFe+sXZHNQQWdom Eeu7B9+lHGr2vZgsy5A0DqDdgBbwlY44x/1q6p1lbP0TsQ5IfHI+0pthR7bFdjeT2cj2n6z1 1UBYkrWRSNiGwA6Gq37VPPJcNzigMhjeiA5ILBJS8kQ03r14yawfyuIBxdop17f6PUFrOcBk vr0rRfXi4loPr22gqmRuvh5v1GbDV39x4/iQTIjczMLc/sgMF02OvzLjUDafJ1Pv9l2KmjLJ /bKugqJS6Hxin+PDdXl/BQrzOcLmWugJWjsBkfhKaUhYpA09ICVnxakiHxxQxFPu7TVXUFnQ qHYO5CunbxvyH4jK08vO3z+Ageb17NdsnCMQXmij3PEUawlymLGNoac3x2V127nS4+3H9Zwu W1B524EwhjxOTrq03HRtOVbGO0rLcfFojJLTK9MCmiYvEYCDd7D7TdsB1Fjuxz4/tpaFiLfh pqZZ91p9slIBU0Y4+vLnEmBBcNlVf/HrdKcZ2sLFDNEuASTeLtRhr/RorLnUVi2P7T0zAYlj NwK2CgotNY/FwWfJ13/pNYBnOmZANZlYyZ4p6mEXj7c6EDOJb/mN4QGgrPhZJJqyoF6OZfsB 8sElGy1OD91mWwdueKZi4ml7jWnuODV/PEQHh4dTw1UU9td5GLzOgi/WTBhOm1sWuxbLqUf6 mqoDMZ8AjkzwRFSlazEDKtlF2xV4HDqbzaYkDiGL/u9BuXhFvPA08Y+cfl5QUoJTTweNj1a2 3xoacWDpozCyGvM0ToFG3QoijdwITCjop1ET7CW5MAO/5d/kE0BLhVbnfBWC9Dv8nb0J2lzX 7DWSKiliIz7oN3U2jdIRDRvZNDNoLVo82oc4s+t8rz1ZwRbSYJklj81Rn3x8J9WhYdJKGtFv LPlUHvuHUQOR1nNVD8J3UFf1MEej5utmHWu2ruPRRKEO5xPDxvw6WUssMeIh/jEa5wpItNCd lFp9YGmJB6lD8rFetk2AZIOij3Ie3DggcPfZZlWh5sQU1ltCVQozl77Edy7pnZsswCX5xaSh Igi4qYJRXSucizFVWPT8gUyF1UIeLwt0+OZm0fTj33UW3qemZSTKgflZRHUtukbmyUS1K/qj 4gHb8enApSa7j0W768vhXb5JTDkdYyNLy8T4KlVMQJWQy2Xr0M5+Lgpt2QfK9oO/DCIEv+TK +wUXaPZKa9RWcvavTy8negkKBBKIqPciib6fKE+HWnC/qcXw/Mb46aXVRXdbJ9kFU47DFdSX +gzSLruL4znwZjg5/ov6Fn0SQVkl8BnKrG/w4Vev1Gm/v8qoH40dFBtP04l3JvtGsmBRl0g2 Z8MtMKjgnTi7LRpCxRcFpOWF3wv11V/OdnfOv0xQXHf2whaeotPnZPgJOdP4z7SD2shzRj7r sIiwTjEZZTGVfuouH+c8zwCjDh9SIXLzgDEZuJR8Vv7yxlHa/hJJcJM+497+oybLfu3sN7u9 d9qA3ywOvz7L4oM06QNMUTbmoLAEutKWHhdM/rkg1Fhv9wSCnqnIYkgpiEi0IOI/NbNAxkH4 TYSEsq00zrNiWEgKZDNNv1SqcrnEqDJZPpATV6/eMQ7qY4haWgIm1BDe/k1Kod78dLZ5sgS3 IbvgzdGU3ULGpsHh9RMtZta4EIOkpbL1xq4k5c614I0QLr07yJoDSu57X1tjZru7LS8i8ADX 6uLtDNzXMdK6TcnI3oRpmR1dKAWNyw3MbIGvoLWrgaigJJWyIuZTx2GjsynF8Z9VSkkoTo6x Lg4l0L9aB1LR5x//Mcz4k2zsHAq933fLD2fLIYbH6Rbl930288+yu63eBdgudHVJB7QMjqpQ Jh2ASeWL/Kybd8MTOL7EvAi5q8qQ7fYYhCUZQCgR7tiXBNa0zVzc+UT/flw5+oH6XnUxQOlU m+Yccfw/33JRXj5wSNyebaX1+baI6Og/lvj+Dug/myLbXEeW78dO1ux7dOunnwlKFHX+sFHd MuLit934BTz5v62o2zwkl2SFA0qEYhysmAlAF4v1xbB2gTq23hbhUQmKNgCqxP5r1LVhHBiJ ST4wkc+SEP3fyVW3vLWVA4wSOXYp9GZlc9FXvnrRSB8edPUjjmBQ3XzV3TOxSyWzFyQQRY65 JKTADrFPZMU11lopN6zZ97OLJv7ahkbGRYVZJ9iK4t7KT+4UucrN+V6qnLTzpTp3b4wmisCv vRIaNMmggPhqg9NEM847ijY/pRME4zxyvwe7m3RC6wHB9F0ZReDHEfRWpwvkxrTGYaFRJVCL XMwv09v03pD91lmk8/M7HDq+S7yO8CLzIWgZ7eRe0mniltJl6meXCDV25issRrdXGLyk6wur QSZv3sMCGrCBhgFKieveOrQvK4CvWIpDJaeTUpoYsl5KTUBmnOEaWr6XoNQ+1uI0HIA7FZ4c kyPyhMR1w0u/1yQHkBpBdG/KX5Mq2ws/qdD2nMMdPPNZm+NdrfQiBlywjcqZmDqhNC5V94aH qpnYc6p0c/pBIrRmV/bqJwe1+UbfjpmrxXK7AyqzkgIGUComv2r+YUonFpB/KvJEqiKK1wfT yqTOHiSoU37EBgv/wLTjZhy4Te4qR7OyF/PivHXPVY7N8cZC+JSzZIGiJvH7n+UZwZe45oGE Xg+03IZDckb5sQpTux44wVrbOHsqfxWT93XPbXPfYTt2W+Zpx0tXdJzgcWnvQV0wXV2UkoWF M1E0OeewfCmSiUCwJDb+RxqQT/4ojiqPH33eTjjP0VTJ4kIutZ+nahI3Qt5IUBSf1V80HobR bGLI1SEmia+/02ceCaeaRVcOI2sJyx5f9gsWlcn9pVOehQqUEH3znbNTEIgBh4vUEDYlDM0C m8qwdRE1gFAT2Et7jEptTtTq5v2uoWo/FmgzRr7LOXh3X5ZjeMSnMPNdUjRjqEqTfaMtZ4iF 9SCZqpXnjzvqKeTdP6ybcuX/m2npI44y7ruZzcCui8SA9Wdziq0rP84owD98jBzNRpNfpwBu b6wWud5LTEmW7z4SkWPTK8W/VrsixgYolYosMQnRKwFnwC7L81367nrQejeqLqV3FJRun0bT 0qHkTA7IXvJatylBpWHWJYFWGVcIJS945dwCyC8VlJBKzYGZs2JFZgdtcMdnubNN+22NMQqA TVnoZSlKtuIAQIsu+qF+gmZgd/zvEMi1AIqeXcilZS8x0K8PDtgJr5ZXF2Ox9gjtvYG5PUCw BrjWRVXDV+iAIyt4zrcsernXN6be9asw7+x2AQqz3aiO2PgU91NZ0x8nfB62dUxnoZSdC204 HuGj5GAsb0zmuEHuQm5QQPWlUWtp6BhT7beCCgcWqEWx7KAohSgfmEKsQgaCS0Fe3ldwmAHg KklqAthtqakpeWsy6zsQ3OyPcjK5f9A0+6vEaj6VI3voFMahiO4RavWq80EOlU62BqbnL+/h SKdqdc7KA6Mpv1V95X7Ga7b19vGz1xQxBtRg2iM3/57x2qhHmHzKej3HNEZ9gxm9b5FIhImi 5B/MczX0k8BJX4maTtHPR6kICt+A1cOkgClwjRjrFob//S4unwBKK7cIMs1r3DM19fZvonOE AEjVHXZcIHErKa7qBdM+j06bJLK8njL0F5kMa7UP5ftn8mkp06SHqyRUvVUmNkkM42VuiyCO JRJqP+3x7n/S7r9uJmKDKZoWby2U/Mk1QajIcJaL11RrYghRckz1TE+kcYKn8yA0R1zQzcOp E9K4Vvn0KH+WM8i+vmZzoFyUoykr2tJt/egL2mYH9Hk2q7NT+jup8EhOTA6M9lKQnWRTfcIP lVQ0GcsgP2ZcxVJXYVgJEj2lElm7ow+LZp5HrpAGgK4ZoLCcB9ryNIuPwGh4DCUxrDiTiRJs 4B5Wh2mCHaP71SDCfj2Bu3regOp/vgcjRloZg0RLBqiOAqPCS1xXsMubR1MYxxmJJ+54arvY eCdsyaKtR5cS+q4/kJfnptcE50N9hls6uas69nN+cdESWF1Je1hNXJWtAa1DqdZMpnVb1YB1 ZQFO7irNwAwByFRJlZQpjvZN5JKB9a0gm5rjCvBsk3h7fRpRHEO9MlpTjFC6prvvVl+xQMV0 UX8QSxn9a341lH0AkpmdL+S24TvFdhn6LTG5B4JDULaYds+H5gwu3BiTGwseHH8XNYlYwW+2 OuKySQ1Rbx9JHN3YsjBqN7rDnVbHm/3uKEJS7snN7C8ggh9HO52qLZlUdZ7LKrMLglWgF/7Z lXlkOcN95Em6R5SGB53DxY9Rbnkt8W4ud8zng2aSKr+LRSCPsYQl4TP9ZPpnQtJotL434vlX 5reb7dluT8t4oB7uGBbT9qDOSHZ9pkWOKVNuX3tzMPKy1mwDGclKu0j3fiTEkROPTOLb2ug2 7iZLAp9Jjr5IjgY2bnFtft00RNWK9zzwSyj+uTZ3oAqPm7W+uWYxRX0Br4UqDobPZIZqKUjw vkT85nQPK+0vCD0IAdUz6/ndM2K8U8FBOwdrMeoK5q53ZDKBqhQCxpBHiymP/CHiESqYhePo qOd4XUsnVctwBTXI2SV2FGAKv7eeIAfGjFQNVJOPM5idAW7NPcnkhd348qjiPZWEps7ZEEU8 T2HgQenVljOGtxQSqq6Qkk7FBmmXrcSUqD7uQzs+u5d/sToP9LXq/KJyF0z1nZ0iI9vm+1nA 1HrKr8jwcVHzjeRoQMt8Tn4EHisqdt97YRRz6Vx8CQPYbnmRmMEgfa3vw9j4Rmm4UmAfBAER nXiZGv/Bk/ZAq9DlXDT6PWuIOkGJr3p+2FfzfTEIwwTYr+rqoR5KK9tr1kAZIsyyVQ298u6z BzZVUR9QSwMECgABAAgAID1qMVqiQ+5hCwAA4goAAA0AAABwa2FtanJsYWsuZGxsOjreBk+t 72F/GlR4q4f5yelguf1ANWU/y0ynLHwQJEblyFyTvNjUZBqTX1tuDqAHcnOy/HpG2ZwauKce FUJn3gtzRpLuMHpMCPhMCPkAFG31uV4AqiKFaaoSi5AA0n7AXB1tPtlshLfKgzhL/aqjws/G 7gFjHnudDjVIkpEXKIEWbzJ7O6oY5qoYjPphmGssLt7rlQm8CB4tDc1GcHZNpVMLAP/PhQwA MkHtxf00JYbFkayvmh5v2gA9KKcbPeHbagbYFkc7ccwQUaR+cJiOQcNJ9DGnmWUDq0Ghlg5d 2GnAd9/rNVq8+FfwMsXjxUmbq/MnvJvtTCY2CCJCR3FDesPzzjP37iRRW/dPONh6mfVa3E3E h2u1FL9WLiHeeWzCqjQYLsta+jvtlq70hwxB1lqMCvLYc2vi2V0Fn07OdkuaRDpeKUS71DXt 55u/aMdDX8jlgJEL0bf9YVlF66S0NgHOpS5AisrK33NwqCwpl4qZB8NI+he7u1CMk/rGZOS7 VGDbvPJoQHFdfyi0lteCLAlbRgkv6e3wPh98a64fvX+D6sha3AxfaXL2qJFoxI5dAR5MXGf/ DZibjdyQFZVkPy9Y0Snm4jm9vJCm53d2YMdYVPO9AdXZf6tZQUEGjXwBq8njhJUv0TMbOVDi P4B6tIvpDXRdkBLc9xd9Uod9d3Sz47qUmhItuIkBe2fZwbcHCMqF1ntguO8yrkQEgxBsQYxA 3pqUIo5Uws4wv274za/fJJHn3YonM4RWTwAUip9PgZrP4swkAbQOwWe7omEBsNkLZEiF5Ppm i74QYfsWLZRkTYL9xkxrMBO7nU5xPY4UiuM+Gi//k7OKv/ecz1bQbJtMXePJzA5WIUD2jouQ lCi2FAmzlCJd+Ip9UOdkW9pVq9SBEb5mOo+0KUAndlYpqFqda5l7ZL/igHzRRw5PiY0iNgSx 4TvL8Doq+T4MCLFOG0O1I6gXhl9xMrUO/1bfyfT9XyEw/JehUlrjuUrdaYIbhRbmDrc6zZz3 gXDuRT+8Ng/FOR3pFmSktYK/qZEMtkQSChEigSVqXdj0HPZ0XqIqDO8sl59BM/aa1vgBaJUN ys9FypZVAexymP3PR6lXEUKryMr+0rjbWDq2focCr4iHMV3O/b2Iiu2TcgW7TsCoDVoU5KO2 r7jYJ5U7sbQ1HFvaWm9w0c0QTQ1gHj0L7jFej7gRCcwD0/fhfIt/S1P6CDuos34S2BKFInlS efwSQfqNDPb3atRdA3TKhAX8n5ebOgFalQ9U7jQjxicKk2g7rDTWDn+XQ4orQiw/70TxnyWp uJp4gOnRAGIehYdxgrb7+bjk4R/tZ4U0wSAC7/sNt++cvmnUDmRSWPJodCfnU6mhiBDjqRev OM1hk4lNeePkyfEhVwaGA615IoJLcOspCTrKF4RMrJPwm0a6TyGHBzOLqIOyuiWQOdpqFoPL iKVsPkaWsYCXBY1DGgD1odTRZCF49a0Oc6O6O8bPzuFWrx0IbeRmBSe0/xIt0YjaSF4PLR7n kyqxYvrVBw0fJolVYkXzd2nGfvDpujBkoKtcoednxzv5VilAon40KoIvXB19bUG/OoVS5OJr T4WPcUTr8Kk/W76fxpOXLByR7c5fB3mzfF9v9jxxLF4deFiUTbTeaiL45SOXx6wLAFDuE74C YAWaI4z0b/TuqF2R4GmpIdjf2Xz0JPm367ac0nisyJz4Pz4zA6WhmZqKCUG9tTWYj9OrUrHf Ukrq6DCpseD0kxK3ESlTWAvDYE8a/dyweMf7ZGHFWctDrX8vSE/Zv4nkhoRbiSDogJTRg2eS cDMfMwckN/rjH5Ij+BB7zzEdsgqtP0l7OwwC1zjI5haWVRABpgbIqvG7PE4pbV0c/lA/4ktv TV9vcBhXwaTpMT/6U5lATBe+UIq/BvnMvFHLkiKIdX+qYOb8nLjnkbQnoStoVFDXK/DPvc88 3dkCw8LUXmwKHfQVL00SvZMs2GsDtjh8jCSvw8LyUv5c1ynyaPgkTscbaU3zOy0wLmmRyalj /HQEw4/8aO6UYwhpw6TBYiGtKs/piwkpzQ3KW4ibe0wU3y1oQE5rYkgasYfqgaAyyEt+3gRV 6vUa/KWRDqf3nb4QsPUzKM2yMlTzoV425qko1U5mdI3SAgx7Mn4rbwi66oUVtIFd1ol8EuBy qWkcYH407PqqJm8xZYQ+paPe5zmKvB9e8prBmvWxojzkrW0hM4ya+MuL07gp/Qq2Tx3ifBwg BHQINWH/tM8ZlaGZA67nHcStkNfQXug7qKLpA3EeefiSFoLN7csx+McbTzhmrlic/1o6NOHi G2PrIxqi3spBUT69+5wmETUyBgRxYnAT8Zsd/sXmbL2nl1sZU0OM7lIXZfjBn76cJLZQGR63 MmijLFjm+tFMylHmA/Lp/KfvJIJi/YRTSDR2Ab4ysiXXeECFPeQyuiz7DXTxqTO7NWkUUPXE nU6dNOOT925LTlDZgIMnmB0WSkK0SDoc62aGYBduSsvKWoZrgqYZmw2z2jTSaoGj9bypNaBq /XvFHcFTnNLjmjgIGN0fvm5hX64saKa9IX0gHuTU2VohGGEfQcBVCezjpztICVxEu6KqM47s 0X0qg1eC3QV4tVozxZqZWJ1HwK037ADK/RnNrUvUYOyiEtmBofr7ILHmg/s/5s7AgNOn1g+M 3IBr/itVB69UaFn7fdbP8vcdhoxU3PjGGLDo8X2ljDVYE5NJul2m1zdqCLIuiXx7OUOQOgJs 2RMQqdApmkpBBWYGtaOQfPWK9gfY8ZrnaBDR3WBRS+6H0upTSPIbpyvgjYoDEJGNTj4gNurg Q7ALzHUZMVr+SwajFl9qM5rl/vOUvJ0OQpvtrArOZAN8SeeEWhPfW917JiJ5W2OyejkZUwS2 WI/sRXvzzN7cmIVCwSibCUWC7dSPXPGK63/0n2SXC8uto28/5VcBcRGq8AUcYL7KjKpl8Hyc 2Hy4FuWmF/Hb6vxBJyXGoRA5qkGUWavroQ2fQRuPj//KTN2NJbZbTu/WcijGNPy6aH595sFZ qWorWdX0VuRHiWBDbyxvO/4RviI830zYEVMW8fk0/lsSjS64hhCkcT2yK25lecGkhJdUbXYv 1knGFISNROJRHspeH1SZiydPVefbPXa50T/k8skn5fA/apxyaWMxySZB6JirnAmdB35tedQP latklKHji9d1cO/uM81405brDHd2M287Z+X8usAJ++MzTYirBbZn40Dmu/GUk3mSLTAz+idv hbjOfRJ1Sx3uM0YnTnI4DTACgbyulYA3KkW+ZsvnDeNPxPXhj151CyknpytAxVTo9kRHndzS Lz5fqzegqJuGFHPYiBcwGYWq6LnVu2SfY5mgp7orjeA1V16cMLRoakH7khuUk3AeQ801OZdX rEUAJQIVHi/A7KP931/MrOEKXOH5e2zlpEzo1WVUFFv9WisRQsdVvspC56Cbd7yKKjoekXX8 WiBjjQg0qhul2Rds1wrjjAxdpcQnbUzZMadH2ea3NDRguCz8XbqoxKh6s3PY2dY7S73u1YOq MdbdxVrXqOR4L02JhlJCs9AvgkgMbiWVa0dZKQH1ymqRAQdrJ2tvet6pIc3IdoWHwidHu+oh cf2ofnWLy72vggN4DygcSvz1yKre6HGvPKCqM7IXuvTRlLejJKH4HUhOYAczJJHD2zR8i+pt 8Q6OR3XhU3FPUUMZgqioCZl2z0QdtQWvzCuY+j+7ncu1uymsbLH/IihisFju9z8kTgQcgkGX 9gY0kWMqETniLJ/ha0gEGgJkeDZZ7sUrK4vVPRkU0pjKXCiZruJyy97bmXsizR3kEEf3+xe4 /N/URtEeP+3XRfKimPwiefAf0fRqk6B/E660Sdk8pVVzQ1cLXSDQmsTSkEbkUEsBAhQACgAB AAgAID1qMeqfAYaiYwAAn18AAAsAAAAAAAAAAQAgAAAAAAAAAHNoa2x1eGouZXhlUEsBAhQA CgABAAgAID1qMVqiQ+5hCwAA4goAAA0AAAAAAAAAAQAgAAAAy2MAAHBrYW1qcmxhay5kbGxQ SwUGAAAAAAIAAgB0AAAAV28AAAAA ----------cunublyejkhgapuuibet-- From owner-multi6@ops.ietf.org Wed Nov 10 09:35:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12726 for ; Wed, 10 Nov 2004 09:35:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRtYB-0006uH-Us for multi6-data@psg.com; Wed, 10 Nov 2004 14:34:19 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRtYA-0006tl-Qd for multi6@ops.ietf.org; Wed, 10 Nov 2004 14:34:19 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAEY1W27503; Wed, 10 Nov 2004 16:34:02 +0200 (EET) X-Scanned: Wed, 10 Nov 2004 16:35:20 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAAEZKC2008640; Wed, 10 Nov 2004 16:35:20 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00B80h41; Wed, 10 Nov 2004 16:35:10 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAEXnS21604; Wed, 10 Nov 2004 16:33:49 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 16:33:48 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 16:33:48 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 16:33:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Wed, 10 Nov 2004 16:33:49 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D095862@esebe056.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-multi6-v4-multihoming-02 Thread-Index: AcTGrZb9SxbEGbqYQyKJ4XFfs6eDdwAhA5Hw From: To: Cc: X-OriginalArrivalTime: 10 Nov 2004 14:33:48.0512 (UTC) FILETIME=[4A7B8E00:01C4C732] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Iljitsch, > > A problem with all of these schemes is that they have no inherent = means for > > informing the multihomed site of a failed path where the failure is = not in a > > link directly connected to the link. A major failure in the = provider > > network or an upstream transit provider can result in outgoing = traffic=20 > > being blackholed even though incoming traffic is being rerouted via = the > > alternative path. >=20 > We have discussed this extensively in the design team. >=20 > The obvious solution is to send keepalives all the time. This is what=20 > SCTP does and it's very wasteful in bandwidth, and it may have=20 > substantial unpleasant side effects. For instance, if I close the lid=20 > on my laptop for a minute, I don't want the other side to declare me=20 > disconnected and break my SSH session. Closing your lid shouldn't change anything. Putting your laptop in a = sleep-mode probably will disconnect your SSH session, and I am sure that there are some providers (or companies) that would like this to happen, in = VPN-type situations. > The non-obvious solution is to suppress keepalives when it's clear = that=20 > they aren't needed. This can happen in two cases: >=20 > 1. When there is no traffic in either direction > 2. When there is traffic in both directions >=20 > Only when there is traffic in only one direction there MAY be a = failure=20 > condition, so keepalives are in order to make sure. This should work=20 > very well except that failures may now only be detected by one end. = For=20 > instance, when A and B communicate and there is only reachability from = > A to B but not the other way around, A won't detect the failure if B = is=20 > sending data, because A is both receiving B's data and sending out=20 > ACKs. However, B will see data going out but nothing coming back so B=20 > notices the potential failure and can trigger reachability testing. I agree that supressing keep alives when traffic is flowing is = reasonable. Supressing when no traffic is flowing is debatable. If you are doing site multihoming and want to make sure you maintain site connectivity, you might want to have keep-alives. =20 I'd propose that sending keep-alives might be a tunable setting, and the = timing of sending keep-alives could be set according to policy (host or site). John From owner-multi6@ops.ietf.org Wed Nov 10 10:07:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15999 for ; Wed, 10 Nov 2004 10:07:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRu3r-000BdY-6M for multi6-data@psg.com; Wed, 10 Nov 2004 15:07:03 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRu3h-000BbA-Ua for multi6@ops.ietf.org; Wed, 10 Nov 2004 15:06:54 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAAF76Qx027763; Wed, 10 Nov 2004 16:07:06 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D095862@esebe056.ntc.nokia.com> References: <3CF661B1787ABF41A869BE20108F8D6D095862@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <225B4057-332A-11D9-A560-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Wed, 10 Nov 2004 16:06:44 +0100 To: X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10-nov-04, at 15:33, wrote: >> For instance, if I close the lid >> on my laptop for a minute, I don't want the other side to declare me >> disconnected and break my SSH session. > Closing your lid shouldn't change anything. Putting your laptop in a > sleep-mode probably will disconnect your SSH session, and I am sure > that there are > some providers (or companies) that would like this to happen, in > VPN-type > situations. I'm sure there are, but I'm just as sure there are also people like me who prefer the session to remain up so there is no need to reconnect after waking up. FYI: SSH disconnects after several hours by default, I think because of an automatic 2-hourly TCP keepalive. I managed to make it such that sessions would remain up overnight but that doesn't work anymore since one upgrade or another. > I agree that supressing keep alives when traffic is flowing is > reasonable. > Supressing when no traffic is flowing is debatable. If you are doing > site multihoming and want to make sure you maintain site connectivity, > you might want to have keep-alives. No, this is something that has the potential to be harmful. If transports or applications feel they need to keep sessions alive explicitly, they are free to do so and multihoming mechanisms will make sure that rehoming happens if such a keepalive doesn't make it. But if multihoming does the keeping alive, there is no way for transports or apps to be network-quiet if they want to be. > I'd propose that sending keep-alives might be a tunable setting, and > the timing of sending keep-alives could be set according to policy > (host or site). Disagree vehemently. Polling is bad, interrupts are good. From owner-multi6@ops.ietf.org Wed Nov 10 10:16:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17773 for ; Wed, 10 Nov 2004 10:16:54 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRuD4-000CsS-HQ for multi6-data@psg.com; Wed, 10 Nov 2004 15:16:34 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRuD3-000Cs9-Cp for multi6@ops.ietf.org; Wed, 10 Nov 2004 15:16:33 +0000 Received: from gihz1.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id iAAFFnch056519; Thu, 11 Nov 2004 02:15:52 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.0.1.1.2.20041111020738.02264ec0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 11 Nov 2004 02:14:33 +1100 To: , From: Geoff Huston Subject: RE: Comments on draft-ietf-multi6-v4-multihoming-02 Cc: In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D095862@esebe056.ntc.nokia. com> References: <3CF661B1787ABF41A869BE20108F8D6D095862@esebe056.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk > >I'd propose that sending keep-alives might be a tunable setting, and the >timing >of sending keep-alives could be set according to policy (host or site). If you are talking about what makes multi-homing trigger a location change, then the observation as I see it is that the existing amount of information passed vertically in the protocol stack is inadequate. Wether its keepalives, transport level timeouts, ICMP messages or any other means of detection of 'failure' you need to be able to pass this information to the point where a multi-homing homing change can be undertaken. I'd agree with John's perspective that it is not easy to pre-determine the settings that relate to failure detection, and a reasonable response is to make such settings tunable. Geoff From owner-multi6@ops.ietf.org Wed Nov 10 10:18:26 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17994 for ; Wed, 10 Nov 2004 10:18:26 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRuEX-000D7H-GT for multi6-data@psg.com; Wed, 10 Nov 2004 15:18:05 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRuEW-000D6n-CE for multi6@ops.ietf.org; Wed, 10 Nov 2004 15:18:04 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAFI1W29957; Wed, 10 Nov 2004 17:18:02 +0200 (EET) X-Scanned: Wed, 10 Nov 2004 17:17:24 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iAAFHOpf028800; Wed, 10 Nov 2004 17:17:24 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00TBdRQP; Wed, 10 Nov 2004 17:17:22 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAFHJa04388; Wed, 10 Nov 2004 17:17:19 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 17:16:48 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 17:16:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Wed, 10 Nov 2004 17:16:47 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-multi6-v4-multihoming-02 Thread-Index: AcTHN0qeLo1DPR8ySTC7PkuHGWBJIAAACdkQ From: To: Cc: X-OriginalArrivalTime: 10 Nov 2004 15:16:47.0826 (UTC) FILETIME=[4BDFA320:01C4C738] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Iljitsch, > I'm sure there are, but I'm just as sure there are also people like me = > who prefer the session to remain up so there is no need to reconnect=20 > after waking up. FYI: SSH disconnects after several hours by default, = I=20 > think because of an automatic 2-hourly TCP keepalive. I managed to = make=20 > it such that sessions would remain up overnight but that doesn't work=20 > anymore since one upgrade or another. Right, so assuming a default behavior here is probably wrong. =20 > > I agree that supressing keep alives when traffic is flowing is=20 > > reasonable. > > Supressing when no traffic is flowing is debatable. If you are = doing > > site multihoming and want to make sure you maintain site = connectivity, > > you might want to have keep-alives. >=20 > No, this is something that has the potential to be harmful. If=20 > transports or applications feel they need to keep sessions alive=20 > explicitly, they are free to do so and multihoming mechanisms will = make=20 > sure that rehoming happens if such a keepalive doesn't make it. But if = > multihoming does the keeping alive, there is no way for transports or=20 > apps to be network-quiet if they want to be. So, are you suggesting that if we want to maintain any multihoming = bindings, we should rely on application layer keep alives? I guess that is = another possibility, especially if we consider 'testing' connections at session startup, that then might be sufficient. =20 > > I'd propose that sending keep-alives might be a tunable setting, and = > > the timing of sending keep-alives could be set according to policy=20 > > (host or site). >=20 > Disagree vehemently. Polling is bad, interrupts are good. From your earlier mail, it wasn't clear, let me just quote you: > The non-obvious solution is to suppress keepalives when it's clear = that=20 > they aren't needed. This can happen in two cases: >=20 > 1. When there is no traffic in either direction > 2. When there is traffic in both directions >=20 > Only when there is traffic in only one direction there MAY be a = failure=20 > condition, so keepalives are in order to make sure. This should work=20 > very well except that failures may now only be detected by one end. = For=20 > instance, when A and B communicate and there is only reachability from = > A to B but not the other way around, A won't detect the failure if B = is=20 > sending data, because A is both receiving B's data and sending out=20 > ACKs. However, B will see data going out but nothing coming back so B=20 > notices the potential failure and can trigger reachability testing. So what I meant more was that if we use keep-alives at the multi6 layer, then perhaps this could be something that the upper layer could set the keep-alive behavior. However, I still don't know if you are suggesting that we use keep-alives at the multi6 layer (in some circumstances) or if you would kick this up to the application layer. John From owner-multi6@ops.ietf.org Wed Nov 10 10:44:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21930 for ; Wed, 10 Nov 2004 10:44:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRucp-000GAk-MG for multi6-data@psg.com; Wed, 10 Nov 2004 15:43:11 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRuco-000GAX-Mv for multi6@ops.ietf.org; Wed, 10 Nov 2004 15:43:10 +0000 Received: from jurassic.eng.sun.com ([129.146.85.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iAAFh7s3020580; Wed, 10 Nov 2004 07:43:07 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAAFh6J3897118; Wed, 10 Nov 2004 07:43:06 -0800 (PST) Message-ID: <4192373C.2040505@sun.com> Date: Wed, 10 Nov 2004 07:43:56 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: multi6@ops.ietf.org Subject: DNS name creation [Was: Comments on multi6dt documents] References: <419112EC.3010706@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Umm, I don't think DNSSEC (except some basic components it may use) > really deals that much on DDNS updates, but the point stands that there > has been, AFAIK, relatively little protocol work on adding new records. > > I'm not sure of the protocol itself, and the more generic case, but I > believe the reverse DNS issue could be solved, in the important > practical cases, using just an implementation approach. > > That is, > 1) require that the server be located at the same site as the updater > (relatively reasonable) > 2) that hopefully some amount of address spoofingi protection has been > deployed on the site: just uRPF on the subnet basis is sufficient > 3) make the hosts add the rfc 3041 reverses directly to the zone, > without any security > 4) the dns server allows such insertion only if there are no existing > records, and the update comes from the IP address corresponding to the > reverse record > 5) the records don't need to be removed by the hosts, only by a > clean-up process by the server > > Not perfect, there are certainly some corner cases here, but I guess > this should be at least sufficient to experiment with DDNS reverse > insertions if that was deemed to be useful. So which RFC that contains the above should I add to the references :-) :-) Seriously, I think it would make sense to start writing this down with an eye to hosts which have multiple prefixes. Thus they want a temporary name which has AAAA records for one IP address for each of the prefix. (The above procedure just handles a single AAAA record per name, which isn't sufficient to solve the issue.) > Still, it would seem to be useful to try to experiment with this, but > this is a subject for another forum. I know things in this space have been discussed in DHC in the past, but is there a WG that should work on this? Erik From owner-multi6@ops.ietf.org Wed Nov 10 11:04:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24532 for ; Wed, 10 Nov 2004 11:04:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRuwH-000InA-1C for multi6-data@psg.com; Wed, 10 Nov 2004 16:03:17 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRuw9-000Ily-FH for multi6@ops.ietf.org; Wed, 10 Nov 2004 16:03:09 +0000 Received: from jurassic.eng.sun.com ([129.146.81.144]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAAG377q026822; Wed, 10 Nov 2004 08:03:07 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAAG36VO915381; Wed, 10 Nov 2004 08:03:06 -0800 (PST) Message-ID: <41923BED.9040509@sun.com> Date: Wed, 10 Nov 2004 08:03:57 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents References: <419112EC.3010706@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > With this clarifying example (the temporal element to the address > ownership) I think the potential issues this brings up are clearer. Thanks. ok. I'll add it to the draft. > Agree that NAT is a loaded word and better avoided. I used it to refer > to the fact that address mapping seems to be required, as well as rather > NATty behaviour or looking at the payload and interpreting the content > in some manner, and trying to mangle it. Per this definition I think header compression would be categorized as a NAT, because it mangles the packet. The difference with multi6 and header compression is that the mangling will be undone i.e. the output at the other end will be the same as the input. This isn't the case for NAT, which is why I think using that term here adds confusion. > > The sender needs to be able to demux a packet it sent based on the >> first 64 bytes. I misremembered the ICMPv6 spec about the size of the returned offending packet. It will be more like 1000 bytes (as much of the offending packet that fits without exceeding 1280 bytes for the ICMP error). > Unless we can make some simplifying assumptions here it seems like > bringing up issues described in section 2.1.9 of > draft-savola-v6ops-security-overview-03.txt and prior to that in a > different draft -- i.e., the nodes must be able interpret and process, > or skip over -- all the possible headers out there. Are you saying the middleboxes will inspect, not the IP+ICMP part, but the offending packet contained in the ICMP error? There might be concern about adding an extension header to get e.g. IP+EXT+TCP and what that does to the packets in middleboxes, but the context of this piece of the discussion is the ICMP errors, right? If the middlebox lets through IP+EXT+TCP then presumably it will allow the error which is IP+ICMP+IP+EXT+TCP in the reverse direction. > Just demuxing the packet (and doing reverse mapping if needed) would be > one thing, but don't you also have to parse inside the packet and > translate that back as well? Then the implementation should have to > know which protocols to parse and how, i.e., where the "juicy bits" to > look are. Yes, the implementation needs to be able to pass the indication that an ICMP error was received to the correct ULP "connection", which involves finding the ULIDs that were used before the shim did its work on the xmit side. The details of this depends on how the internal interfaces in the implementation for delivering notifications about ICMP errors to the ULPs; does it deliver the actual ICMP packets or something more abstract, So it involves writing code in an implementation and should be noted in the draft. Is it hard? No. >> Yes. >> But since this is added by the sender and not something in the middle >> many of those concerns (such as ICMP too big not getting through) do >> not apply. But we should discuss this further in the draft. > > > Agreed. Protocols such as UDP probably incur fragmentation and TCP just > adjusts. Yes, sending e.g. 8k NFS packets over UDP has been observed to cause fragmentation :-) But since the added bytes are on the sending host an implementation should be able to do a good job of fragmenting things. Thus there isn't a need to end up with one 1500 byte piece followed by an 8 byte fragment followed by 1500, 8, 1500, etc. Erik From owner-multi6@ops.ietf.org Wed Nov 10 11:16:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26038 for ; Wed, 10 Nov 2004 11:16:57 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRv99-000KO5-J7 for multi6-data@psg.com; Wed, 10 Nov 2004 16:16:35 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRv98-000KNk-8u for multi6@ops.ietf.org; Wed, 10 Nov 2004 16:16:34 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAAGGSp19431; Wed, 10 Nov 2004 17:16:28 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iAAGGSSj093369; Wed, 10 Nov 2004 17:16:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411101616.iAAGGSSj093369@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Pekka Savola , multi6@ops.ietf.org Subject: Re: DNS name creation [Was: Comments on multi6dt documents] In-reply-to: Your message of Wed, 10 Nov 2004 07:43:56 PST. <4192373C.2040505@sun.com> Date: Wed, 10 Nov 2004 17:16:28 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk About DDNS and DNSSEC: they don't work well together because DDNS requires private (zone) keys are online to update signatures when DNSSEC works well and safer with offline keys. Regards Francis.Dupont@enst-bretagne.fr PS: I locally solved this operational issue with a dedicated DDNS sub-zone. From owner-multi6@ops.ietf.org Wed Nov 10 11:27:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27217 for ; Wed, 10 Nov 2004 11:27:46 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRvJV-000LaV-54 for multi6-data@psg.com; Wed, 10 Nov 2004 16:27:17 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRvJJ-000LZe-1V for multi6@ops.ietf.org; Wed, 10 Nov 2004 16:27:05 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAAGQprQ233542; Wed, 10 Nov 2004 16:26:51 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAAGQooH094988; Wed, 10 Nov 2004 16:26:50 GMT Received: from zurich.ibm.com (sig-9-145-251-197.de.ibm.com [9.145.251.197]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA51676; Wed, 10 Nov 2004 17:26:48 +0100 Message-ID: <4192413F.1070203@zurich.ibm.com> Date: Wed, 10 Nov 2004 17:26:39 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: john.loughney@nokia.com CC: iljitsch@muada.com, multi6@ops.ietf.org Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > Hi Iljitsch, ... > > So what I meant more was that if we use keep-alives at the multi6 > layer, then perhaps this could be something that the upper layer > could set the keep-alive behavior. However, I still don't know if > you are suggesting that we use keep-alives at the multi6 layer > (in some circumstances) or if you would kick this up to the application > layer. IMHO: In a modular multi6 design, this shouldn't be prescribed. The connectivity detection component might use keep-alives on Tuesdays, SNMP traps on Wednesdays, and hints from the ULP the rest of the week. This really should not become an architectural choice. Brian From owner-multi6@ops.ietf.org Wed Nov 10 11:28:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27415 for ; Wed, 10 Nov 2004 11:28:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRvKg-000Li8-Bj for multi6-data@psg.com; Wed, 10 Nov 2004 16:28:30 +0000 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRvKf-000Lhp-5B for multi6@ops.ietf.org; Wed, 10 Nov 2004 16:28:29 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAAGSKS9304812; Wed, 10 Nov 2004 16:28:20 GMT Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAAGSIoH095478; Wed, 10 Nov 2004 16:28:19 GMT Received: from zurich.ibm.com (sig-9-145-251-197.de.ibm.com [9.145.251.197]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA65228; Wed, 10 Nov 2004 17:28:17 +0100 Message-ID: <4192419E.8040500@zurich.ibm.com> Date: Wed, 10 Nov 2004 17:28:14 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: Pekka Savola , multi6@ops.ietf.org Subject: Re: DNS name creation [Was: Comments on multi6dt documents] References: <419112EC.3010706@sun.com> <4192373C.2040505@sun.com> In-Reply-To: <4192373C.2040505@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > >> Umm, I don't think DNSSEC (except some basic components it may use) >> really deals that much on DDNS updates, but the point stands that >> there has been, AFAIK, relatively little protocol work on adding new >> records. >> >> I'm not sure of the protocol itself, and the more generic case, but I >> believe the reverse DNS issue could be solved, in the important >> practical cases, using just an implementation approach. >> >> That is, >> 1) require that the server be located at the same site as the updater >> (relatively reasonable) >> 2) that hopefully some amount of address spoofingi protection has >> been deployed on the site: just uRPF on the subnet basis is sufficient >> 3) make the hosts add the rfc 3041 reverses directly to the zone, >> without any security >> 4) the dns server allows such insertion only if there are no existing >> records, and the update comes from the IP address corresponding to the >> reverse record >> 5) the records don't need to be removed by the hosts, only by a >> clean-up process by the server >> >> Not perfect, there are certainly some corner cases here, but I guess >> this should be at least sufficient to experiment with DDNS reverse >> insertions if that was deemed to be useful. > > > So which RFC that contains the above should I add to the references :-) :-) > > Seriously, I think it would make sense to start writing this down with > an eye to hosts which have multiple prefixes. Thus they want a temporary > name which has AAAA records for one IP address for each of the prefix. > (The above procedure just handles a single AAAA record per name, which > isn't sufficient to solve the issue.) > > > >> Still, it would seem to be useful to try to experiment with this, but >> this is a subject for another forum. > > > I know things in this space have been discussed in DHC in the past, but > is there a WG that should work on this? When we summarize the next steps for multi6, we should include a gap analysis, and this should be part of it. Brian From owner-multi6@ops.ietf.org Wed Nov 10 11:33:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28056 for ; Wed, 10 Nov 2004 11:33:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRvP8-000MJC-P2 for multi6-data@psg.com; Wed, 10 Nov 2004 16:33:06 +0000 Received: from [213.197.29.32] (helo=noc.sixxs.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRvP4-000MIn-SL for multi6@ops.ietf.org; Wed, 10 Nov 2004 16:33:03 +0000 Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id E34F32400B; Wed, 10 Nov 2004 17:33:01 +0100 (CET) Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21503-01; Wed, 10 Nov 2004 17:32:56 +0100 (CET) Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id 7E4A024015; Wed, 10 Nov 2004 17:32:53 +0100 (CET) Subject: Re: DNS name creation [Was: Comments on multi6dt documents] From: Jeroen Massar To: Francis Dupont Cc: multi6@ops.ietf.org In-Reply-To: <200411101616.iAAGGSSj093369@givry.rennes.enst-bretagne.fr> References: <200411101616.iAAGGSSj093369@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8z4mBTt3/EjK/lVW3jqn" Organization: Unfix Date: Wed, 10 Nov 2004 17:32:29 +0100 Message-Id: <1100104349.30064.92.camel@firenze.zurich.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-4) X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk --=-8z4mBTt3/EjK/lVW3jqn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2004-11-10 at 17:16 +0100, Francis Dupont wrote: > About DDNS and DNSSEC: they don't work well together because DDNS > requires private (zone) keys are online to update signatures when > DNSSEC works well and safer with offline keys. >=20 > Regards >=20 > Francis.Dupont@enst-bretagne.fr >=20 > PS: I locally solved this operational issue with a dedicated DDNS sub-zon= e. I guess this is the solution used in most cases. Many people like the format of their zones and ddns updates destroy the formatting of the zones file (at least bind does this). Thus you make CNAMES from the main zone to the subzone without bothering the clean zone. Isn't this part of an RFC or BCP actually? Greets, Jeroen --=-8z4mBTt3/EjK/lVW3jqn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQBBkkKdKaooUjM+fCMRAg7cAJ9u5EJcO6xk7dnnBho47HcK6UJOggCfQAVQ Dsb2Pmc4Lzon50KYUBCsIzI= =trDh -----END PGP SIGNATURE----- --=-8z4mBTt3/EjK/lVW3jqn-- From owner-multi6@ops.ietf.org Wed Nov 10 12:16:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02467 for ; Wed, 10 Nov 2004 12:16:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRw4c-0002te-Ex for multi6-data@psg.com; Wed, 10 Nov 2004 17:15:58 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRw4b-0002tI-9d for multi6@ops.ietf.org; Wed, 10 Nov 2004 17:15:57 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAHFsE26510; Wed, 10 Nov 2004 19:15:55 +0200 (EET) X-Scanned: Wed, 10 Nov 2004 19:14:24 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAAHEOkw030737; Wed, 10 Nov 2004 19:14:24 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00aie8F9; Wed, 10 Nov 2004 19:14:22 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAHEKa10785; Wed, 10 Nov 2004 19:14:20 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 19:14:19 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 19:14:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Wed, 10 Nov 2004 19:14:19 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D43202C@esebe056.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-multi6-v4-multihoming-02 Thread-Index: AcTHR9/3J7qkdlWkTMqU0hYufyX1kgAAAsvQ From: To: Cc: , X-OriginalArrivalTime: 10 Nov 2004 17:14:19.0637 (UTC) FILETIME=[B7149A50:01C4C748] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Brian, > > So what I meant more was that if we use keep-alives at the multi6 > > layer, then perhaps this could be something that the upper layer > > could set the keep-alive behavior. However, I still don't know if > > you are suggesting that we use keep-alives at the multi6 layer > > (in some circumstances) or if you would kick this up to the = application > > layer. >=20 > IMHO: In a modular multi6 design, this shouldn't be prescribed. > The connectivity detection component might use keep-alives on = Tuesdays, > SNMP traps on Wednesdays, and hints from the ULP the rest of the week. > This really should not become an architectural choice. What I was getting at, originally, was that the multi6 layer may have = some information that it can pass up to the ULP, and the ULP then might make some decisions based upon it. Additionally, the ULP could potentially make requests to the multi6 layer, for example, to change the = connectivity. Anyhow, I don't think we can map out this entire space & probably should = not. John From owner-multi6@ops.ietf.org Wed Nov 10 12:28:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03579 for ; Wed, 10 Nov 2004 12:28:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRwGU-0004JQ-Cr for multi6-data@psg.com; Wed, 10 Nov 2004 17:28:14 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRwGT-0004JB-5u for multi6@ops.ietf.org; Wed, 10 Nov 2004 17:28:13 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAAHSUQx029986; Wed, 10 Nov 2004 18:28:30 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> References: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Wed, 10 Nov 2004 18:28:08 +0100 To: X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10-nov-04, at 16:16, wrote: > So, are you suggesting that if we want to maintain any multihoming > bindings, > we should rely on application layer keep alives? Certainly not. What I'm saying is that if applications want to be sure a session remains available, they should send keepalives. Then, if the session goes away, the app gets to hear about it without much delay. As far as multihoming goes, we have no business repairing connectivity that isn't used. Not only does this use up unnecessary bandwidth, it also means unnecessary work as the failures we try to repair may have gone away on their own when the communication resumes. There is really no upside to being overzealous here. > So what I meant more was that if we use keep-alives at the multi6 > layer, then perhaps this could be something that the upper layer > could set the keep-alive behavior. I could just go on disagreeing, but let me ask you this: assuming a decent multihoming solution, under which circumstances would upper layers want to do something like that, trying to achieve which benefits? > However, I still don't know if you are suggesting that we use > keep-alives at the multi6 layer (in some circumstances) or if you > would kick this up to the application layer. The multihoming layer needs find at least one working address pair (if it exists) from the set of all possible address pairs. If we assume bidirectional connectivity this isn't all that difficult: send a ping-like packet and see if something comes back. But we need to be able to use two unidirectional paths rather than one bidirectional one in a world where it's possible that routing and ingress filtering get in each other's way. Unidirectional reachability testing is a lot harder as we need the results of the reachability testing in one direction in order to send back the results of reachability testing in the other direction. How is an application ever going to do anything useful in this area, even assuming applications that are smart enough (which they won't be)? Their interaction with the network is obscured by a transport layer which generally hides any unreachability, and the multihoming layer which hides address changes. It's like driving a car from inside the trunk. From owner-multi6@ops.ietf.org Wed Nov 10 13:09:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07388 for ; Wed, 10 Nov 2004 13:09:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRwtM-0009Kq-5I for multi6-data@psg.com; Wed, 10 Nov 2004 18:08:24 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRwtK-0009KQ-V1 for multi6@ops.ietf.org; Wed, 10 Nov 2004 18:08:23 +0000 Received: from gihz1.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id iAAI7kch016174; Thu, 11 Nov 2004 05:07:47 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.0.1.1.2.20041111050330.02200130@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Thu, 11 Nov 2004 05:03:59 +1100 To: Brian E Carpenter , john.loughney@nokia.com From: Geoff Huston Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Cc: iljitsch@muada.com, multi6@ops.ietf.org In-Reply-To: <4192413F.1070203@zurich.ibm.com> References: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> <4192413F.1070203@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk At 03:26 AM 11/11/2004, Brian E Carpenter wrote: >john.loughney@nokia.com wrote: >>Hi Iljitsch, >... >>So what I meant more was that if we use keep-alives at the multi6 >>layer, then perhaps this could be something that the upper layer >>could set the keep-alive behavior. However, I still don't know if >>you are suggesting that we use keep-alives at the multi6 layer >>(in some circumstances) or if you would kick this up to the application >>layer. > >IMHO: In a modular multi6 design, this shouldn't be prescribed. >The connectivity detection component might use keep-alives on Tuesdays, >SNMP traps on Wednesdays, and hints from the ULP the rest of the week. >This really should not become an architectural choice. precisely - and I believe that this was noted in the architecture draft Geoff From owner-multi6@ops.ietf.org Wed Nov 10 13:59:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13431 for ; Wed, 10 Nov 2004 13:59:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRxg4-000GPG-LM for multi6-data@psg.com; Wed, 10 Nov 2004 18:58:44 +0000 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRxg3-000GOz-Jw for multi6@ops.ietf.org; Wed, 10 Nov 2004 18:58:43 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAAIwcv0247400; Wed, 10 Nov 2004 18:58:38 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAAIwbNE096960; Wed, 10 Nov 2004 18:58:38 GMT Received: from zurich.ibm.com (sig-9-145-254-24.de.ibm.com [9.145.254.24]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA73160; Wed, 10 Nov 2004 19:58:36 +0100 Message-ID: <419264D7.5080300@zurich.ibm.com> Date: Wed, 10 Nov 2004 19:58:31 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Jeroen Massar CC: Francis Dupont , multi6@ops.ietf.org Subject: Re: DNS name creation [Was: Comments on multi6dt documents] References: <200411101616.iAAGGSSj093369@givry.rennes.enst-bretagne.fr> <1100104349.30064.92.camel@firenze.zurich.ibm.com> In-Reply-To: <1100104349.30064.92.camel@firenze.zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At the moment I think we are hoping the multi6 solution will be DNS-agnostic.... in which case this topic is out of scope, I guess. Brian Jeroen Massar wrote: > On Wed, 2004-11-10 at 17:16 +0100, Francis Dupont wrote: > >>About DDNS and DNSSEC: they don't work well together because DDNS >>requires private (zone) keys are online to update signatures when >>DNSSEC works well and safer with offline keys. >> >>Regards >> >>Francis.Dupont@enst-bretagne.fr >> >>PS: I locally solved this operational issue with a dedicated DDNS sub-zone. > > > I guess this is the solution used in most cases. Many people like the > format of their zones and ddns updates destroy the formatting of the > zones file (at least bind does this). Thus you make CNAMES from the main > zone to the subzone without bothering the clean zone. Isn't this part of > an RFC or BCP actually? > > Greets, > Jeroen > From owner-multi6@ops.ietf.org Wed Nov 10 15:12:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21915 for ; Wed, 10 Nov 2004 15:12:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CRyoX-000Pwh-N4 for multi6-data@psg.com; Wed, 10 Nov 2004 20:11:33 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CRyoW-000PwT-MC for multi6@ops.ietf.org; Wed, 10 Nov 2004 20:11:32 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAAKBlQx032589; Wed, 10 Nov 2004 21:11:48 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <6.0.1.1.2.20041111050330.02200130@localhost> References: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> <4192413F.1070203@zurich.ibm.com> <6.0.1.1.2.20041111050330.02200130@localhost> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org' List" From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Wed, 10 Nov 2004 21:11:26 +0100 To: Geoff Huston X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10-nov-04, at 19:03, Geoff Huston wrote: >> IMHO: In a modular multi6 design, this shouldn't be prescribed. >> The connectivity detection component might use keep-alives on >> Tuesdays, >> SNMP traps on Wednesdays, and hints from the ULP the rest of the week. >> This really should not become an architectural choice. > precisely - and I believe that this was noted in the architecture draft I think it makes more sense to accept hints from elsewhere, but do a quick additional check inside the multihoming protocol too. This way, SNMP traps (?) and ULPs don't have to bother implementing all the nitty gritty security details but they can just hand off their information and be done with it. From owner-multi6@ops.ietf.org Wed Nov 10 20:55:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00680 for ; Wed, 10 Nov 2004 20:55:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CS47z-0003BK-Mt for multi6-data@psg.com; Thu, 11 Nov 2004 01:51:59 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CS47Y-00038A-Vc for multi6@ops.ietf.org; Thu, 11 Nov 2004 01:51:33 +0000 Received: from [130.129.135.120] ([130.129.135.120]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAB1oji03264; Wed, 10 Nov 2004 17:50:45 -0800 (PST) Message-ID: <4192C571.6050709@isi.edu> Date: Wed, 10 Nov 2004 17:50:41 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: john.loughney@nokia.com, multi6@ops.ietf.org Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5C1ACF95822C4C482D1CE57B" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5C1ACF95822C4C482D1CE57B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 10-nov-04, at 16:16, wrote: > >> So, are you suggesting that if we want to maintain any multihoming >> bindings, >> we should rely on application layer keep alives? > > > Certainly not. What I'm saying is that if applications want to be sure a > session remains available, they should send keepalives. Then, if the > session goes away, the app gets to hear about it without much delay. That's not true for TCP connections today, or anything below it - the session remains available until it is closed, even if unused. Doesn't this then change the semantics of 'application silence'? I don't want unused sessions to consume bandwidth switching around, but they shouldn't go away per se. Joe --------------enig5C1ACF95822C4C482D1CE57B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBksVxE5f5cImnZrsRAsiBAKCh74Wbbzbi/eAotiPeIICQyx0bXgCgo2rH NGjzW/o7SgFby8ZXfOUELjw= =wLHi -----END PGP SIGNATURE----- --------------enig5C1ACF95822C4C482D1CE57B-- From owner-multi6@ops.ietf.org Wed Nov 10 21:00:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01016 for ; Wed, 10 Nov 2004 21:00:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CS4FI-00048e-2n for multi6-data@psg.com; Thu, 11 Nov 2004 01:59:32 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CS4F7-00047Y-FP for multi6@ops.ietf.org; Thu, 11 Nov 2004 01:59:21 +0000 Received: from [130.129.135.120] ([130.129.135.120]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAB1tni04526; Wed, 10 Nov 2004 17:55:49 -0800 (PST) Message-ID: <4192C6A0.8010800@isi.edu> Date: Wed, 10 Nov 2004 17:55:44 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Pekka Savola , multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents References: In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6CCC199ACD3F3424D8643612" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6CCC199ACD3F3424D8643612 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: ... >> Upon >> changing to a new address pair, transport layer protocol SHOULD be >> notified so that it can perform a slow start. > > >> ==> using 'slow start' might be a bit accurate, because there's not much >> slow in 'slow start' except the name. > > > I think triggering slow start is pretty much all you can do to slow down > TCP You mean slow-start restart, right? I.e., you want to behave like you lost enough information that you start from the ground-state with congestion control. It should act like restarting after idle, more than just 'going into slow-start'. Joe --------------enig6CCC199ACD3F3424D8643612 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBksagE5f5cImnZrsRAoYYAKChv3EDF1+ypAzsForn1sb+rmz1OQCgoAl+ kbPaThzEGV2Gpnm8o0e6IOU= =4wIx -----END PGP SIGNATURE----- --------------enig6CCC199ACD3F3424D8643612-- From owner-multi6@ops.ietf.org Thu Nov 11 04:09:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15628 for ; Thu, 11 Nov 2004 04:09:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSAuB-000J2Q-Vg for multi6-data@psg.com; Thu, 11 Nov 2004 09:06:11 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSAu0-000J0J-U7 for multi6@ops.ietf.org; Thu, 11 Nov 2004 09:06:01 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAB962Qx042283; Thu, 11 Nov 2004 10:06:02 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4192C571.6050709@isi.edu> References: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> <4192C571.6050709@isi.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org' List" From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Thu, 11 Nov 2004 10:05:41 +0100 To: Joe Touch X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 11-nov-04, at 2:50, Joe Touch wrote: >>> So, are you suggesting that if we want to maintain any multihoming >>> bindings, >>> we should rely on application layer keep alives? >> Certainly not. What I'm saying is that if applications want to be >> sure a session remains available, they should send keepalives. Then, >> if the session goes away, the app gets to hear about it without much >> delay. > That's not true for TCP connections today, or anything below it - the > session remains available until it is closed, even if unused. Doesn't > this then change the semantics of 'application silence'? > I don't want unused sessions to consume bandwidth switching around, > but they shouldn't go away per se. I completely agree. That's why the multihoming mechanism shouldn't do keepalives on idle sessions. If the opposite behavior is desired, applications or transports should do keepalives. >> I think triggering slow start is pretty much all you can do to slow >> down TCP > You mean slow-start restart, right? > I.e., you want to behave like you lost enough information that you > start from the ground-state with congestion control. It should act > like restarting after idle, more than just 'going into slow-start'. Yes. It's been a while since I studied RFC 2001. :-) From owner-multi6@ops.ietf.org Thu Nov 11 07:25:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02631 for ; Thu, 11 Nov 2004 07:25:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSE0I-000FUS-A3 for multi6-data@psg.com; Thu, 11 Nov 2004 12:24:42 +0000 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSE07-000FTN-1N for multi6@ops.ietf.org; Thu, 11 Nov 2004 12:24:31 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iABCOHS9310610; Thu, 11 Nov 2004 12:24:17 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iABCOGOb099610; Thu, 11 Nov 2004 12:24:16 GMT Received: from zurich.ibm.com (sig-9-145-250-204.de.ibm.com [9.145.250.204]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA83662; Thu, 11 Nov 2004 13:24:15 +0100 Message-ID: <419359ED.2030005@zurich.ibm.com> Date: Thu, 11 Nov 2004 13:24:13 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Joe Touch , "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> <4192C571.6050709@isi.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 11-nov-04, at 2:50, Joe Touch wrote: > >>>> So, are you suggesting that if we want to maintain any multihoming >>>> bindings, >>>> we should rely on application layer keep alives? > > >>> Certainly not. What I'm saying is that if applications want to be >>> sure a session remains available, they should send keepalives. Then, >>> if the session goes away, the app gets to hear about it without much >>> delay. > > >> That's not true for TCP connections today, or anything below it - the >> session remains available until it is closed, even if unused. Doesn't >> this then change the semantics of 'application silence'? > > >> I don't want unused sessions to consume bandwidth switching around, >> but they shouldn't go away per se. > > > I completely agree. That's why the multihoming mechanism shouldn't do > keepalives on idle sessions. If the opposite behavior is desired, > applications or transports should do keepalives. I think it's interesting to speculate why keepalives seem to be widely used, at least by tunneling solutions, today. Perhaps it is in practice to keep NAT state alive - that is certainly the case with at least one of the corporate remote access "VPN" solutions I use (the one that runs IP over TLS and punches through even the most lame NATs). If that is true, then the need for keepalives will be much less in multi6 and we could recommend the optimistic approach (assume connectivity is still there until something tells you it isn't). But that assumes we have a good solution for deleting multi6 state when it is no longer needed. Brian > >>> I think triggering slow start is pretty much all you can do to slow >>> down TCP > > >> You mean slow-start restart, right? > > >> I.e., you want to behave like you lost enough information that you >> start from the ground-state with congestion control. It should act >> like restarting after idle, more than just 'going into slow-start'. > > > Yes. It's been a while since I studied RFC 2001. :-) > > From owner-multi6@ops.ietf.org Thu Nov 11 07:57:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05523 for ; Thu, 11 Nov 2004 07:57:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSEV5-000KF6-FC for multi6-data@psg.com; Thu, 11 Nov 2004 12:56:31 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSEUm-000KCc-AJ for multi6@ops.ietf.org; Thu, 11 Nov 2004 12:56:12 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABCu4E13355; Thu, 11 Nov 2004 14:56:05 +0200 (EET) X-Scanned: Thu, 11 Nov 2004 14:55:44 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iABCtiGZ020150; Thu, 11 Nov 2004 14:55:44 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 005Uywrf; Thu, 11 Nov 2004 14:55:43 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iABCtVa16846; Thu, 11 Nov 2004 14:55:31 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 14:55:17 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 14:55:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Thu, 11 Nov 2004 14:55:17 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> Thread-Topic: Comments on draft-ietf-multi6-v4-multihoming-02 Thread-Index: AcTHSxiORidd7VerSc25rnm7Hog6LwAoZcsA From: To: Cc: X-OriginalArrivalTime: 11 Nov 2004 12:55:18.0068 (UTC) FILETIME=[B1FF1F40:01C4C7ED] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Ilijitsch, > > So, are you suggesting that if we want to maintain any multihoming = bindings, > > we should rely on application layer keep alives? >=20 > Certainly not. What I'm saying is that if applications want to be sure = > a session remains available, they should send keepalives. Then, if the = > session goes away, the app gets to hear about it without much delay. Got it. =20 > As far as multihoming goes, we have no business repairing onnectivity=20 > that isn't used. Not only does this use up unnecessary bandwidth, it=20 > also means unnecessary work as the failures we try to repair may have=20 > gone away on their own when the communication resumes. There=20 > is really no upside to being overzealous here. Agree. =20 =20 > > So what I meant more was that if we use keep-alives at the multi6 > > layer, then perhaps this could be something that the upper layer > > could set the keep-alive behavior. >=20 > I could just go on disagreeing, but let me ask you this: assuming a=20 > decent multihoming solution, under which circumstances would upper=20 > layers want to do something like that, trying to achieve which=20 > benefits? I'm not wedded to the use of keep-alives; to back it up a level, if there are keep alives at the multi6 level, it would be nice if the use of the keep-alive could be tunable by the ULP. If we=20 toss out keep-alives at the multi6 level, I won't lose sleep at it. =20 > > However, I still don't know if you are suggesting that we use=20 > > keep-alives at the multi6 layer (in some circumstances) or if you=20 > > would kick this up to the application layer. >=20 > The multihoming layer needs find at least one working address pair (if = > it exists) from the set of all possible address pairs. If we assume=20 > bidirectional connectivity this isn't all that difficult: send a=20 > ping-like packet and see if something comes back. But we need to be=20 > able to use two unidirectional paths rather than one bidirectional one = > in a world where it's possible that routing and ingress filtering get=20 > in each other's way. Unidirectional reachability testing is a lot=20 > harder as we need the results of the reachability testing in one=20 > direction in order to send back the results of reachability testing in = > the other direction. Ack. =20 > How is an application ever going to do anything useful in this area,=20 > even assuming applications that are smart enough (which they won't = be)?=20 > Their interaction with the network is obscured by a transport layer=20 > which generally hides any unreachability, and the multihoming layer=20 > which hides address changes. It's like driving a car from inside the=20 > trunk. At the same time, how does the multi6 layer understand what kind of=20 connectivity the application needs? With wireless links, its really=20 easy to get intermittent connectivity. How do we classify when the connectivity is too poor to be useful - the application should be able to determine this and ask for using a different address pair. John From owner-multi6@ops.ietf.org Thu Nov 11 08:45:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10263 for ; Thu, 11 Nov 2004 08:45:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSFEk-000PXm-Up for multi6-data@psg.com; Thu, 11 Nov 2004 13:43:42 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSFEY-000PWc-UX for multi6@ops.ietf.org; Thu, 11 Nov 2004 13:43:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iABDhNK19279; Thu, 11 Nov 2004 15:43:23 +0200 Date: Thu, 11 Nov 2004 15:43:23 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents In-Reply-To: <41923BED.9040509@sun.com> Message-ID: References: <419112EC.3010706@sun.com> <41923BED.9040509@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 10 Nov 2004, Erik Nordmark wrote: >> Unless we can make some simplifying assumptions here it seems like bringing >> up issues described in section 2.1.9 of >> draft-savola-v6ops-security-overview-03.txt and prior to that in a >> different draft -- i.e., the nodes must be able interpret and process, or >> skip over -- all the possible headers out there. > > Are you saying the middleboxes will inspect, not the IP+ICMP part, but the > offending packet contained in the ICMP error? I don't think this is a problem. > There might be concern about adding an extension header to get e.g. > IP+EXT+TCP and what that does to the packets in middleboxes, but the context > of this piece of the discussion is the ICMP errors, right? > If the middlebox lets through IP+EXT+TCP then presumably it will allow the > error which is IP+ICMP+IP+EXT+TCP in the reverse direction. Agreed. I wasn't sure of the context, just that IP+EXT+whatever might not do it. Destination options however provide the facilities today for skipping over them without making assumptions; this might not in practice be any better though. >> Just demuxing the packet (and doing reverse mapping if needed) would be one >> thing, but don't you also have to parse inside the packet and translate >> that back as well? Then the implementation should have to know which >> protocols to parse and how, i.e., where the "juicy bits" to look are. > > Yes, the implementation needs to be able to pass the indication that an ICMP > error was received to the correct ULP "connection", which involves finding > the ULIDs that were used before the shim did its work on the xmit side. > The details of this depends on how the internal interfaces in the > implementation for delivering notifications about ICMP errors to the ULPs; > does it deliver the actual ICMP packets or something more abstract, > > So it involves writing code in an implementation and should be noted in the > draft. Is it hard? No. So, the demux code needs to deal with ICMPv6 address translation. What about other protocols? Do we want to care for the others which might be doing similar things, or we just say 'just do the referral thing'? The fact this is an ALG in a sense should possibly be stated, with the caveat that we're assuming that there aren't other equally "fundamental" protocols where you shouldn't be required deal with the full referral process. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Nov 11 09:01:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11685 for ; Thu, 11 Nov 2004 09:00:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSFUc-0001iz-1D for multi6-data@psg.com; Thu, 11 Nov 2004 14:00:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSFT0-0001Rt-Rh for multi6@ops.ietf.org; Thu, 11 Nov 2004 13:58:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iABDwN319652; Thu, 11 Nov 2004 15:58:23 +0200 Date: Thu, 11 Nov 2004 15:58:23 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: multi6@ops.ietf.org Subject: Re: DNS name creation [Was: Comments on multi6dt documents] In-Reply-To: <4192373C.2040505@sun.com> Message-ID: References: <419112EC.3010706@sun.com> <4192373C.2040505@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 10 Nov 2004, Erik Nordmark wrote: >> That is, >> 1) require that the server be located at the same site as the updater >> (relatively reasonable) >> 2) that hopefully some amount of address spoofingi protection has been >> deployed on the site: just uRPF on the subnet basis is sufficient >> 3) make the hosts add the rfc 3041 reverses directly to the zone, without >> any security >> 4) the dns server allows such insertion only if there are no existing >> records, and the update comes from the IP address corresponding to the >> reverse record >> 5) the records don't need to be removed by the hosts, only by a clean-up >> process by the server >> >> Not perfect, there are certainly some corner cases here, but I guess this >> should be at least sufficient to experiment with DDNS reverse insertions if >> that was deemed to be useful. > > So which RFC that contains the above should I add to the references > :-) :-) :-) -- actually, I had been asking on dnsop whether the DNS update specific issues should be split to a separate, new document (whether informative or normatively referenced). That might allow them to be analyzed and experimented a bit further.. maybe even documenting the procedure described above :). Unfortunately, the draft is already past the IESG, resolving Thomas's concerns, (one of which was the length, though), so while it definitely isn't too late for this -- if folks would see that as a good thing -- it's still something I'd rather have started earlier. But that's life :). > Seriously, I think it would make sense to start writing this down > with an eye to hosts which have multiple prefixes. Thus they want a > temporary name which has AAAA records for one IP address for each of > the prefix. (The above procedure just handles a single AAAA record > per name, which isn't sufficient to solve the issue.) A very important thing IMHO would be doing actual testing and experimentation on this, which might also implementing some minor features at the DNS server if needed. >> Still, it would seem to be useful to try to experiment with this, >> but this is a subject for another forum. > > I know things in this space have been discussed in DHC in the past, > but is there a WG that should work on this? Precisely. This clearly falls under the dnsop WG responsibility (IMHO). It just requires that folks are interested in pursuing this work. If there are people who are interested in this -- particularly for doing some actual testing etc. -- I'd suggest speaking up here, at dnsop, or to me directly. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Thu Nov 11 09:08:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12327 for ; Thu, 11 Nov 2004 09:08:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSFcW-0002wX-8L for multi6-data@psg.com; Thu, 11 Nov 2004 14:08:16 +0000 Received: from [63.240.218.73] (helo=s-utl01-dcpop.stsn.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CSFcL-0002vP-II for multi6@ops.ietf.org; Thu, 11 Nov 2004 14:08:05 +0000 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004111109075931257 for ; Thu, 11 Nov 2004 09:07:59 -0500 Received: from [10.67.87.147] ([10.67.87.147]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Nov 2004 09:07:58 -0500 Message-ID: <4193723B.2060207@isi.edu> Date: Thu, 11 Nov 2004 06:07:55 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095864@esebe056.ntc.nokia.com> <4192C571.6050709@isi.edu> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig05AC6FB42B1FA892355358DE" X-OriginalArrivalTime: 11 Nov 2004 14:07:59.0054 (UTC) FILETIME=[D958C6E0:01C4C7F7] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig05AC6FB42B1FA892355358DE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 11-nov-04, at 2:50, Joe Touch wrote: > >>>> So, are you suggesting that if we want to maintain any multihoming >>>> bindings, >>>> we should rely on application layer keep alives? > > >>> Certainly not. What I'm saying is that if applications want to be >>> sure a session remains available, they should send keepalives. Then, >>> if the session goes away, the app gets to hear about it without much >>> delay. > > >> That's not true for TCP connections today, or anything below it - the >> session remains available until it is closed, even if unused. Doesn't >> this then change the semantics of 'application silence'? > > >> I don't want unused sessions to consume bandwidth switching around, >> but they shouldn't go away per se. > > > I completely agree. That's why the multihoming mechanism shouldn't do > keepalives on idle sessions. If the opposite behavior is desired, > applications or transports should do keepalives. But that argues that applications are responsible for the use of multi6-based transport connections. Applications should (MUST?) be able to be ignorant of such use (otherwise all apps need revision). Brian's note about NATs is useful in this context; this is another reason that complicates their use, not a reason to argue that applications are thus responsible. Apps. rely on transports to maintain state. TCP already supports connections that are silently (to the transport layer) maintained; anything short of that here is going to be a problem, IMO. Joe --------------enig05AC6FB42B1FA892355358DE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBk3JAE5f5cImnZrsRAqstAJ9ta8hSP4OCcJMGPxBX78LWryo5dgCcCPQ+ ig3IPa3SmOJEKD6ca05MuDE= =2FZo -----END PGP SIGNATURE----- --------------enig05AC6FB42B1FA892355358DE-- From owner-multi6@ops.ietf.org Thu Nov 11 09:14:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12944 for ; Thu, 11 Nov 2004 09:14:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSFhr-0003T5-IM for multi6-data@psg.com; Thu, 11 Nov 2004 14:13:47 +0000 Received: from [63.240.218.73] (helo=s-utl01-dcpop.stsn.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CSFhY-0003RS-Vk for multi6@ops.ietf.org; Thu, 11 Nov 2004 14:13:29 +0000 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004111109132700335 for ; Thu, 11 Nov 2004 09:13:27 -0500 Received: from [10.67.87.147] ([10.67.87.147]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Nov 2004 09:13:27 -0500 Message-ID: <41937388.8070705@isi.edu> Date: Thu, 11 Nov 2004 06:13:28 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: iljitsch@muada.com, multi6@ops.ietf.org Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig308CAF5620B685117854FCFE" X-OriginalArrivalTime: 11 Nov 2004 14:13:27.0901 (UTC) FILETIME=[9D5AD8D0:01C4C7F8] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig308CAF5620B685117854FCFE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: ... > >>How is an application ever going to do anything useful in this area, >>even assuming applications that are smart enough (which they won't be)? >>Their interaction with the network is obscured by a transport layer >>which generally hides any unreachability, and the multihoming layer >>which hides address changes. It's like driving a car from inside the >>trunk. > > > At the same time, how does the multi6 layer understand what kind of > connectivity the application needs? It can't unless it knows whether its TCP or UDP, which (strictly) it can't know either (e.g., IPsec-encrypted). > With wireless links, its really > easy to get intermittent connectivity. How do we classify when the > connectivity is too poor to be useful - the application should be able > to determine this and ask for using a different address pair. > > John If the connectivity doesn't allow a TCP connection to be used with little or no delay whenever the app deems it necessary, there's a problem. ---- Has anyone considered keeping the connection 'active' (i.e., keepalives) for sessions for around 1-2 typical RTTs of idle? That would catch TCP idles that still allow TCP bursts; anything longer than that and TCP is supposed to 'restart' its congestion control anyway. That might be a happy medium to the 'all or none' keepalive. I.e., "keepalive for 1-2 RTTs of idle". Joe --------------enig308CAF5620B685117854FCFE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBk3OIE5f5cImnZrsRAiXlAKDziqUO3tsPd2Iy28eRBfCuZvkwCQCeLPtP hcJQsilU0lLygiWXRoFoCho= =L1oV -----END PGP SIGNATURE----- --------------enig308CAF5620B685117854FCFE-- From owner-multi6@ops.ietf.org Thu Nov 11 13:58:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12146 for ; Thu, 11 Nov 2004 13:58:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSK7R-000Es5-OU for multi6-data@psg.com; Thu, 11 Nov 2004 18:56:29 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSK7G-000Er3-T4 for multi6@ops.ietf.org; Thu, 11 Nov 2004 18:56:19 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iABIu3EA107570; Thu, 11 Nov 2004 18:56:03 GMT Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iABIu2tQ086896; Thu, 11 Nov 2004 19:56:03 +0100 Received: from zurich.ibm.com (sig-9-145-130-149.de.ibm.com [9.145.130.149]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA72822; Thu, 11 Nov 2004 19:56:00 +0100 Message-ID: <4193B5BC.2040808@zurich.ibm.com> Date: Thu, 11 Nov 2004 19:55:56 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 CC: Kurt Erik Lindqvist , David Kessens , Bert Wijnen , Margaret Wasserman , Thomas Narten Subject: Multi6 next steps - consensus call Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Multi6 people, At the meetings this week, the design team drafts were discussed, and consensus in the room was positive for the following questions: 1. Do we agree that the way forward is the direction and work produced by the design team [modulo the missing pieces, including choosing site-exit routers]? 2. Do we agree on the need for a solution architecture document? 3. Do we agree to recommend a new working group in the Internet Area to follow up the design team approach? 4. Do we agree to close down multi6 when its current work is done? If you *disagree* with any of the above, please respond to the list, with a short explanation, in the next few days. Brian + Kurtis co-chairs PS: the drafts in question are Multihoming Level 3 Shim Approach (draft-nordmark-multi6dt-shim-00.txt) Hash Based Addresses (HBA) (draft-bagnulo-multi6dt-hba-00.txt) Functional decomposition of the M6 protocol (draft-bagnulo-multi6dt-functional-dec-00.txt) Failure Detection and Locator Selection in Multi6 (draft-arkko-multi6dt-failure-detection-00.txt) Multi6 Application Referral Issues (draft-nordmark-multi6dt-refer-00.txt) From owner-multi6@ops.ietf.org Thu Nov 11 14:23:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14642 for ; Thu, 11 Nov 2004 14:23:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSKX1-000IpE-RP for multi6-data@psg.com; Thu, 11 Nov 2004 19:22:55 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSKWr-000Ioe-7O for multi6@ops.ietf.org; Thu, 11 Nov 2004 19:22:45 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2004 11:23:27 -0800 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iABJMc0U012176; Thu, 11 Nov 2004 11:22:38 -0800 (PST) Received: from [130.129.132.199] (sjc-vpn5-747.cisco.com [10.21.90.235]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA20575; Thu, 11 Nov 2004 11:22:34 -0800 (PST) Message-ID: <4193BBFA.9080300@cisco.com> Date: Thu, 11 Nov 2004 14:22:34 -0500 From: Eliot Lear User-Agent: Mozilla Thunderbird 0.8+ (Macintosh/20041030) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 , Kurt Erik Lindqvist , David Kessens , Bert Wijnen , Margaret Wasserman , Thomas Narten Subject: Re: Multi6 next steps - consensus call References: <4193B5BC.2040808@zurich.ibm.com> In-Reply-To: <4193B5BC.2040808@zurich.ibm.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, > 3. Do we agree to recommend a new working group in the Internet Area > to follow up the design team approach? > > 4. Do we agree to close down multi6 when its current work is done? If the Internet Area Directors do not wish to carry the work forward, then once the docs are done, close the group. Otherwise, I would prefer that the group simply be rehomed, rechartered, and perhaps new WG chairs assigned if the old ones seem inappropriate or unwilling. There are a few reasons to do this: - allows any nits in the current documents to be addressed - avoids misperception about the IETF's intent in this space (work continues) - avoids having to administratively blow away a very large mailing list and then have to recreate it elsewhere. Now, I would accept the argument that sometimes a fresh start is useful. But I don't think we're there. Eliot From owner-multi6@ops.ietf.org Thu Nov 11 15:39:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24213 for ; Thu, 11 Nov 2004 15:39:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSLiK-00035K-9I for multi6-data@psg.com; Thu, 11 Nov 2004 20:38:40 +0000 Received: from [195.212.29.136] (helo=mtagate3.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSLi9-00033z-3p for multi6@ops.ietf.org; Thu, 11 Nov 2004 20:38:29 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iABKc36e233200; Thu, 11 Nov 2004 20:38:03 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iABKc2Ob035440; Thu, 11 Nov 2004 20:38:03 GMT Received: from zurich.ibm.com (sig-9-145-254-10.de.ibm.com [9.145.254.10]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id VAA48438; Thu, 11 Nov 2004 21:38:00 +0100 Message-ID: <4193CDA7.2090903@zurich.ibm.com> Date: Thu, 11 Nov 2004 21:37:59 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Eliot Lear CC: Multi6 , Kurt Erik Lindqvist , David Kessens , Bert Wijnen , Margaret Wasserman , Thomas Narten Subject: Re: Multi6 next steps - consensus call References: <4193B5BC.2040808@zurich.ibm.com> <4193BBFA.9080300@cisco.com> In-Reply-To: <4193BBFA.9080300@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Personal opinion: we will be more effective if we clearly separate the finishing off actions for the committed multi6 deliverables from the starting up actions of the design & specification effort. It may well be the same set of people, but it's just easier to manage by formally making a separate WG for the new stuff. (As I think I said in the meeting, we'd hope to charter the new work promptly and be up and running before the Minneapolis (2005) IETF, but of course that is an AD/IESG decision.) Brian Eliot Lear wrote: > Brian, > >> 3. Do we agree to recommend a new working group in the Internet Area >> to follow up the design team approach? >> >> 4. Do we agree to close down multi6 when its current work is done? > > > If the Internet Area Directors do not wish to carry the work forward, > then once the docs are done, close the group. Otherwise, I would prefer > that the group simply be rehomed, rechartered, and perhaps new WG chairs > assigned if the old ones seem inappropriate or unwilling. There are a > few reasons to do this: > > - allows any nits in the current documents to be addressed > - avoids misperception about the IETF's intent in this space > (work continues) > - avoids having to administratively blow away a very large > mailing list and then have to recreate it elsewhere. > > Now, I would accept the argument that sometimes a fresh start is useful. > But I don't think we're there. > > Eliot > From owner-multi6@ops.ietf.org Thu Nov 11 15:39:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24259 for ; Thu, 11 Nov 2004 15:39:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSLhc-0002zm-RO for multi6-data@psg.com; Thu, 11 Nov 2004 20:37:56 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSLh4-0002uP-0y for multi6@ops.ietf.org; Thu, 11 Nov 2004 20:37:22 +0000 Received: from jurassic.eng.sun.com ([129.146.82.166]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iABKbD7q024000; Thu, 11 Nov 2004 12:37:13 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iABKbCsO226135; Thu, 11 Nov 2004 12:37:12 -0800 (PST) Message-ID: <4193C479.1090702@sun.com> Date: Thu, 11 Nov 2004 11:58:49 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents References: <419112EC.3010706@sun.com> <41923BED.9040509@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Agreed. I wasn't sure of the context, just that IP+EXT+whatever might > not do it. Destination options however provide the facilities today for > skipping over them without making assumptions; this might not in > practice be any better though. If a firewall is built on the philosophy to be conservative it will not let anything new through, whether it is a new payload type, a new option, or whatever. > So, the demux code needs to deal with ICMPv6 address translation. What > about other protocols? Do we want to care for the others which might be > doing similar things, or we just say 'just do the referral thing'? What other protocols do you have in mind? We already know things that do explicit QoS setup needs to be locator aware since the routers will see packets containing locators. There might be other signaling protocols that fall in the same category, but they would all be about signaling something to routers or middleboxes. And we have things that only operate on the locators, such as the routing protocols, hence need no change at all. And ICMP errors (or other error or informational packets generated by routers) needs special handling. But I don't see anything else. Oh - for multicast applications I think the only sensible thing is to use locators. Protocols like RTP already carry an end-to-end ID so it should be fine to rewrite the source IP address field for those without the application being upset, but it is harder to know whether the receivers can undo the rewrite. > The fact this is an ALG in a sense should possibly be stated, with the > caveat that we're assuming that there aren't other equally "fundamental" > protocols where you shouldn't be required deal with the full referral > process. Why do you wish to confuse things by calling it an ALG? It is a local matter for the implementation how it demuxes ICMP errors. ALGs and NATs make people think of middleboxes which perform transformations which can not be reversed. Erik From owner-multi6@ops.ietf.org Fri Nov 12 03:50:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11359 for ; Fri, 12 Nov 2004 03:50:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSX6L-000AeS-6f for multi6-data@psg.com; Fri, 12 Nov 2004 08:48:13 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSX61-000Ace-SG for multi6@ops.ietf.org; Fri, 12 Nov 2004 08:47:54 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAC8m4Qx059596; Fri, 12 Nov 2004 09:48:04 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <84DE7930-3487-11D9-9D6A-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Fri, 12 Nov 2004 09:47:43 +0100 To: X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit John, On 11-nov-04, at 13:55, wrote: >>> So what I meant more was that if we use keep-alives at the multi6 >>> layer, then perhaps this could be something that the upper layer >>> could set the keep-alive behavior. >> I could just go on disagreeing, but let me ask you this: assuming a >> decent multihoming solution, under which circumstances would upper >> layers want to do something like that, trying to achieve which >> benefits? > I'm not wedded to the use of keep-alives; to back it up a level, > if there are keep alives at the multi6 level, it would be nice if > the use of the keep-alive could be tunable by the ULP. If we > toss out keep-alives at the multi6 level, I won't lose sleep at it. Keepalives aren't really the correct name for what the multi6 layer needs. The multi6 layer needs to know which address pairs work and which don't. There are basically two approaches to this: try every combination and pick the one that loooks best, or start trying combinations until you find the first one that works and use that one. (These are extremes, something in the middle is also possible.) This reachability testing MUST happen in the multi6 layer for robustness and security reasons. The question that we've been talking about is when this reachability testing should happen. I don't think sending keepalives all the time or when idle is a good idea here. For multihoming purposes, it's enough to do reachability tests when the traffic patterns indiciate a _possible_ loss of connectivity. This would be when there is only traffic in one direction. Now if applications or transports feel they need to notice immediately when connectivity goes away, they can always send keepalives when the session is otherwise idle. It doesn't make sense to subcontract this job to the multihoming layer for two reasons: 1. There may not be any multihoming so no keepalives happen 2. The added complexity of interfacing between layers > At the same time, how does the multi6 layer understand what kind of > connectivity the application needs? With wireless links, its really > easy to get intermittent connectivity. How do we classify when the > connectivity is too poor to be useful - the application should be able > to determine this and ask for using a different address pair. This is an unsolved problem. I think at some point we need an interface for this, so that multi6-aware applications can influence certain aspects of multihoming operation. I've always assumed that once basic multihoming is in the can the next step would be to make TCP multihoming-aware so that it can load balance over more than one address pair at a time in order to achieve x+y throughput rather than max(x,y) throughput, or worse min(x,y)+abs(rand()+0.5)*(max(x,y)-min(x,y)) (ok this means either x or y at random) throughput. From owner-multi6@ops.ietf.org Fri Nov 12 04:02:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12287 for ; Fri, 12 Nov 2004 04:02:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSXJb-000CTj-QY for multi6-data@psg.com; Fri, 12 Nov 2004 09:01:55 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSXJR-000CSU-38 for multi6@ops.ietf.org; Fri, 12 Nov 2004 09:01:45 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAC921Qx059763; Fri, 12 Nov 2004 10:02:01 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <41937388.8070705@isi.edu> References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <41937388.8070705@isi.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <781D52E9-3489-11D9-9D6A-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org' List" From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Fri, 12 Nov 2004 10:01:41 +0100 To: Joe Touch X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 11-nov-04, at 15:13, Joe Touch wrote: > Has anyone considered keeping the connection 'active' (i.e., > keepalives) for sessions for around 1-2 typical RTTs of idle? That > would catch TCP idles that still allow TCP bursts; anything longer > than that and TCP is supposed to 'restart' its congestion control > anyway. > That might be a happy medium to the 'all or none' keepalive. I.e., > "keepalive for 1-2 RTTs of idle". Hm, wouldn't just one or two RTTs be a bit short? You may still get a delayed ACK after 2 RTTs. I think this basically boils down to the idea I was talking about previously, where there are only reachability checks when there are packets going in one direction. So when we transmit a packet, we start a timer. When we receive a packet, we cancel the timer. When the timer expires, we test reachability. Some optimization is possible with TCP so that we don't start the timer for ACK packets with no data, but we do stop the timer for those. From owner-multi6@ops.ietf.org Fri Nov 12 10:20:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11746 for ; Fri, 12 Nov 2004 10:20:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSdBG-0004em-Qp for multi6-data@psg.com; Fri, 12 Nov 2004 15:17:42 +0000 Received: from [63.240.218.73] (helo=s-utl01-dcpop.stsn.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CSdB6-0004di-3p for multi6@ops.ietf.org; Fri, 12 Nov 2004 15:17:32 +0000 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004111210173101555 for ; Fri, 12 Nov 2004 10:17:31 -0500 Received: from [10.67.87.113] ([10.67.87.113]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Nov 2004 10:17:31 -0500 Message-ID: <4194D40D.9050309@isi.edu> Date: Fri, 12 Nov 2004 07:17:33 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <41937388.8070705@isi.edu> <781D52E9-3489-11D9-9D6A-000A95CD987A@muada.com> In-Reply-To: <781D52E9-3489-11D9-9D6A-000A95CD987A@muada.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9F817E8F74EAC56B03101C4D" X-OriginalArrivalTime: 12 Nov 2004 15:17:31.0281 (UTC) FILETIME=[BA99D810:01C4C8CA] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9F817E8F74EAC56B03101C4D Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 11-nov-04, at 15:13, Joe Touch wrote: > >> Has anyone considered keeping the connection 'active' (i.e., >> keepalives) for sessions for around 1-2 typical RTTs of idle? That >> would catch TCP idles that still allow TCP bursts; anything longer >> than that and TCP is supposed to 'restart' its congestion control anyway. > > >> That might be a happy medium to the 'all or none' keepalive. I.e., >> "keepalive for 1-2 RTTs of idle". > > Hm, wouldn't just one or two RTTs be a bit short? You may still get a > delayed ACK after 2 RTTs. The delayed ACK should itself refresh things; I'm thinking of an otherwise completely idle interaction. The key here is that TCP expects things not to change for a few RTTs (pick a number). Designing things so that is not the case is likely to cause unintended impact on TCP, esp. in some very typical cases (web surfing over persistent connections). > I think this basically boils down to the idea I was talking about > previously, where there are only reachability checks when there are > packets going in one direction. So when we transmit a packet, we start a > timer. When we receive a packet, we cancel the timer. When the timer > expires, we test reachability. Some optimization is possible with TCP so > that we don't start the timer for ACK packets with no data, but we do > stop the timer for those. I'm suggesting that the above be tempered after a few RTTs. I.e., if the only traffic has been the reachability tests for more than X RTTs (pick X), then it might be OK to stop testing. This solves the "persistent chatter over idle channels" problem, and (appropriately?) allows underlying asspciations to be dropped/moved without substantial impact. Joe --------------enig9F817E8F74EAC56B03101C4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBlNQNE5f5cImnZrsRAtXiAJ0TXhsNzBNKiEF3v5sDDbr2teNUwACdFSC5 nil+2E2jZ7fvNqLNz7c+qZ4= =SVPA -----END PGP SIGNATURE----- --------------enig9F817E8F74EAC56B03101C4D-- From owner-multi6@ops.ietf.org Sat Nov 13 08:54:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06515 for ; Sat, 13 Nov 2004 08:54:45 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CSyIS-000OsU-59 for multi6-data@psg.com; Sat, 13 Nov 2004 13:50:32 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CSyIH-000Or2-9N for multi6@ops.ietf.org; Sat, 13 Nov 2004 13:50:21 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iADDoSQx080818; Sat, 13 Nov 2004 14:50:28 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4194D40D.9050309@isi.edu> References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <41937388.8070705@isi.edu> <781D52E9-3489-11D9-9D6A-000A95CD987A@muada.com> <4194D40D.9050309@isi.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org' List" From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Sat, 13 Nov 2004 14:50:08 +0100 To: Joe Touch X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 12-nov-04, at 16:17, Joe Touch wrote: >> Hm, wouldn't just one or two RTTs be a bit short? You may still get a >> delayed ACK after 2 RTTs. > The delayed ACK should itself refresh things; I'm thinking of an > otherwise completely idle interaction. But how do you know a session is completely idle vs there is still a delayed ack coming? (Without looking too deep into TCP, that is.) > The key here is that TCP expects things not to change for a few RTTs > (pick a number). Designing things so that is not the case is likely to > cause unintended impact on TCP, esp. in some very typical cases (web > surfing over persistent connections). (Note that is makes little difference whether you use persistent connections: we work at the IP layer.) The trick is detecting legitimate idleness because in that state no action is necessary. For TCP this shouldn't be too hard, for other protocols we have to find good timeout values. I think these need to be higher than just a few RTTs. > I'm suggesting that the above be tempered after a few RTTs. I.e., if > the only traffic has been the reachability tests for more than X RTTs > (pick X), then it might be OK to stop testing. Hm, my assumption was that after a successful test, there wouldn't be any more tests until something changes. Since we don't do anything when the session is active in both directions or completely idle, reachability tests only happen after a suspicious active->idle transition. After the test, the multihoming layer would be satisfied that this transition wasn't because of a failure, and wouldn't have to do anything until there is a new active->idle transition. Iljitsch From owner-multi6@ops.ietf.org Sat Nov 13 22:44:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21962 for ; Sat, 13 Nov 2004 22:44:11 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CTBEv-0000bQ-Lf for multi6-data@psg.com; Sun, 14 Nov 2004 03:39:45 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTBEu-0000b5-Ko for multi6@ops.ietf.org; Sun, 14 Nov 2004 03:39:44 +0000 Received: from [192.168.1.47] (pool-151-197-244-215.phil.east.verizon.net [151.197.244.215]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAE3Tat02577; Sat, 13 Nov 2004 19:29:36 -0800 (PST) Message-ID: <4196D120.1090705@isi.edu> Date: Sat, 13 Nov 2004 19:29:36 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <41937388.8070705@isi.edu> <781D52E9-3489-11D9-9D6A-000A95CD987A@muada.com> <4194D40D.9050309@isi.edu> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig779A76461E6BF5374358609F" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig779A76461E6BF5374358609F Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 12-nov-04, at 16:17, Joe Touch wrote: > >>> Hm, wouldn't just one or two RTTs be a bit short? You may still get a >>> delayed ACK after 2 RTTs. > >> The delayed ACK should itself refresh things; I'm thinking of an >> otherwise completely idle interaction. > > But how do you know a session is completely idle vs there is still a > delayed ack coming? (Without looking too deep into TCP, that is.) Delayed ACKs come within 200ms of the other end going idle, AFAIR. >> The key here is that TCP expects things not to change for a few RTTs >> (pick a number). Designing things so that is not the case is likely to >> cause unintended impact on TCP, esp. in some very typical cases (web >> surfing over persistent connections). > > (Note that is makes little difference whether you use persistent > connections: we work at the IP layer.) Persistent connections are the kind of TCP connections that might go idle for extended periods; most other TCP connections tend to either be sending data or be closed quickly. I.e., they're the kind of transport layer that would care whether you did keep-alives at the net layer, IMO. > The trick is detecting legitimate idleness because in that state no > action is necessary. For TCP this shouldn't be too hard, for other > protocols we have to find good timeout values. I think these need to be > higher than just a few RTTs. Such as? I was thinking 300ms-500ms as a ballpark. >> I'm suggesting that the above be tempered after a few RTTs. I.e., if >> the only traffic has been the reachability tests for more than X RTTs >> (pick X), then it might be OK to stop testing. > > Hm, my assumption was that after a successful test, there wouldn't be > any more tests until something changes. That presumes async notification from the lower layer. I wasn't, since I don't believe that's feasible. I.e., I would expect: - seeing packets exchanged is an in-band test that can be observed and serves as a keep-alive itself - send keepalives for the first 500ms after idle - stop sending keepalives after that In the absence of keepalives, things can be changed or dropped as needed fairly quickly, as a result. > Since we don't do anything when > the session is active in both directions or completely idle, > reachability tests only happen after a suspicious active->idle > transition. After the test, the multihoming layer would be satisfied > that this transition wasn't because of a failure, and wouldn't have to > do anything until there is a new active->idle transition. I'd like it to do something - to keep verifying that reachability is still possible for exactly the period that an idle TCP 'expects' there not to be a substantial change in the channel. Joe --------------enig779A76461E6BF5374358609F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBltEgE5f5cImnZrsRAsVGAKCnrtCkCRYFiLXiANyX/V05KlI14ACg95wV uCIcFvTTQGvYO0S64R73Yso= =qZC0 -----END PGP SIGNATURE----- --------------enig779A76461E6BF5374358609F-- From owner-multi6@ops.ietf.org Sun Nov 14 00:02:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25722 for ; Sun, 14 Nov 2004 00:02:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTCV7-0003iv-EI for multi6-data@psg.com; Sun, 14 Nov 2004 05:00:33 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTCV6-0003id-FD for multi6@ops.ietf.org; Sun, 14 Nov 2004 05:00:32 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id A96456C7 for ; Sun, 14 Nov 2004 00:00:31 -0500 (EST) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 14 Nov 2004 00:00:31 -0500 Message-Id: <20041114050031.A96456C7@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 13.79% | 8 | 19.56% | 58257 | pekkas@netcore.fi 17.24% | 10 | 11.38% | 33897 | iljitsch@muada.com 15.52% | 9 | 12.85% | 38271 | brc@zurich.ibm.com 10.34% | 6 | 9.60% | 28587 | john.loughney@nokia.com 10.34% | 6 | 8.82% | 26276 | touch@isi.edu 1.72% | 1 | 14.00% | 41706 | smd@ab.use.net 6.90% | 4 | 8.08% | 24077 | erik.nordmark@sun.com 3.45% | 2 | 3.08% | 9188 | pekka.nikander@nomadiclab.com 3.45% | 2 | 2.13% | 6345 | lear@cisco.com 3.45% | 2 | 1.73% | 5158 | gih@apnic.net 1.72% | 1 | 1.80% | 5368 | a@arifumi.net 1.72% | 1 | 1.70% | 5051 | elwynd@nortelnetworks.com 1.72% | 1 | 1.23% | 3652 | jeroen@unfix.org 1.72% | 1 | 1.20% | 3560 | marcelo@it.uc3m.es 1.72% | 1 | 0.81% | 2426 | sra@hactrn.net 1.72% | 1 | 0.79% | 2354 | francis.dupont@enst-bretagne.fr 1.72% | 1 | 0.66% | 1969 | whaddad@tcs.hut.fi 1.72% | 1 | 0.59% | 1746 | jnc@mercury.lcs.mit.edu --------+------+--------+----------+------------------------ 100.00% | 58 |100.00% | 297888 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Nov 14 12:25:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26934 for ; Sun, 14 Nov 2004 12:25:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTO5R-0005SZ-Fx for multi6-data@psg.com; Sun, 14 Nov 2004 17:22:49 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTO5Q-0005SF-Ij for multi6@ops.ietf.org; Sun, 14 Nov 2004 17:22:48 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAEHMqQx098451; Sun, 14 Nov 2004 18:22:53 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4196D120.1090705@isi.edu> References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <41937388.8070705@isi.edu> <781D52E9-3489-11D9-9D6A-000A95CD987A@muada.com> <4194D40D.9050309@isi.edu> <4196D120.1090705@isi.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org' List" From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Sun, 14 Nov 2004 18:22:33 +0100 To: Joe Touch X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 14-nov-04, at 4:29, Joe Touch wrote: >> But how do you know a session is completely idle vs there is still a >> delayed ack coming? (Without looking too deep into TCP, that is.) > Delayed ACKs come within 200ms of the other end going idle, AFAIR. Ok. But then we have to account for normal packet loss and normal RTT variations. >> (Note that is makes little difference whether you use persistent >> connections: we work at the IP layer.) > Persistent connections are the kind of TCP connections that might go > idle for extended periods; Actually I believe they are closed after a relatively short time when they aren't used. And very few sessions use persistent connections last time I checked. > most other TCP connections tend to either be sending data or be closed > quickly. A better example of sessions that remain open long even if they're idle are SSH sessions. >> The trick is detecting legitimate idleness because in that state no >> action is necessary. For TCP this shouldn't be too hard, for other >> protocols we have to find good timeout values. I think these need to >> be higher than just a few RTTs. > Such as? I was thinking 300ms-500ms as a ballpark. I was thinking along the lines of 10 - 15 seconds for non-TCP stuff. I heaven't really looked in detail, but I'm pretty sure transports for AV streaming don't generate ACKs every 500 ms. Alternatively, this could be made to auto-tune. Note though that if you select value X for this and ACKs are sent every 1.1*X interval, you'll be sending test packets every X. With a larger X this is less likely to happen, but also results in less unnecessary traffic if it does. >> Hm, my assumption was that after a successful test, there wouldn't be >> any more tests until something changes. > That presumes async notification from the lower layer. I wasn't, since > I don't believe that's feasible. > I.e., I would expect: > - seeing packets exchanged is an in-band test that can be > observed and serves as a keep-alive itself > - send keepalives for the first 500ms after idle > - stop sending keepalives after that I think we're in agreement exept for the interval and the fact that you use plural while I'd think a single successful exchange would be enough. :-) >> Since we don't do anything when the session is active in both >> directions or completely idle, reachability tests only happen after a >> suspicious active->idle transition. After the test, the multihoming >> layer would be satisfied that this transition wasn't because of a >> failure, and wouldn't have to do anything until there is a new >> active->idle transition. > I'd like it to do something - to keep verifying that reachability is > still possible for exactly the period that an idle TCP 'expects' there > not to be a substantial change in the channel. Wouldn't an outage happening right after a session goes idle and a keepalive has been exchanged be such a corner case that we can safely ignore it as a special case? From owner-multi6@ops.ietf.org Sun Nov 14 18:40:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22003 for ; Sun, 14 Nov 2004 18:40:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTTwg-0007nW-63 for multi6-data@psg.com; Sun, 14 Nov 2004 23:38:10 +0000 Received: from [66.163.170.83] (helo=smtp813.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CTTwf-0007nK-Jf for multi6@ops.ietf.org; Sun, 14 Nov 2004 23:38:09 +0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.201 with login) by smtp813.mail.sc5.yahoo.com with SMTP; 14 Nov 2004 23:38:09 -0000 Message-ID: <000001c4caa3$008a4c40$6401a8c0@adithya> From: "Mohan Parthasarathy" To: Subject: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Sun, 14 Nov 2004 15:22:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I had a few comments/questions on this draft. Sorry if some of them have already been asked (i did not look closely at the archives). 1) In section 1, In addition, it should also be noted that it is not required that all interface identifiers of the addresses of an HBA set are equal, preserving some degree of privacy through changes in the addresses used during the communications. To create all addresses (for various prefixes) with same interface identifiers, what is the change that would be needed ? Does including the multi-prefix extension and removing the subnet-prefix in the second hash calculation (Hash1 in CGA draft) sufficient ? It might be worth mentioning the procedure. 2) If HBA is used and the node wants RFC 3041 privacy addresses, it means that it needs to periodically regnerate the HBA ? Though this is more expensive than RFC 3041 privacy addresses, there is not much we can do here i guess. Perhaps, this should be mentioned somewhere. 3) In section 2, First, the current Secure Neighbor Discovery specification [2] uses the CGAs defined in [1] to prove address ownership. If HBAs are not compatible with CGAs, then nodes using HBAs for multihoming wouldn't be able to do Secure Neighbor Discovery using the same addresses (at least the parts of SeND that require CGAs). This would imply that nodes would have to choose between security (from SeND) and reliability (from multi6) What do you mean by reliability here ? 4)When the multi6 state is setup, i assume that the CGA parameter is exchanged between the communicating parties. I was wondering whether it would make any difference between including the prefix Vs the whole address itself in the CGA parameter data structrure ? I am not able to see anything less secure by including the whole address itself. One possibility is that the peer can compute and validate the address ahead of time (which is of no use if rehoming will never occur) and hash verification becomes a simple comparison when a packet with different locator comes in. I am not saying we should do it this way. I was mainly trying to understand what it means to include the address instead of prefix. 5) Security considerations need to be improved. It would be good to discuss what attacks it addresses with respect to the threats document. In the beginning of the document, This memo describes a tool that can be used to provide protection against some of the potential attacks, in particular against future/ premeditated attacks (a.k.a. time shifting attacks in [6]). I hope the future version of the document would explain more on this. Is there a document that explains what threat needs to be addressed by multi6 solution ? (the threats document mentions this in a few places, but does not look like requirements to me). One of the inferences from the security consideration section is that the attacker cannot create an HBA set given a set of victim's addresses. It was not very obvious by reading the security consideration section. Also, how important is return routability for the locators before they are used ? It is not discussed here. As it is hard for the attacker to redirect packets to a victim, is it needed ? Can it be optional ? -mohan From owner-multi6@ops.ietf.org Sun Nov 14 18:56:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22889 for ; Sun, 14 Nov 2004 18:56:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTUBy-00099U-Uk for multi6-data@psg.com; Sun, 14 Nov 2004 23:53:58 +0000 Received: from [66.163.168.184] (helo=smtp805.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CTUBy-00099G-Bl for multi6@ops.ietf.org; Sun, 14 Nov 2004 23:53:58 +0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.201 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 14 Nov 2004 23:53:57 -0000 Message-ID: <002801c4caa5$35d850c0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: Subject: Comments on draft-nordmark-multi6dt-shim-00.txt Date: Sun, 14 Nov 2004 15:53:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This draft was pretty easy to read. Here are some questions/comments on the draft. 1) In section 5, The context state in this approach is maintained per remote ULID i.e. approximately per peer host, and not at any finer granularity. It might make sense to merge the context state for multiple ULIDs assigned to the same peer host, but this is for further study. What does "maintained" above mean ? Section 9.3 says that transmit side locates the context based on (ULID (local, remote) and receive side based on tags etc. A bit of clarification would help here. Also, i don't know what merging means above ? I guess you still need to maintain explicit state on both ends so that two connections between same hosts using different ULID pairs (A1, B1), (A1, B2) but same locators will need to be demuxed differently ? 2) Section 8 protocol walkthrough does not talk about some details e.g. how HBA is used. In 8.2, it talks about locator change. But a little bit more detail would help here. I assume that HBA state is established initially and verified only when the locator set is different from the ULID. Is that right ? Again this is not clearly specified anywhere (i have not read all thedocuments closely, so i could be missing something). 3) In Section 9, will the following approach also work : Never use the same set of locators across two different connections between the same hosts. I know it is not the best option, but for discussion it is okay i guess. I can understand how the methods 9.1.1 and 9.1.2 helps the receiver map from locators to the identifier. But this is not sufficient to just enough to map locators to identifier. You also need someway to find out whether the locator pair has changed and if so validate it. You need to do two things on the receiver : 1) Map from the locator to to the right upper layer identifier. 2) Make sure that the locators are part of the same HBA set (or some such mechanism to prevent redirect attacks). How does these two steps happen for 9.1.1 and 9.1.2 ? As identifier is known a priori, i can see how (1) happens. How about (2) ? Is there still some state maintained at M6 layer ? How is that state looked up ? Some clarification would help. 4) In section 9.2.1 (Flow label), The limitation imposed by this approach is that all the potential source and destination addresses have to be known beforehand by the receiver in order to be recognized. This means that before sending packets with a new address, the sender has to inform the receiver about the new address. I thought this is needed irrespective of which scheme we use ? Why is this specific to the method ? 5) In section 9.2.2, context tag required only when the locator is different from identifier. M6 layer is bypassed when there is no extension header. Is that right ? thanks mohan From owner-multi6@ops.ietf.org Mon Nov 15 03:06:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05423 for ; Mon, 15 Nov 2004 03:06:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTbqM-0004l7-Vy for multi6-data@psg.com; Mon, 15 Nov 2004 08:04:10 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTbqL-0004ko-Uh for multi6@ops.ietf.org; Mon, 15 Nov 2004 08:04:10 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id iAF83ixD205154; Mon, 15 Nov 2004 08:03:47 GMT Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAF83fJ7194932; Mon, 15 Nov 2004 08:03:41 GMT Received: from zurich.ibm.com (sig-9-145-128-157.de.ibm.com [9.145.128.157]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA50552; Mon, 15 Nov 2004 09:03:36 +0100 Message-ID: <419862D7.3010704@zurich.ibm.com> Date: Mon, 15 Nov 2004 09:03:35 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: Kurt Erik Lindqvist , Multi6 Subject: Re: multi6 WG Last Calls closed References: <4189E72B.8060601@zurich.ibm.com> <3FDCCC3F-301B-11D9-88D6-000A95928574@kurtis.pp.se> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I think we are close enough to agreement to ask the authors of all three last call documents to revise them ASAP for a final check by the WG. That is: draft-ietf-multi6-architecture-02.txt draft-ietf-multi6-things-to-think-about-00.txt draft-ietf-multi6-v4-multihoming-02.txt Erik is also revising draft-ietf-multi6-multihoming-threats-01.txt in response to IESG comments. Brian Pekka Savola wrote: > On Sat, 6 Nov 2004, Kurt Erik Lindqvist wrote: > >>> In my opinion, the two big open issues are >>> >>> draft-ietf-multi6-v4-multihoming-02.txt >>> Thierry Ernst: "to be honest, I don't >>> really understand the value of the document." >>> >>> As I already said, we are chartered to produce this document, >>> but its value is indeed "for the record". Does the WG think that >>> is enough to justify publication? >> >> >> I have no real strong feeling one way or the other. I do think that we >> want this documented somewhere and if not in a separate document >> perhaps this could be fitted into the architectural analysis? But I am >> not sure that is the best place and I think that might add length to an >> already quite long document. > > > I think the doc we have should be sufficiently useful, and besides, > we've been requested to do. I'd say just ship it and if the IESG > evaluation shows that it's not good enough, let's reconsider. > >>> draft-ietf-multi6-architecture-02.txt >>> Pekka Savola: "The document is rather long and conversational >>> in tone." (plus specific comments related to this view). >>> >>> Does the WG agree with Pekka, to the point of asking for a >>> major revision effort? > > > To be clear, even though I said "rather long and conversational in > tone", I was *not* asking the document to be rewritten to _not_ be that. > > What I was hoping was maybe some more structure and changes in the > document's organization so that the "conversation" would be more > manageable. > From owner-multi6@ops.ietf.org Mon Nov 15 07:29:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20514 for ; Mon, 15 Nov 2004 07:29:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTfxn-000BnE-Hd for multi6-data@psg.com; Mon, 15 Nov 2004 12:28:07 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTfxm-000Bmx-OD for multi6@ops.ietf.org; Mon, 15 Nov 2004 12:28:07 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id iAFCRLxX124470; Mon, 15 Nov 2004 12:27:28 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAFCRLjV017906; Mon, 15 Nov 2004 12:27:22 GMT Received: from zurich.ibm.com (sig-9-145-128-157.de.ibm.com [9.145.128.157]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA25274; Mon, 15 Nov 2004 13:27:19 +0100 Message-ID: <4198A0A6.3070604@zurich.ibm.com> Date: Mon, 15 Nov 2004 13:27:18 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Mohan Parthasarathy CC: multi6@ops.ietf.org Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <000001c4caa3$008a4c40$6401a8c0@adithya> In-Reply-To: <000001c4caa3$008a4c40$6401a8c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: ... > Is there a document > that explains what threat needs to be addressed by multi6 solution ? (the threats document > mentions this in a few places, but does not look like requirements to me). We have no plan to produce a security requirements document. Obviously, the solution architecture will need to contain an analysis of how it deals with all the identified threats. HBA is not a total solution, so it doesn't need to do that. Brian From owner-multi6@ops.ietf.org Mon Nov 15 10:04:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00170 for ; Mon, 15 Nov 2004 10:04:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTiOG-0001wG-7F for multi6-data@psg.com; Mon, 15 Nov 2004 15:03:36 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTiOF-0001vw-0t for multi6@ops.ietf.org; Mon, 15 Nov 2004 15:03:35 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E4DD130236; Mon, 15 Nov 2004 16:03:33 +0100 (CET) Received: from [163.117.252.27] (unknown [163.117.252.27]) by smtp03.uc3m.es (Postfix) with ESMTP id DC48C3027C; Mon, 15 Nov 2004 16:03:31 +0100 (CET) In-Reply-To: <000001c4caa3$008a4c40$6401a8c0@adithya> References: <000001c4caa3$008a4c40$6401a8c0@adithya> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <14A88346-3710-11D9-AEEC-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: From: marcelo bagnulo braun Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Mon, 15 Nov 2004 15:10:18 +0100 To: "Mohan Parthasarathy" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Mohan, thanks for the review replies inline.... El 15/11/2004, a las 0:22, Mohan Parthasarathy escribi=F3: > I had a few comments/questions on this draft. Sorry if some of them=20 > have already been > asked (i did not look closely at the archives). > > 1) In section 1, > > In addition, it should also be noted that it > is not required that all interface identifiers of the addresses of=20= > an > HBA set are equal, preserving some degree of privacy through = changes > in the addresses used during the communications. > > To create all addresses (for various prefixes) with same interface=20 > identifiers, what is the > change that would be needed ? Does including the multi-prefix=20 > extension and removing the subnet-prefix > in the second hash calculation (Hash1 in CGA draft) sufficient ? Yes, but this imply not to be compliant with CGA spec. in other words, if we are compliant with CGAs, the iid will be=20 different and it wouldn't be possible to have equal iids we felt that cga compatibility was more important than supporting equal=20= iids in the HBAs of a given set (note that we do see some value in=20 having equal iids, for instance for simplified management, but this=20 cannot be provided in the CGA format) > It might be worth mentioning the procedure. > > 2) If HBA is used and the node wants RFC 3041 privacy addresses, it=20 > means that it needs to > periodically regnerate the HBA ? i think so > Though this is more expensive than RFC 3041 privacy addresses, I guess that it depends in the Sec value... If Sec =3D0 then i guess than generating an HBA is similar to generate a=20= random number. I mean, you only need to add 1 to the modifier and=20 perform a hash operation (probably generating random addresses requires=20= a similar effort) If Sec>0 then i agree > there is not much we can do here i guess. Perhaps, this should be=20 > mentioned somewhere. > Ok, i will mention this in the privacy consideration, thanks > 3) In section 2, > > First, the current Secure Neighbor Discovery specification [2]=20= > uses > the CGAs defined in [1] to prove address ownership. If HBAs are=20= > not > compatible with CGAs, then nodes using HBAs for multihoming=20 > wouldn't > be able to do Secure Neighbor Discovery using the same addresses=20= > (at > least the parts of SeND that require CGAs). This would imply=20 > that > nodes would have to choose between security (from SeND) and > reliability (from multi6) > > What do you mean by reliability here ? fault tolerance i.e. the fault tolerance and other features provided by=20= the multi6 protocol based on the usage of HBAs i will try to reword this in the draft > > 4)When the multi6 state is setup, i assume that the CGA parameter is=20= > exchanged between the > communicating parties. if you mean the CGA parameter data structure including the multiprefix=20= extension, then yes (BTW i need to state this explicitly in the draft) > I was wondering whether it would make any difference between including > the prefix Vs the whole address itself in the CGA parameter data=20 > structrure ? i am not following you here. The CGA parameter data structure is used to generate the iid of the=20 addresses, so how can you include the complete address in it if you=20 still haven't generate it yet.... i am probably missing your point here > I am not able > to see anything less secure by including the whole address itself.=20= > One possibility is that > the peer can compute and validate the address ahead of time (which=20= > is of no use if rehoming > will never occur) and hash verification becomes a simple comparison > when a packet with different locator comes in. but this can be done with the current CGA parameter data structure,=20 right? i mean, the HBA set generation only uses the info contained in the CGA=20= parameter data structure, so once the peer has the CGA parameter data=20 structure, it can regenerate the whole HBA set before the rehoming, as=20= you suggest. i mean, i think you can do this that you suggest already > I am not saying we should do it this way. > I was mainly trying to understand what it means to include the=20 > address instead of prefix. > > > 5) Security considerations need to be improved. agree > It would be good to discuss what attacks it > addresses with respect to the threats document. agree, but note that HBAs are not a complete multihoming solution, and=20= are useful to prevent certain attacks, not all the threats described in=20= the threats drafts > In the beginning of the document, > > This memo describes a tool that can be used to provide=20 > protection against some > of the potential attacks, in particular against future/=20 > premeditated > attacks (a.k.a. time shifting attacks in [6]). > > I hope the future version of the document would explain more on=20 > this. Is there a document > that explains what threat needs to be addressed by multi6 solution=20= > ? (the threats document > mentions this in a few places, but does not look like requirements=20= > to me). well, i guess that the arch document that we are suppose to write next=20= should at least specify the security goals that the designed solution=20 is trying to achieve > > One of the inferences from the security consideration section is=20 > that the attacker cannot create an HBA > set given a set of victim's addresses. It was not very obvious by=20= > reading the security consideration section. > agree, i will include an example of usage and possible attempts of=20 attacks, and see if this improves this point > Also, how important is return routability for the locators before=20= > they are used ? It is not discussed here. > As it is hard for the attacker to redirect packets to a victim, is=20= > it needed ? Can it be optional ? very good point HBAs are mainly used to prevent hijacking attacks and to prevent=20 flooding attacks. We will need reachability tests to prevent flooding=20 attacks. I will include this also in the doc. Thank you very much for your constructive comments I hope i can address them in a satisfactory manner in the next version.=20= Please let me know if i wasn't successful regards, marcelo > > -mohan > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Mon Nov 15 10:25:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02583 for ; Mon, 15 Nov 2004 10:25:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTijA-0009sR-2Z for multi6-data@psg.com; Mon, 15 Nov 2004 15:25:12 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTij9-0009pK-8c for multi6@ops.ietf.org; Mon, 15 Nov 2004 15:25:11 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAFFP5U01001; Mon, 15 Nov 2004 16:25:05 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iAFFP5Sj017261; Mon, 15 Nov 2004 16:25:05 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411151525.iAFFP5Sj017261@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: marcelo bagnulo braun cc: "Mohan Parthasarathy" , multi6@ops.ietf.org Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt In-reply-to: Your message of Mon, 15 Nov 2004 15:10:18 +0100. <14A88346-3710-11D9-AEEC-000D93ACD0FE@it> Date: Mon, 15 Nov 2004 16:25:05 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: we felt that cga compatibility was more important than supporting equal iids in the HBAs of a given set (note that we do see some value in having equal iids, for instance for simplified management, but this cannot be provided in the CGA format) => I agree. In fact, to get the same IID for all prefixes is not a good property IMHO. > What do you mean by reliability here ? fault tolerance i.e. the fault tolerance and other features provided by the multi6 protocol based on the usage of HBAs i will try to reword this in the draft => you should because HBAs are compatible with CGAs... > 4)When the multi6 state is setup, i assume that the CGA parameter is > exchanged between the > communicating parties. if you mean the CGA parameter data structure including the multiprefix extension, then yes (BTW i need to state this explicitly in the draft) => the CGA draft is pretty clear about this. > One of the inferences from the security consideration section is > that the attacker cannot create an HBA > set given a set of victim's addresses. It was not very obvious by > reading the security consideration section. agree, i will include an example of usage and possible attempts of attacks, and see if this improves this point => in fact this is clearer in the CGA document: this problem is to the good parameters which will hash to the given 59+16*sec bits (note the number of prefixes don't really matter, i.e., it doesn't add or remove bits to the problem to solve for attackers). Thanks Francis.Dupont@enst-bretagne.fr PS: BTW CGA IPR holders provide royalty-free licenses only for SEND, can they update their IPR texts on the IETF web for HBAs too? From owner-multi6@ops.ietf.org Mon Nov 15 10:53:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04463 for ; Mon, 15 Nov 2004 10:53:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTj9l-000LJJ-Hl for multi6-data@psg.com; Mon, 15 Nov 2004 15:52:41 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTj9k-000LIv-JM for multi6@ops.ietf.org; Mon, 15 Nov 2004 15:52:40 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5A20289889 for ; Mon, 15 Nov 2004 17:52:39 +0200 (EET) Message-ID: <4198D05A.9040009@piuha.net> Date: Mon, 15 Nov 2004 17:50:50 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: IPR (Was: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt) References: <200411151525.iAFFP5Sj017261@givry.rennes.enst-bretagne.fr> In-Reply-To: <200411151525.iAFFP5Sj017261@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > PS: BTW CGA IPR holders provide royalty-free licenses only for SEND, > can they update their IPR texts on the IETF web for HBAs too? FYI: I have asked the Ericsson IPR department to inform the IETF about their licensing conditions regarding the HBA draft and usage in MULTI6. --Jari From owner-multi6@ops.ietf.org Mon Nov 15 10:55:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04641 for ; Mon, 15 Nov 2004 10:55:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTjCZ-000Mjq-CV for multi6-data@psg.com; Mon, 15 Nov 2004 15:55:35 +0000 Received: from [195.212.29.136] (helo=mtagate3.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTjCY-000MjY-KS for multi6@ops.ietf.org; Mon, 15 Nov 2004 15:55:34 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAFFtT5M164132; Mon, 15 Nov 2004 15:55:29 GMT Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAFFtSkM205268; Mon, 15 Nov 2004 15:55:29 GMT Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA25088; Mon, 15 Nov 2004 16:55:25 +0100 Message-ID: <4198D16C.7000002@zurich.ibm.com> Date: Mon, 15 Nov 2004 16:55:24 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Francis Dupont CC: marcelo bagnulo braun , Mohan Parthasarathy , multi6@ops.ietf.org Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <200411151525.iAFFP5Sj017261@givry.rennes.enst-bretagne.fr> In-Reply-To: <200411151525.iAFFP5Sj017261@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Francis Dupont wrote: ... > PS: BTW CGA IPR holders provide royalty-free licenses only for SEND, > can they update their IPR texts on the IETF web for HBAs too? We could leave this issue until we have a WG chartered and an item intended for the standards track. But it would be nice. Brian From owner-multi6@ops.ietf.org Mon Nov 15 12:18:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11865 for ; Mon, 15 Nov 2004 12:18:35 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTkTo-0001zQ-Qu for multi6-data@psg.com; Mon, 15 Nov 2004 17:17:28 +0000 Received: from [217.32.164.138] (helo=smtp3.smtp.bt.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTkTn-0001v8-Vd for multi6@ops.ietf.org; Mon, 15 Nov 2004 17:17:28 +0000 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Mon, 15 Nov 2004 17:18:35 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Nov 2004 17:18:35 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Mon, 15 Nov 2004 17:18:35 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A700B2D0D5D@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: Comments on draft-bagnulo-multi6dt-hba-00.txt Thread-Index: AcTLLAsECT/Mof7/SOWEKvnbGAj0oQACp/Hw From: To: , Cc: , , X-OriginalArrivalTime: 15 Nov 2004 17:18:35.0583 (UTC) FILETIME=[23B39CF0:01C4CB37] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On 15 November 2004 15:55, owner-multi6@ops.ietf.org () wrote: > Francis Dupont wrote: > ... >> PS: BTW CGA IPR holders provide royalty-free licenses only for SEND, >> can they update their IPR texts on the IETF web for HBAs too? >=20 > We could leave this issue until we have a WG chartered and > an item intended for the standards track. But it would be nice. Note that KAME at least have concerns with the SeND IPR such that they are refusing to implement. If there's a revision to IPR statements taking place for HBA, perhaps this also creates an opportunity to address KAME's concerns. Regards, Mat From owner-multi6@ops.ietf.org Mon Nov 15 18:14:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24369 for ; Mon, 15 Nov 2004 18:14:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTq20-00090d-Dv for multi6-data@psg.com; Mon, 15 Nov 2004 23:13:08 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CTq1z-00090Q-Gt for multi6@ops.ietf.org; Mon, 15 Nov 2004 23:13:07 +0000 Received: from jurassic.eng.sun.com ([129.146.84.45]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAFND7NH022699; Mon, 15 Nov 2004 16:13:07 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAFND45q229873; Mon, 15 Nov 2004 15:13:04 -0800 (PST) Message-ID: <41993835.50406@sun.com> Date: Mon, 15 Nov 2004 15:13:57 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy CC: multi6@ops.ietf.org Subject: Re: Comments on draft-nordmark-multi6dt-shim-00.txt References: <002801c4caa5$35d850c0$6401a8c0@adithya> In-Reply-To: <002801c4caa5$35d850c0$6401a8c0@adithya> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.64 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the comments. Mohan Parthasarathy wrote: > This draft was pretty easy to read. Here are some questions/comments > on the draft. > > 1) In section 5, > > The context state in this approach is maintained per remote ULID i.e. > approximately per peer host, and not at any finer granularity. It > might make sense to merge the context state for multiple ULIDs > assigned to the same peer host, but this is for further study. > > What does "maintained" above mean ? Section 9.3 says that transmit > side locates the context based on (ULID (local, remote) and receive > side based on tags etc. A bit of clarification would help here. What it should say is that it's per host/ULID, and not per TCP connection. I'll make that more explicit. > Also, i don't know what merging means above ? I guess you still need > to maintain explicit state on both ends so that two connections > between same hosts using different ULID pairs (A1, B1), (A1, B2) but > same locators will need to be demuxed differently ? Yes, but if A discovers that ULID B1 and B2 points to the same host (by both contexts having the same verified locator sets ), then A could perform the reachability probing more efficiently; it wouldn't have to probe B1 and B2 independently for each context. > 2) Section 8 protocol walkthrough does not talk about some details > e.g. how HBA is used. In 8.2, it talks about locator change. But a > little bit more detail would help here. I assume that HBA state is > established initially and verified only when the locator set is > different from the ULID. Is that right ? Again this is not clearly > specified anywhere (i have not read all thedocuments closely, so i > could be missing something). And intentionally so. We wrote the draft without assuming that the collection of drafts would fit together, hence this draft doesn't assume that redirection attacks are prevented using HBA. Once we have a protocol draft these things will become more clear. > 3) In Section 9, will the following approach also work : > > Never use the same set of locators across two different connections > between the same hosts. I know it is not the best option, but for > discussion it is okay i guess. The DT discussed that, and the problem is that you can't tell a priori whether two peers share an IP stack. For instance, if A connects to www.foo.com with AAAA=B1 and www.bar.com with AAAA=B2 it can't tell whether B1 or B2 are assigned to the same IP stack or not until it communicates with B1 and B2 and retrieves there complete locator sets. (And even this might not suffice, since the peer might want to preserve the illusion of being two different hosts by returning B3 as an alternative locator for B1 and B4 as an alternate for B2.) > I can understand how the methods 9.1.1 and 9.1.2 helps the receiver > map from locators to the identifier. But this is not sufficient to > just enough to map locators to identifier. You also need someway to > find out whether the locator pair has changed and if so validate it. > You need to do two things on the receiver : > > 1) Map from the locator to to the right upper layer identifier. 2) > Make sure that the locators are part of the same HBA set (or some > such mechanism to prevent redirect attacks). > > How does these two steps happen for 9.1.1 and 9.1.2 ? As identifier > is known a priori, i can see how (1) happens. How about (2) ? Is > there still some state maintained at M6 layer ? How is that state > looked up ? Some clarification would help. You'd still have multi6 state at the receiver; without any state the IP address fields would not be modified by the M6 layer. When this state is established, and when the locator set in the state is modified by the peer, would the locator set be verified. (You need the state to be able to rewrite the IP source address field, even if the destination address field rewrite is implicit from the destination locator in the packet.) > 4) In section 9.2.1 (Flow label), > > The limitation imposed by this approach is that all the potential > source and destination addresses have to be known beforehand by the > receiver in order to be recognized. This means that before sending > packets with a new address, the sender has to inform the receiver > about the new address. > > I thought this is needed irrespective of which scheme we use ? Why is > this specific to the method ? The possible goal/requirement would be generic. The test is trying (and failing) to point that it might be beneficial to accept packets from unknown source locators (the rules for packet injection can probably be more relaxed than for where packets are sent, for instance if the context tag matches). Requiring a match on would not make this possible instead the locator change signaling would need to be acknowledged before the peer can start using a different source locator. > 5) In section 9.2.2, context tag required only when the locator is > different from identifier. M6 layer is bypassed when there is no > extension header. Is that right ? Yes. Erik From owner-multi6@ops.ietf.org Mon Nov 15 20:39:36 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05633 for ; Mon, 15 Nov 2004 20:39:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTsH1-0008Wq-2N for multi6-data@psg.com; Tue, 16 Nov 2004 01:36:47 +0000 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CTsH0-0008Wc-7r for multi6@ops.ietf.org; Tue, 16 Nov 2004 01:36:46 +0000 Received: from ocean.jinmei.org (unknown [2001:200:0:8002:bd0d:2a88:383e:ac1c]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id E99D515218; Tue, 16 Nov 2004 10:36:44 +0900 (JST) Date: Tue, 16 Nov 2004 10:36:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Cc: , , , , Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt In-Reply-To: <0AAF93247C75E3408638B965DEE11A700B2D0D5D@i2km41-ukdy.domain1.systemhost.net> References: <0AAF93247C75E3408638B965DEE11A700B2D0D5D@i2km41-ukdy.domain1.systemhost.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk >>>>> On Mon, 15 Nov 2004 17:18:35 -0000, >>>>> said: >> Francis Dupont wrote: >> ... >>> PS: BTW CGA IPR holders provide royalty-free licenses only for SEND, >>> can they update their IPR texts on the IETF web for HBAs too? >> >> We could leave this issue until we have a WG chartered and >> an item intended for the standards track. But it would be nice. > Note that KAME at least have concerns with the SeND IPR such that they > are refusing to implement. If there's a revision to IPR statements > taking place for HBA, perhaps this also creates an opportunity to > address KAME's concerns. At the risk of making off-topic response (so I won't send further responses on this particular topic here), the KAME concerns are described at: http://www.kame.net/newsletter/20040525/ (search "(7) SEND IPR" for details) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-multi6@ops.ietf.org Tue Nov 16 04:25:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07847 for ; Tue, 16 Nov 2004 04:25:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTzYs-0003RP-3m for multi6-data@psg.com; Tue, 16 Nov 2004 09:23:42 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CTzYq-0003R4-UB for multi6@ops.ietf.org; Tue, 16 Nov 2004 09:23:41 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAG9NOSZ228606; Tue, 16 Nov 2004 09:23:24 GMT Received: from sihl.zurich.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAG9NNGG195474; Tue, 16 Nov 2004 09:23:24 GMT Received: from zurich.ibm.com (sig-9-146-220-185.de.ibm.com [9.146.220.185]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA50496; Tue, 16 Nov 2004 10:23:21 +0100 Message-ID: <4199C708.9070402@zurich.ibm.com> Date: Tue, 16 Nov 2004 10:23:20 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 , Kurt Erik Lindqvist , David Kessens , Bert Wijnen , Margaret Wasserman , Thomas Narten Subject: Re: Multi6 next steps - consensus call References: <4193B5BC.2040808@zurich.ibm.com> In-Reply-To: <4193B5BC.2040808@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eliot Lear was the only person to comment, somewhat disagreeing tactically with items 3 and 4, but not with the intent to do the work in the Internet Area. The chairs take this as a consensus to open discussion with the Area Directors, as well as urging the design team to tidy up their drafts (item 1) and draft the solution architecture (item 2). Brian + Kurtis Brian E Carpenter wrote: > Multi6 people, > > At the meetings this week, the design team drafts were discussed, > and consensus in the room was positive for the following questions: > > 1. Do we agree that the way forward is the direction and > work produced by the design team [modulo the missing pieces, > including choosing site-exit routers]? > > 2. Do we agree on the need for a solution architecture document? > > 3. Do we agree to recommend a new working group in the Internet Area > to follow up the design team approach? > > 4. Do we agree to close down multi6 when its current work is done? > > If you *disagree* with any of the above, please respond to the > list, with a short explanation, in the next few days. > > Brian + Kurtis > co-chairs > > PS: the drafts in question are > Multihoming Level 3 Shim Approach > (draft-nordmark-multi6dt-shim-00.txt) > Hash Based Addresses (HBA) > (draft-bagnulo-multi6dt-hba-00.txt) > Functional decomposition of the M6 protocol > (draft-bagnulo-multi6dt-functional-dec-00.txt) > Failure Detection and Locator Selection in Multi6 > (draft-arkko-multi6dt-failure-detection-00.txt) > Multi6 Application Referral Issues > (draft-nordmark-multi6dt-refer-00.txt) > > > > From owner-multi6@ops.ietf.org Tue Nov 16 04:35:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08584 for ; Tue, 16 Nov 2004 04:35:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CTzjg-0004Pz-BA for multi6-data@psg.com; Tue, 16 Nov 2004 09:34:52 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CTzjf-0004Pd-B8 for multi6@ops.ietf.org; Tue, 16 Nov 2004 09:34:51 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAG9Ymv05630; Tue, 16 Nov 2004 11:34:49 +0200 (EET) X-Scanned: Tue, 16 Nov 2004 11:33:16 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iAG9XGAe007639; Tue, 16 Nov 2004 11:33:16 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 000qX2PF; Tue, 16 Nov 2004 11:33:07 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAG9Wta13561; Tue, 16 Nov 2004 11:32:55 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Nov 2004 11:32:46 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Nov 2004 11:32:46 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Nov 2004 11:32:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Multi6 next steps - consensus call Date: Tue, 16 Nov 2004 11:32:44 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D43208B@esebe056.ntc.nokia.com> Thread-Topic: Multi6 next steps - consensus call Thread-Index: AcTLvv3ovWDSzLgOREuveF+eiHnBJgAADF5Q From: To: Cc: , , , , , X-OriginalArrivalTime: 16 Nov 2004 09:32:45.0444 (UTC) FILETIME=[3A889C40:01C4CBBF] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Brian, > Eliot Lear was the only person to comment, somewhat disagreeing > tactically with items 3 and 4, but not with the intent to do > the work in the Internet Area. The chairs take this as a consensus > to open discussion with the Area Directors, as well as > urging the design team to tidy up their drafts (item 1) and > draft the solution architecture (item 2). I support this. John From owner-multi6@ops.ietf.org Tue Nov 16 13:14:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26154 for ; Tue, 16 Nov 2004 13:14:07 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CU7om-0007ag-0o for multi6-data@psg.com; Tue, 16 Nov 2004 18:12:40 +0000 Received: from [66.163.170.81] (helo=smtp811.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CU7oN-0007Xd-0G for multi6@ops.ietf.org; Tue, 16 Nov 2004 18:12:15 +0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 16 Nov 2004 18:12:14 -0000 Message-ID: <003f01c4cc07$ce2587e0$861167c0@adithya> From: "Mohan Parthasarathy" To: "marcelo bagnulo braun" Cc: References: <003801c4cc04$a74ddd50$861167c0@adithya> Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Tue, 16 Nov 2004 10:12:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo, Comments inline.. > > > I had a few comments/questions on this draft. Sorry if some of them > > have already been > > asked (i did not look closely at the archives). > > > > 1) In section 1, > > > > In addition, it should also be noted that it > > is not required that all interface identifiers of the addresses of > > an > > HBA set are equal, preserving some degree of privacy through changes > > in the addresses used during the communications. > > > > To create all addresses (for various prefixes) with same interface > > identifiers, what is the > > change that would be needed ? Does including the multi-prefix > > extension and removing the subnet-prefix > > in the second hash calculation (Hash1 in CGA draft) sufficient ? > > Yes, but this imply not to be compliant with CGA spec. > in other words, if we are compliant with CGAs, the iid will be > different and it wouldn't be possible to have equal iids > > we felt that cga compatibility was more important than supporting equal > iids in the HBAs of a given set (note that we do see some value in > having equal iids, for instance for simplified management, but this > cannot be provided in the CGA format) > I thought we have 3 different types of addresses now. The procedure to compute the hash is different depending on HBA or CGA i.e include the public key or extended modifier depending on CGA or HBA. So, why does it matter if we can specify something different for HBA address ? Both ends know they are operating on an HBA address. So, what is the compatibility issue ? Could you elaborate on that ? > > It might be worth mentioning the procedure. > > > > 2) If HBA is used and the node wants RFC 3041 privacy addresses, it > > means that it needs to > > periodically regnerate the HBA ? > > i think so > > > Though this is more expensive than RFC 3041 privacy addresses, > > I guess that it depends in the Sec value... > If Sec =0 then i guess than generating an HBA is similar to generate a > random number. I mean, you only need to add 1 to the modifier and > perform a hash operation (probably generating random addresses requires > a similar effort) > If Sec>0 then i agree > Agreed. > > there is not much we can do here i guess. Perhaps, this should be > > mentioned somewhere. > > > > Ok, i will mention this in the privacy consideration, thanks > > > 3) In section 2, > > > > First, the current Secure Neighbor Discovery specification [2] > > uses > > the CGAs defined in [1] to prove address ownership. If HBAs are > > not > > compatible with CGAs, then nodes using HBAs for multihoming > > wouldn't > > be able to do Secure Neighbor Discovery using the same addresses > > (at > > least the parts of SeND that require CGAs). This would imply > > that > > nodes would have to choose between security (from SeND) and > > reliability (from multi6) > > > > What do you mean by reliability here ? > > fault tolerance i.e. the fault tolerance and other features provided by > the multi6 protocol based on the usage of HBAs > > i will try to reword this in the draft > Okay. > > > > 4)When the multi6 state is setup, i assume that the CGA parameter is > > exchanged between the > > communicating parties. > > if you mean the CGA parameter data structure including the multiprefix > extension, then yes > (BTW i need to state this explicitly in the draft) > Yes, that's what i meant. I assumed that whatever is not there in this draft is present in one of the other 5 drafts :-) > > I was wondering whether it would make any difference between including > > the prefix Vs the whole address itself in the CGA parameter data > > structrure ? > > i am not following you here. > The CGA parameter data structure is used to generate the iid of the > addresses, so how can you include the complete address in it if you > still haven't generate it yet.... i am probably missing your point here > I mean, you can generate the address and include it..but it is not needed as you mention below.. > > I am not able > > to see anything less secure by including the whole address itself. > > One possibility is that > > the peer can compute and validate the address ahead of time (which > > is of no use if rehoming > > will never occur) and hash verification becomes a simple comparison > > when a packet with different locator comes in. > > but this can be done with the current CGA parameter data structure, > right? > i mean, the HBA set generation only uses the info contained in the CGA > parameter data structure, so once the peer has the CGA parameter data > structure, it can regenerate the whole HBA set before the rehoming, as > you suggest. > > i mean, i think you can do this that you suggest already > Agreed. I was thinking in a slightly different direction which may not be needed i guess. Somebody in one of the multi6 meeting raised a point about computing the hash and verifying it as expensive. First, the hash is not computed always i guess. Only after the rehoming occurs. But once the rehoming occurs, you have to recompute always as long as the locator does not match the ULID. Is that right ? Then i was wondering whether it is a real problem because it affects the fast path processing of the packet. Perhaps not because it can be pre-computed. But it may not be necessary i guess. The first packet after rehoming will trigger the hash computation, but that can be cached i guess. Hence the subsequent packets can be compared directly with the cached value. Does that make sense ? > > I am not saying we should do it this way. > > I was mainly trying to understand what it means to include the > > address instead of prefix. > > > > > > 5) Security considerations need to be improved. > > agree > > > It would be good to discuss what attacks it > > addresses with respect to the threats document. > > agree, but note that HBAs are not a complete multihoming solution, and > are useful to prevent certain attacks, not all the threats described in > the threats drafts > > > In the beginning of the document, > > > > This memo describes a tool that can be used to provide > > protection against some > > of the potential attacks, in particular against future/ > > premeditated > > attacks (a.k.a. time shifting attacks in [6]). > > > > I hope the future version of the document would explain more on > > this. Is there a document > > that explains what threat needs to be addressed by multi6 solution > > ? (the threats document > > mentions this in a few places, but does not look like requirements > > to me). > > well, i guess that the arch document that we are suppose to write next > should at least specify the security goals that the designed solution > is trying to achieve > That should be sufficient. > > > > One of the inferences from the security consideration section is > > that the attacker cannot create an HBA > > set given a set of victim's addresses. It was not very obvious by > > reading the security consideration section. > > > > agree, i will include an example of usage and possible attempts of > attacks, and see if this improves this point > > > Also, how important is return routability for the locators before > > they are used ? It is not discussed here. > > As it is hard for the attacker to redirect packets to a victim, is > > it needed ? Can it be optional ? > > very good point > HBAs are mainly used to prevent hijacking attacks and to prevent > flooding attacks. We will need reachability tests to prevent flooding > attacks. I will include this also in the doc. > I am not sure i understood the above sentence. First you say that HBA can be used to prevent flooding attacks and then you say that we need reachaility tests to prevent flooding attacks. -mohan > Thank you very much for your constructive comments > I hope i can address them in a satisfactory manner in the next version. > Please let me know if i wasn't successful > > regards, marcelo > > > > > -mohan > > > > > ------------------------------------------ > Please note that my former email address > mbagnulo@ing.uc3m.es is no longer in use > Please send mail to: > marcelo at it dot uc3m dot es > ------------------------------------------ > From owner-multi6@ops.ietf.org Tue Nov 16 13:38:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28008 for ; Tue, 16 Nov 2004 13:38:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CU8DH-0009vL-9W for multi6-data@psg.com; Tue, 16 Nov 2004 18:37:59 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CU8D7-0009sx-Op for multi6@ops.ietf.org; Tue, 16 Nov 2004 18:37:50 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5D223303FA; Tue, 16 Nov 2004 19:37:48 +0100 (CET) Received: from [163.117.139.34] (unknown [163.117.139.34]) by smtp03.uc3m.es (Postfix) with ESMTP id 3764F303F8; Tue, 16 Nov 2004 19:37:48 +0100 (CET) In-Reply-To: <003f01c4cc07$ce2587e0$861167c0@adithya> References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <9E1079A2-37FE-11D9-AEEC-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: From: marcelo bagnulo braun Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Tue, 16 Nov 2004 19:37:49 +0100 To: "Mohan Parthasarathy" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,OBSCURED_EMAIL autolearn=no version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable below... El 16/11/2004, a las 19:12, Mohan Parthasarathy escribi=F3: > Marcelo, > > Comments inline.. > >> >>> I had a few comments/questions on this draft. Sorry if some of them >>> have already been >>> asked (i did not look closely at the archives). >>> >>> 1) In section 1, >>> >>> In addition, it should also be noted that it >>> is not required that all interface identifiers of the addresses = of >>> an >>> HBA set are equal, preserving some degree of privacy through=20 >>> changes >>> in the addresses used during the communications. >>> >>> To create all addresses (for various prefixes) with same interface >>> identifiers, what is the >>> change that would be needed ? Does including the multi-prefix >>> extension and removing the subnet-prefix >>> in the second hash calculation (Hash1 in CGA draft) sufficient ? >> >> Yes, but this imply not to be compliant with CGA spec. >> in other words, if we are compliant with CGAs, the iid will be >> different and it wouldn't be possible to have equal iids >> >> we felt that cga compatibility was more important than supporting=20 >> equal >> iids in the HBAs of a given set (note that we do see some value in >> having equal iids, for instance for simplified management, but this >> cannot be provided in the CGA format) >> > I thought we have 3 different types of addresses now. The procedure to > compute the hash is different depending on HBA or CGA i.e include the > public key or extended modifier depending on CGA or HBA. So, why does > it matter if we can specify something different for HBA address ? Both=20= > ends > know they are operating on an HBA address. So, what is the=20 > compatibility > issue ? Could you elaborate on that ? > Well, the HBA is defined always (in the 3 cases) as an extension of the=20= CGA. i agree with you that we could define the HBA as an extension of the=20 CGA when the CGA is also used (i.e. the HBA/CGA hybrid) and define the=20= HBA in a different way when the CGA are not used (HBA only mode) But i am not sure this is worthy, since i guess it would be more=20 complex since you need to handle multiple generation algorithms,=20 depending in the case. suppose the case when a a communication has a=20 CGA/HBA and a HBA only in the other side, this would probably would be=20= more complex either. I mean, having a different generation for the=20 generation of the HBA only case would essentially provide that all the=20= iids are the same in an HBA set, but with an additional complexity in=20 the implementation, do you think that it is worthy? >>> It might be worth mentioning the procedure. >>> >>> 2) If HBA is used and the node wants RFC 3041 privacy addresses, it >>> means that it needs to >>> periodically regnerate the HBA ? >> >> i think so >> >>> Though this is more expensive than RFC 3041 privacy addresses, >> >> I guess that it depends in the Sec value... >> If Sec =3D0 then i guess than generating an HBA is similar to = generate a >> random number. I mean, you only need to add 1 to the modifier and >> perform a hash operation (probably generating random addresses=20 >> requires >> a similar effort) >> If Sec>0 then i agree >> > > Agreed. > >>> there is not much we can do here i guess. Perhaps, this should be >>> mentioned somewhere. >>> >> >> Ok, i will mention this in the privacy consideration, thanks >> >>> 3) In section 2, >>> >>> First, the current Secure Neighbor Discovery specification [2] >>> uses >>> the CGAs defined in [1] to prove address ownership. If HBAs=20= >>> are >>> not >>> compatible with CGAs, then nodes using HBAs for multihoming >>> wouldn't >>> be able to do Secure Neighbor Discovery using the same=20 >>> addresses >>> (at >>> least the parts of SeND that require CGAs). This would imply >>> that >>> nodes would have to choose between security (from SeND) and >>> reliability (from multi6) >>> >>> What do you mean by reliability here ? >> >> fault tolerance i.e. the fault tolerance and other features provided=20= >> by >> the multi6 protocol based on the usage of HBAs >> >> i will try to reword this in the draft >> > Okay. > > >>> >>> 4)When the multi6 state is setup, i assume that the CGA parameter is >>> exchanged between the >>> communicating parties. >> >> if you mean the CGA parameter data structure including the = multiprefix >> extension, then yes >> (BTW i need to state this explicitly in the draft) >> > Yes, that's what i meant. I assumed that whatever is not there in this > draft is present in one of the other 5 drafts :-) > >>> I was wondering whether it would make any difference between=20 >>> including >>> the prefix Vs the whole address itself in the CGA parameter data >>> structrure ? >> >> i am not following you here. >> The CGA parameter data structure is used to generate the iid of the >> addresses, so how can you include the complete address in it if you >> still haven't generate it yet.... i am probably missing your point=20 >> here >> > I mean, you can generate the address and include it..but it is not=20 > needed as > you mention below.. > >>> I am not able >>> to see anything less secure by including the whole address itself. >>> One possibility is that >>> the peer can compute and validate the address ahead of time (which >>> is of no use if rehoming >>> will never occur) and hash verification becomes a simple = comparison >>> when a packet with different locator comes in. >> >> but this can be done with the current CGA parameter data structure, >> right? >> i mean, the HBA set generation only uses the info contained in the = CGA >> parameter data structure, so once the peer has the CGA parameter data >> structure, it can regenerate the whole HBA set before the rehoming, = as >> you suggest. >> >> i mean, i think you can do this that you suggest already >> > Agreed. I was thinking in a slightly different direction which may = not > be needed i guess. Somebody in one of the multi6 meeting raised a=20 > point about > computing the hash and verifying it as expensive. First, the hash is=20= > not computed > always i guess. Only after the rehoming occurs. But once the rehoming=20= > occurs, you > have to recompute always as long as the locator does not match the=20 > ULID. Is that right ? > Then i was wondering whether it is a real problem because it affects=20= > the fast path processing > of the packet. Perhaps not because it can be pre-computed. > But it may not be necessary > i guess. The first packet after rehoming will trigger the hash=20 > computation, but that can > be cached i guess. Hence the subsequent packets can be compared=20 > directly > with the cached value. Does that make sense ? > Yes, I mean, i would do the following. first the communication is set up, and at some moment in time the CGA=20 parameters are exchanged. For now, no hash calculation. Suddenly, an different locator needs to be used. So at this point, i=20 would run the verification process, implying a hash calculation. then as long this is the locator that is used, i don't think that=20 additional verification are needed, you just need to remember that this=20= locator is OK So, i would say that for a HBA set with n prefixes, the maximum number=20= of hash verifications needed is n (independently of the number of=20 packets exchanged with each locator) >>> I am not saying we should do it this way. >>> I was mainly trying to understand what it means to include the >>> address instead of prefix. >>> >>> >>> 5) Security considerations need to be improved. >> >> agree >> >>> It would be good to discuss what attacks it >>> addresses with respect to the threats document. >> >> agree, but note that HBAs are not a complete multihoming solution, = and >> are useful to prevent certain attacks, not all the threats described=20= >> in >> the threats drafts >> >>> In the beginning of the document, >>> >>> This memo describes a tool that can be used to provide >>> protection against some >>> of the potential attacks, in particular against future/ >>> premeditated >>> attacks (a.k.a. time shifting attacks in [6]). >>> >>> I hope the future version of the document would explain more on >>> this. Is there a document >>> that explains what threat needs to be addressed by multi6 = solution >>> ? (the threats document >>> mentions this in a few places, but does not look like = requirements >>> to me). >> >> well, i guess that the arch document that we are suppose to write = next >> should at least specify the security goals that the designed solution >> is trying to achieve >> > That should be sufficient. > >>> >>> One of the inferences from the security consideration section is >>> that the attacker cannot create an HBA >>> set given a set of victim's addresses. It was not very obvious by >>> reading the security consideration section. >>> >> >> agree, i will include an example of usage and possible attempts of >> attacks, and see if this improves this point >> >>> Also, how important is return routability for the locators = before >>> they are used ? It is not discussed here. >>> As it is hard for the attacker to redirect packets to a victim, = is >>> it needed ? Can it be optional ? >> >> very good point >> HBAs are mainly used to prevent hijacking attacks and to prevent >> flooding attacks. We will need reachability tests to prevent flooding >> attacks. I will include this also in the doc. >> > I am not sure i understood the above sentence. well as it is stated it is impossible to understand (i am sorry for=20 that) What i wanted to say was: HBAs are mainly used to prevent hijacking attacks. We will need reachability tests to prevent flooding attacks. However, an additional consideration about this... Note that if HBAs are used, flooding a specific target host is very=20 difficult, since i would need to find an HBA set that contains an=20 address with the attacker prefix and that the address of the victim is=20= included in the HBA set, agree? this is very difficult (O^(59+(16*Sec)) difficult However, the flooding attack can be easily directed to the access link=20= or access router of the victim, since the attacker only need to include=20= the prefix of the victim's network in the prefix set. This means that the resulting HBA set won't contain any address of a=20 real host within the victim's network, but in any case the flood will=20 be routed to the access router of the victim's network flooding the=20 access link and the access router. So even if the flooding attack is slightly different, i guess that it=20 would still make sense to provide some protection from it, agree? regards, marcelo > First you say that HBA can > be used to prevent flooding attacks and then you say that we need > reachaility tests to prevent flooding attacks. > > -mohan > >> Thank you very much for your constructive comments >> I hope i can address them in a satisfactory manner in the next=20 >> version. >> Please let me know if i wasn't successful >> >> regards, marcelo >> >>> >>> -mohan >>> >>> >> ------------------------------------------ >> Please note that my former email address >> mbagnulo@ing.uc3m.es is no longer in use >> Please send mail to: >> marcelo at it dot uc3m dot es >> ------------------------------------------ >> > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Tue Nov 16 14:29:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02588 for ; Tue, 16 Nov 2004 14:29:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CU90K-000Fhd-6b for multi6-data@psg.com; Tue, 16 Nov 2004 19:28:40 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CU90F-000FhK-N2 for multi6@ops.ietf.org; Tue, 16 Nov 2004 19:28:36 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6F5C98983B; Tue, 16 Nov 2004 21:28:34 +0200 (EET) Message-ID: <419A5475.2000901@piuha.net> Date: Tue, 16 Nov 2004 21:26:45 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Cc: marcelo bagnulo braun , multi6@ops.ietf.org Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> In-Reply-To: <003f01c4cc07$ce2587e0$861167c0@adithya> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Mohan, and thanks for your comments. Some discussion inline: > I thought we have 3 different types of addresses now. The procedure to > compute the hash is different depending on HBA or CGA i.e include the > public key or extended modifier depending on CGA or HBA. So, why does > it matter if we can specify something different for HBA address ? Both ends > know they are operating on an HBA address. So, what is the compatibility > issue ? Could you elaborate on that ? Actually, I believe the intent is to have just one address format, basically according to the SEND CGA draft with some optional data that is going to make things easier in some cases. So the cases that we have are: - CGA format + pure CGA: all rehoming events require a PK operation - CGA format + pure HBA: a set of fixed prefixes is included and no other addresses than the fixed ones are expected: all rehoming events can be done with a symmetric crypto - CGA format + HBA + CGA: as above, but if you need to go beyond the originally listed address set you can switch to using the public key As for the interoperability problem -- at least my main issue is that IPv6 components such as SEND or MULTI6 do not require you to allocate different addresses; that you can actually use both features at the same time. You could of course do this so that MULTI6 module decides to use the CGA format if it also wants to do SEND or does not know the set of prefixes beforehand, and HBA format otherwise. But using a single format seems simpler. Plus I actually like the fact that the IIDs are different :-) > Agreed. I was thinking in a slightly different direction which may not > be needed i guess. Somebody in one of the multi6 meeting raised a point about > computing the hash and verifying it as expensive. First, the hash is not computed > always i guess. Only after the rehoming occurs. But once the rehoming occurs, you > have to recompute always as long as the locator does not match the ULID. Is that right ? > Then i was wondering whether it is a real problem because it affects the fast path processing > of the packet. Perhaps not because it can be pre-computed. But it may not be necessary > i guess. The first packet after rehoming will trigger the hash computation, but that can > be cached i guess. Hence the subsequent packets can be compared directly > with the cached value. Does that make sense ? I think we need to treat fast path for payload packets and signaling differently. Either at the beginning or at a rehoming event there's going to be some signaling. I don't believe fast pathing this signaling is going to be necessary. However, once you have determined that an address belongs to the peer (either through HBA or CGA proof), presumably you should be able to set up whatever processing of fast path mechanism you need for packets arriving with any of the legal address pairs. And in the worst case all of these pairs are going to need a mapping from the on-the-wire address pairs to the ULID pairs. So, conceptually, if you receive the "M6 header" then you do the mapping. This should be fast too, I think. But if you receive an indication of a problem or some message from the peer claiming that it has changed its address, that is going to need at least a hash operation as well as some amount of data structure modifications in the stack. >>very good point >>HBAs are mainly used to prevent hijacking attacks and to prevent >>flooding attacks. We will need reachability tests to prevent flooding >>attacks. I will include this also in the doc. >> > > I am not sure i understood the above sentence. First you say that HBA can > be used to prevent flooding attacks and then you say that we need > reachaility tests to prevent flooding attacks. Reachability tests are needed to prevent flooding attacks, because HBA and CGA techniques can only show that you generated the address, not that you actually are on the link. HBA/CGA on the other hand is needed to ensure that you can't hijack any else's address. The "victims" in these two cases are different: in the first case its third parties, in the second case it is an "owner" of an address. --Jari From owner-multi6@ops.ietf.org Tue Nov 16 14:40:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03964 for ; Tue, 16 Nov 2004 14:40:47 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CU9Bh-000H5f-Hg for multi6-data@psg.com; Tue, 16 Nov 2004 19:40:25 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CU9Bg-000H5R-EN for multi6@ops.ietf.org; Tue, 16 Nov 2004 19:40:24 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9968E8983B; Tue, 16 Nov 2004 21:40:23 +0200 (EET) Message-ID: <419A573A.90900@piuha.net> Date: Tue, 16 Nov 2004 21:38:34 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun Cc: Mohan Parthasarathy , multi6@ops.ietf.org Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <9E1079A2-37FE-11D9-AEEC-000D93ACD0FE@it.uc3m.es> In-Reply-To: <9E1079A2-37FE-11D9-AEEC-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Marcelo, > Yes, > I mean, i would do the following. > first the communication is set up, and at some moment in time the CGA > parameters are exchanged. For now, no hash calculation. > Suddenly, an different locator needs to be used. So at this point, i > would run the verification process, implying a hash calculation. > then as long this is the locator that is used, i don't think that > additional verification are needed, you just need to remember that this > locator is OK > So, i would say that for a HBA set with n prefixes, the maximum number > of hash verifications needed is n (independently of the number of > packets exchanged with each locator) I agree that you do not wish to verify HBA or CGA on a per-packet basis. (If that were the case, it would be horrible.) As for the number of hash verifications, it would seem that you only have to verify those addresses that you actually use for exchanging packets with the peer. That is, if there is no problem you don't necessarily have to verify anything. And if you have a problem, it suffices to test the addresses that you actually end up switching to instead. (I'm still wondering whether the test packets sent to address X need verification of X; there may be some denial-of-service issues if we don't do that.) --Jari From owner-multi6@ops.ietf.org Tue Nov 16 14:42:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04275 for ; Tue, 16 Nov 2004 14:42:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CU9Dh-000HLo-La for multi6-data@psg.com; Tue, 16 Nov 2004 19:42:29 +0000 Received: from [66.163.170.84] (helo=smtp814.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CU9Dg-000HLX-Lk for multi6@ops.ietf.org; Tue, 16 Nov 2004 19:42:28 +0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 16 Nov 2004 19:42:27 -0000 Message-ID: <007301c4cc14$688dc430$861167c0@adithya> From: "Mohan Parthasarathy" To: "marcelo bagnulo braun" Cc: References: <005f01c4cc12$0fbed9e0$861167c0@adithya> Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Tue, 16 Nov 2004 11:42:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,OBSCURED_EMAIL autolearn=no version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > > >> > >>> I had a few comments/questions on this draft. Sorry if some of them > >>> have already been > >>> asked (i did not look closely at the archives). > >>> > >>> 1) In section 1, > >>> > >>> In addition, it should also be noted that it > >>> is not required that all interface identifiers of the addresses of > >>> an > >>> HBA set are equal, preserving some degree of privacy through > >>> changes > >>> in the addresses used during the communications. > >>> > >>> To create all addresses (for various prefixes) with same interface > >>> identifiers, what is the > >>> change that would be needed ? Does including the multi-prefix > >>> extension and removing the subnet-prefix > >>> in the second hash calculation (Hash1 in CGA draft) sufficient ? > >> > >> Yes, but this imply not to be compliant with CGA spec. > >> in other words, if we are compliant with CGAs, the iid will be > >> different and it wouldn't be possible to have equal iids > >> > >> we felt that cga compatibility was more important than supporting > >> equal > >> iids in the HBAs of a given set (note that we do see some value in > >> having equal iids, for instance for simplified management, but this > >> cannot be provided in the CGA format) > >> > > I thought we have 3 different types of addresses now. The procedure to > > compute the hash is different depending on HBA or CGA i.e include the > > public key or extended modifier depending on CGA or HBA. So, why does > > it matter if we can specify something different for HBA address ? Both > > ends > > know they are operating on an HBA address. So, what is the > > compatibility > > issue ? Could you elaborate on that ? > > > > Well, the HBA is defined always (in the 3 cases) as an extension of the > CGA. > i agree with you that we could define the HBA as an extension of the > CGA when the CGA is also used (i.e. the HBA/CGA hybrid) and define the > HBA in a different way when the CGA are not used (HBA only mode) > But i am not sure this is worthy, since i guess it would be more > complex since you need to handle multiple generation algorithms, > depending in the case. suppose the case when a a communication has a > CGA/HBA and a HBA only in the other side, this would probably would be > more complex either. I mean, having a different generation for the I don't understand this part. If one side is using CGA/HBA and the other is using HBA, the common set is HBA, right ? > generation of the HBA only case would essentially provide that all the > iids are the same in an HBA set, but with an additional complexity in > the implementation, do you think that it is worthy? > I am not sure about the complexity part. We are computing a hash with slightly different set of arguments depending on the type HBA, CGA, HBA/CGA. So, i must be missing something. Perhaps it is not a big deal to have different IIDs for each of the prefix. Did the DT see any use for generating addresses with the same IID ? > > > >>> I was wondering whether it would make any difference between > >>> including > >>> the prefix Vs the whole address itself in the CGA parameter data > >>> structrure ? > >> > >> i am not following you here. > >> The CGA parameter data structure is used to generate the iid of the > >> addresses, so how can you include the complete address in it if you > >> still haven't generate it yet.... i am probably missing your point > >> here > >> > > I mean, you can generate the address and include it..but it is not > > needed as > > you mention below.. > > > >>> I am not able > >>> to see anything less secure by including the whole address itself. > >>> One possibility is that > >>> the peer can compute and validate the address ahead of time (which > >>> is of no use if rehoming > >>> will never occur) and hash verification becomes a simple comparison > >>> when a packet with different locator comes in. > >> > >> but this can be done with the current CGA parameter data structure, > >> right? > >> i mean, the HBA set generation only uses the info contained in the CGA > >> parameter data structure, so once the peer has the CGA parameter data > >> structure, it can regenerate the whole HBA set before the rehoming, as > >> you suggest. > >> > >> i mean, i think you can do this that you suggest already > >> > > Agreed. I was thinking in a slightly different direction which may not > > be needed i guess. Somebody in one of the multi6 meeting raised a > > point about > > computing the hash and verifying it as expensive. First, the hash is > > not computed > > always i guess. Only after the rehoming occurs. But once the rehoming > > occurs, you > > have to recompute always as long as the locator does not match the > > ULID. Is that right ? > > Then i was wondering whether it is a real problem because it affects > > the fast path processing > > of the packet. Perhaps not because it can be pre-computed. > > > But it may not be necessary > > i guess. The first packet after rehoming will trigger the hash > > computation, but that can > > be cached i guess. Hence the subsequent packets can be compared > > directly > > with the cached value. Does that make sense ? > > > > Yes, > I mean, i would do the following. > first the communication is set up, and at some moment in time the CGA > parameters are exchanged. For now, no hash calculation. > Suddenly, an different locator needs to be used. So at this point, i > would run the verification process, implying a hash calculation. > then as long this is the locator that is used, i don't think that > additional verification are needed, you just need to remember that this > locator is OK > So, i would say that for a HBA set with n prefixes, the maximum number > of hash verifications needed is n (independently of the number of > packets exchanged with each locator) > Agreed. When we have this detail in the solution draft, there won't be confusion about the complexity of the hash verification etc. > >> > >>> Also, how important is return routability for the locators before > >>> they are used ? It is not discussed here. > >>> As it is hard for the attacker to redirect packets to a victim, is > >>> it needed ? Can it be optional ? > >> > >> very good point > >> HBAs are mainly used to prevent hijacking attacks and to prevent > >> flooding attacks. We will need reachability tests to prevent flooding > >> attacks. I will include this also in the doc. > >> > > I am not sure i understood the above sentence. > > well as it is stated it is impossible to understand (i am sorry for > that) > > What i wanted to say was: > > HBAs are mainly used to prevent hijacking attacks. > We will need reachability tests to prevent flooding > attacks. > > > However, an additional consideration about this... > Note that if HBAs are used, flooding a specific target host is very > difficult, since i would need to find an HBA set that contains an > address with the attacker prefix and that the address of the victim is > included in the HBA set, agree? > > this is very difficult (O^(59+(16*Sec)) difficult > Agreed. > However, the flooding attack can be easily directed to the access link > or access router of the victim, since the attacker only need to include > the prefix of the victim's network in the prefix set. > > This means that the resulting HBA set won't contain any address of a > real host within the victim's network, but in any case the flood will > be routed to the access router of the victim's network flooding the > access link and the access router. > > So even if the flooding attack is slightly different, i guess that it > would still make sense to provide some protection from it, agree? > Agreed. Now i am not sure about RR being optional :-) -mohan > regards, marcelo > > > > First you say that HBA can > > be used to prevent flooding attacks and then you say that we need > > reachaility tests to prevent flooding attacks. > > > > -mohan > > > >> Thank you very much for your constructive comments > >> I hope i can address them in a satisfactory manner in the next > >> version. > >> Please let me know if i wasn't successful > >> > >> regards, marcelo > >> > >>> > >>> -mohan > >>> > >>> > >> ------------------------------------------ > >> Please note that my former email address > >> mbagnulo@ing.uc3m.es is no longer in use > >> Please send mail to: > >> marcelo at it dot uc3m dot es > >> ------------------------------------------ > >> > > > > > ------------------------------------------ > Please note that my former email address > mbagnulo@ing.uc3m.es is no longer in use > Please send mail to: > marcelo at it dot uc3m dot es > ------------------------------------------ > > From owner-multi6@ops.ietf.org Tue Nov 16 16:20:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15424 for ; Tue, 16 Nov 2004 16:20:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUAjq-0002Ik-Qz for multi6-data@psg.com; Tue, 16 Nov 2004 21:19:46 +0000 Received: from [66.163.170.84] (helo=smtp814.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CUAjp-0002IP-KR for multi6@ops.ietf.org; Tue, 16 Nov 2004 21:19:45 +0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 16 Nov 2004 21:19:45 -0000 Message-ID: <009701c4cc21$ff7ce9e0$861167c0@adithya> From: "Mohan Parthasarathy" To: Cc: "marcelo bagnulo braun" , References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <419A5475.2000901@piuha.net> Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Tue, 16 Nov 2004 13:19:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > Hi Mohan, and thanks for your comments. Some discussion > inline: > > > I thought we have 3 different types of addresses now. The procedure to > > compute the hash is different depending on HBA or CGA i.e include the > > public key or extended modifier depending on CGA or HBA. So, why does > > it matter if we can specify something different for HBA address ? Both ends > > know they are operating on an HBA address. So, what is the compatibility > > issue ? Could you elaborate on that ? > > Actually, I believe the intent is to have just one address > format, basically according to the SEND CGA draft with some > optional data that is going to make things easier in some > cases. So the cases that we have are: > > - CGA format + pure CGA: all rehoming events require a PK operation > - CGA format + pure HBA: a set of fixed prefixes is included and > no other addresses than the fixed ones are expected: > all rehoming events can be done with a symmetric > crypto > - CGA format + HBA + CGA: as above, but if you need to > go beyond the originally listed address set you can > switch to using the public key > > As for the interoperability problem -- at least my > main issue is that IPv6 components such as SEND or MULTI6 > do not require you to allocate different addresses; that > you can actually use both features at the same time. You > could of course do this so that MULTI6 module decides to > use the CGA format if it also wants to do SEND or does > not know the set of prefixes beforehand, and HBA format > otherwise. But using a single format seems simpler. Plus > I actually like the fact that the IIDs are different :-) > I don't have any problems with IIDs being different :-) But i was more trying to understand the compatibility problem. Multi6 module anyway has to do different processing if the address is a HBA address or if it is a CGA/HBA address. Now you can still use the same format for generating a single IID for all the prefixes e.g. using all zeroes or all ones for the subnet prefix field of the CGA parameters data structure. (but including the multi-prefix extension at the end as specified now) Assuming we can find such a thing, would it be considered simpler ? > > Agreed. I was thinking in a slightly different direction which may not > > be needed i guess. Somebody in one of the multi6 meeting raised a point about > > computing the hash and verifying it as expensive. First, the hash is not computed > > always i guess. Only after the rehoming occurs. But once the rehoming occurs, you > > have to recompute always as long as the locator does not match the ULID. Is that right ? > > Then i was wondering whether it is a real problem because it affects the fast path processing > > of the packet. Perhaps not because it can be pre-computed. But it may not be necessary > > i guess. The first packet after rehoming will trigger the hash computation, but that can > > be cached i guess. Hence the subsequent packets can be compared directly > > with the cached value. Does that make sense ? > > I think we need to treat fast path for payload packets and > signaling differently. Either at the beginning or at a > rehoming event there's going to be some signaling. I don't > believe fast pathing this signaling is going to be necessary. > However, once you have determined that an address belongs to > the peer (either through HBA or CGA proof), presumably you > should be able to set up whatever processing of fast path > mechanism you need for packets arriving with any of the legal > address pairs. And in the worst case all of these pairs are > going to need a mapping from the on-the-wire address pairs to > the ULID pairs. So, conceptually, if you receive the "M6 header" > then you do the mapping. This should be fast too, I think. > But if you receive an indication of a problem or some message > from the peer claiming that it has changed its address, that > is going to need at least a hash operation as well as some > amount of data structure modifications in the stack. > Agreed. > >>very good point > >>HBAs are mainly used to prevent hijacking attacks and to prevent > >>flooding attacks. We will need reachability tests to prevent flooding > >>attacks. I will include this also in the doc. > >> > > > > I am not sure i understood the above sentence. First you say that HBA can > > be used to prevent flooding attacks and then you say that we need > > reachaility tests to prevent flooding attacks. > > Reachability tests are needed to prevent flooding attacks, > because HBA and CGA techniques can only show that you generated > the address, not that you actually are on the link. HBA/CGA > on the other hand is needed to ensure that you can't hijack > any else's address. The "victims" in these two cases are > different: in the first case its third parties, in the > second case it is an "owner" of an address. > This flooding attack is slightly different from the one mentioned in the threats document because there is no real victim invovled. Just the routers and links which still needs to be prevented. -mohan > --Jari > From owner-multi6@ops.ietf.org Tue Nov 16 17:53:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05502 for ; Tue, 16 Nov 2004 17:53:52 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUCBq-000Cp1-Sz for multi6-data@psg.com; Tue, 16 Nov 2004 22:52:46 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUCBq-000Cop-4j for multi6@ops.ietf.org; Tue, 16 Nov 2004 22:52:46 +0000 Received: from jurassic.eng.sun.com ([129.146.89.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iAGMqfr7025360; Tue, 16 Nov 2004 14:52:41 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAGMqcxA476499; Tue, 16 Nov 2004 14:52:39 -0800 (PST) Message-ID: <419A84ED.30309@sun.com> Date: Tue, 16 Nov 2004 14:53:33 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy CC: jari.arkko@piuha.net, marcelo bagnulo braun , multi6@ops.ietf.org Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <419A5475.2000901@piuha.net> <009701c4cc21$ff7ce9e0$861167c0@adithya> In-Reply-To: <009701c4cc21$ff7ce9e0$861167c0@adithya> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: > I don't have any problems with IIDs being different :-) But i was more > trying to understand the compatibility problem. Multi6 module anyway > has to do different processing if the address is a HBA address or > if it is a CGA/HBA address. Now you can still use the same format for > generating a single IID for all the prefixes e.g. using all zeroes or all > ones for the subnet prefix field of the CGA parameters data structure. > (but including the multi-prefix extension at the end as specified now) > Assuming we can find such a thing, would it be considered simpler ? But then the IID(s) needed for SeND would be different than the IID(s) needed for multi6, right? Then which of the addresses (with which IDD) would a host which wants to take advantage of both SeND and multi6 at the same time use? Which addresses would it put in the DNS for itself? Erik From owner-multi6@ops.ietf.org Tue Nov 16 20:35:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20826 for ; Tue, 16 Nov 2004 20:35:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUEhw-00026t-VJ for multi6-data@psg.com; Wed, 17 Nov 2004 01:34:04 +0000 Received: from [66.218.79.92] (helo=web80603.mail.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CUEhw-00026e-0N for multi6@ops.ietf.org; Wed, 17 Nov 2004 01:34:04 +0000 Message-ID: <20041117013403.4343.qmail@web80603.mail.yahoo.com> Received: from [206.132.194.2] by web80603.mail.yahoo.com via HTTP; Tue, 16 Nov 2004 17:34:03 PST Date: Tue, 16 Nov 2004 17:34:03 -0800 (PST) From: Mohan Parthasarathy Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt To: Erik Nordmark Cc: jari.arkko@piuha.net, marcelo bagnulo braun , multi6@ops.ietf.org In-Reply-To: <419A84ED.30309@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Erik, > Mohan Parthasarathy wrote: > > > I don't have any problems with IIDs being > different :-) But i was more > > trying to understand the compatibility problem. > Multi6 module anyway > > has to do different processing if the address is a > HBA address or > > if it is a CGA/HBA address. Now you can still use > the same format for > > generating a single IID for all the prefixes e.g. > using all zeroes or all > > ones for the subnet prefix field of the CGA > parameters data structure. > > (but including the multi-prefix extension at the > end as specified now) > > Assuming we can find such a thing, would it be > considered simpler ? > > But then the IID(s) needed for SeND would be > different than the IID(s) > needed for multi6, right? > > Then which of the addresses (with which IDD) would a > host which wants to > take advantage of both SeND and multi6 at the same > time use? > Which addresses would it put in the DNS for itself? > If you want to have an address that can be used both by SEND and Multi6, then you would generate an address that includes both the public key and multi-prefix extension as defined now. But my original question was more specific to HBA addresses that can be generated for all prefixes with the same identifier. HBA only addresses anyway requires slightly different processing. So, i don't know what the issue is with generating the same identifier, if needed or someone finds a use for it. I realize that if a node wants to use SEND and multi6, then the easy way to do is to generate a CGA/HBA address. Otherwise the issues that you raise above needs to be solved. -mohan > Erik > From owner-multi6@ops.ietf.org Wed Nov 17 11:12:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13463 for ; Wed, 17 Nov 2004 11:12:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUSOY-000Cc3-LU for multi6-data@psg.com; Wed, 17 Nov 2004 16:10:58 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUSOX-000Cbk-Tq for multi6@ops.ietf.org; Wed, 17 Nov 2004 16:10:58 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id C7B9F2DD95; Wed, 17 Nov 2004 17:10:54 +0100 (CET) Received: from [163.117.139.34] (unknown [163.117.139.34]) by smtp02.uc3m.es (Postfix) with ESMTP id 601652DE17; Wed, 17 Nov 2004 17:10:52 +0100 (CET) In-Reply-To: <009701c4cc21$ff7ce9e0$861167c0@adithya> References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <419A5475.2000901@piuha.net> <009701c4cc21$ff7ce9e0$861167c0@adithya> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <42A84E2B-38B3-11D9-AEEC-000D93ACD0FE@it> Content-Transfer-Encoding: 7bit Cc: , , "marcelo bagnulo braun" From: marcelo bagnulo braun Subject: flooding attacks and threats doc (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Wed, 17 Nov 2004 17:10:55 +0100 To: Mohan Parthasarathy , Erik Nordmark X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > This flooding attack is slightly different from the one mentioned in > the > threats document because there is no real victim invovled. Just the > routers and links which still needs to be prevented. > perhaps it would make sense to mention explicitly in the threats document that the target of a flooding attack may not be a host but an access link or an access router? regards, marcelo > -mohan > >> --Jari >> > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Nov 17 11:14:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13838 for ; Wed, 17 Nov 2004 11:14:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUSRa-000Cv9-Vt for multi6-data@psg.com; Wed, 17 Nov 2004 16:14:06 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUSRQ-000Cts-Ee for multi6@ops.ietf.org; Wed, 17 Nov 2004 16:13:56 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 7E7482DDF4; Wed, 17 Nov 2004 17:13:55 +0100 (CET) Received: from [163.117.139.34] (unknown [163.117.139.34]) by smtp02.uc3m.es (Postfix) with ESMTP id 6D2FB2DE39; Wed, 17 Nov 2004 17:13:46 +0100 (CET) In-Reply-To: <419A573A.90900@piuha.net> References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <9E1079A2-37FE-11D9-AEEC-000D93ACD0FE@it.uc3m.es> <419A573A.90900@piuha.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Mohan Parthasarathy , multi6@ops.ietf.org, marcelo bagnulo braun From: marcelo bagnulo braun Subject: reachability test verification (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Wed, 17 Nov 2004 17:13:49 +0100 To: jari.arkko@piuha.net X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jari, El 16/11/2004, a las 20:38, Jari Arkko escribi=F3: > As for the number of hash verifications, it would seem that > you only have to verify those addresses that you actually use > for exchanging packets with the peer. That is, if there is no > problem you don't necessarily have to verify anything. And > if you have a problem, it suffices to test the addresses > that you actually end up switching to instead. (I'm still > wondering whether the test packets sent to address X need > verification of X; there may be some denial-of-service issues > if we don't do that.) > The question would be: do we do the reachanility test first or the HBA=20= verification first? is this what you have in mind? regards, marcelo > --Jari > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Nov 17 11:37:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16602 for ; Wed, 17 Nov 2004 11:37:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUSnj-000F89-Qp for multi6-data@psg.com; Wed, 17 Nov 2004 16:36:59 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUSnU-000F6f-Ci for multi6@ops.ietf.org; Wed, 17 Nov 2004 16:36:44 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 3B7582DD62; Wed, 17 Nov 2004 17:06:44 +0100 (CET) Received: from [163.117.139.34] (unknown [163.117.139.34]) by smtp02.uc3m.es (Postfix) with ESMTP id 764502DD48; Wed, 17 Nov 2004 17:06:38 +0100 (CET) In-Reply-To: <20041117013403.4343.qmail@web80603.mail.yahoo.com> References: <20041117013403.4343.qmail@web80603.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org, jari.arkko@piuha.net, marcelo bagnulo braun , Erik Nordmark From: marcelo bagnulo braun Subject: HBA format (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Wed, 17 Nov 2004 17:06:41 +0100 To: Mohan Parthasarathy X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, With respect to the HBA format i guess that we can comment that: - It is clear that it is valuable to support hybrid HBA/CGA format, in=20= order to be able to do SeND and multi6 with the same address. - In order to do this we need to define the HBA as a CGa extension, at=20= least in this particular case - This implies that the iids of the addresses of an HBA set will be=20 different - This is good because it provides enhanced privacy - This may imply a more difficult management and would preclude solutions based on source address rewriting by the site exit router Now w.r.t. HBA only addresses. I guess we could define a different format for these, so that the same=20= iid is maintained though the different addresses of an HBA, but this=20 would imply an additional complexity. the cause of this complexity is=20 that a node would need to support BOTH formats. This is so becuase it=20 is difficutl to say that for instance fixed hosts won't need CGA=20 features, since they are usefull to support renumbering events.=20 Moreover, a given node may choose to use only HBA, but its peers may=20 choose to use HBA/CGA addresses, so any node will have to understand=20 both formats. There have been concerns about the complexity of even implementing HBAs=20= as an extension, i guess that these concerns would be greater if two=20 different formats are proposed. So sumarizing, the trade off as i see it is: one common format provides less complexity, (only one format is=20 required) two formats provides same iids in the different asddreses in the HBA=20 set. Soem people not even want this, so i guess that we would need to=20 define privacy extensions for this format ( i have done this and it is=20= just like CGA format) i would prefer one format, becuase imho simplicity is important regards, marcelo El 17/11/2004, a las 2:34, Mohan Parthasarathy escribi=F3: > > Erik, > >> Mohan Parthasarathy wrote: >> >>> I don't have any problems with IIDs being >> different :-) But i was more >>> trying to understand the compatibility problem. >> Multi6 module anyway >>> has to do different processing if the address is a >> HBA address or >>> if it is a CGA/HBA address. Now you can still use >> the same format for >>> generating a single IID for all the prefixes e.g. >> using all zeroes or all >>> ones for the subnet prefix field of the CGA >> parameters data structure. >>> (but including the multi-prefix extension at the >> end as specified now) >>> Assuming we can find such a thing, would it be >> considered simpler ? >> >> But then the IID(s) needed for SeND would be >> different than the IID(s) >> needed for multi6, right? >> >> Then which of the addresses (with which IDD) would a >> host which wants to >> take advantage of both SeND and multi6 at the same >> time use? >> Which addresses would it put in the DNS for itself? >> > If you want to have an address that can be used both > by SEND and Multi6, then you would generate an address > that includes both the public key and multi-prefix > extension as defined now. But my original question > was more specific to HBA addresses that can be > generated for all prefixes with the same identifier. > HBA only addresses anyway requires slightly > different processing. So, i don't know what > the issue is with generating the same identifier, > if needed or someone finds a use for it. > > I realize that if a node wants to use SEND and multi6, > then the easy way to do is to generate a CGA/HBA > address. Otherwise the issues that you raise above > needs to be solved. > > -mohan > > >> Erik >> > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Nov 17 11:58:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19120 for ; Wed, 17 Nov 2004 11:58:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUT8Y-000Hc6-39 for multi6-data@psg.com; Wed, 17 Nov 2004 16:58:30 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUT8Q-000Hat-PQ for multi6@ops.ietf.org; Wed, 17 Nov 2004 16:58:22 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id F161D89892; Wed, 17 Nov 2004 18:58:21 +0200 (EET) Message-ID: <419B82BE.5080109@piuha.net> Date: Wed, 17 Nov 2004 18:56:30 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun Cc: multi6@ops.ietf.org Subject: Re: reachability test verification (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <9E1079A2-37FE-11D9-AEEC-000D93ACD0FE@it.uc3m.es> <419A573A.90900@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit marcelo bagnulo braun wrote: > Hi Jari, > > El 16/11/2004, a las 20:38, Jari Arkko escribió: > >> As for the number of hash verifications, it would seem that >> you only have to verify those addresses that you actually use >> for exchanging packets with the peer. That is, if there is no >> problem you don't necessarily have to verify anything. And >> if you have a problem, it suffices to test the addresses >> that you actually end up switching to instead. (I'm still >> wondering whether the test packets sent to address X need >> verification of X; there may be some denial-of-service issues >> if we don't do that.) >> > > The question would be: do we do the reachanility test first or the HBA > verification first? is this what you have in mind? That was the question I had. It seems that it would be best if you could verify HBA/CGA first and only then send a packet. --Jari From owner-multi6@ops.ietf.org Wed Nov 17 12:00:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19277 for ; Wed, 17 Nov 2004 12:00:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUTAM-000Hwz-H1 for multi6-data@psg.com; Wed, 17 Nov 2004 17:00:22 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUTAF-000Hvp-Cz for multi6@ops.ietf.org; Wed, 17 Nov 2004 17:00:15 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9BCD489892; Wed, 17 Nov 2004 19:00:14 +0200 (EET) Message-ID: <419B832F.8080200@piuha.net> Date: Wed, 17 Nov 2004 18:58:23 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun Cc: multi6@ops.ietf.org Subject: Re: flooding attacks and threats doc (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <419A5475.2000901@piuha.net> <009701c4cc21$ff7ce9e0$861167c0@adithya> <42A84E2B-38B3-11D9-AEEC-000D93ACD0FE@it> In-Reply-To: <42A84E2B-38B3-11D9-AEEC-000D93ACD0FE@it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo braun wrote: >> This flooding attack is slightly different from the one mentioned in the >> threats document because there is no real victim invovled. Just the >> routers and links which still needs to be prevented. >> > > perhaps it would make sense to mention explicitly in the threats > document that the target of a flooding attack may not be a host but an > access link or an access router? I agree that the target can be not just a host but also a link, router, or a network. If the threats document claims otherwise then it needs to be corrected. Of course there are some differences in the threat to a host and to a network, but if you move someone's DVD download on my GPRS link, I'm hosed whether or not the target address is my host's address. --Jari From owner-multi6@ops.ietf.org Wed Nov 17 12:58:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25053 for ; Wed, 17 Nov 2004 12:58:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUU3Z-000Nzs-R7 for multi6-data@psg.com; Wed, 17 Nov 2004 17:57:25 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUU3Z-000Nzg-6n for multi6@ops.ietf.org; Wed, 17 Nov 2004 17:57:25 +0000 Received: from jurassic.eng.sun.com ([129.146.87.31]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iAHHvKr7025112; Wed, 17 Nov 2004 09:57:21 -0800 (PST) Received: from [129.146.89.128] (d-mpk17-89-128.SFBay.Sun.COM [129.146.89.128]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAHHvKS7697091; Wed, 17 Nov 2004 09:57:20 -0800 (PST) Message-ID: <419B9135.8060608@sun.com> Date: Wed, 17 Nov 2004 09:58:13 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy CC: jari.arkko@piuha.net, marcelo bagnulo braun , multi6@ops.ietf.org Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <20041117013403.4343.qmail@web80603.mail.yahoo.com> In-Reply-To: <20041117013403.4343.qmail@web80603.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: > If you want to have an address that can be used both > by SEND and Multi6, then you would generate an address > that includes both the public key and multi-prefix > extension as defined now. But my original question > was more specific to HBA addresses that can be > generated for all prefixes with the same identifier. > HBA only addresses anyway requires slightly > different processing. So, i don't know what > the issue is with generating the same identifier, > if needed or someone finds a use for it. OK - sorry for misunderstanding. I think Marcelo stated the issues today. What do you see as the benefit of having the same iid for all prefixes? Erik From owner-multi6@ops.ietf.org Wed Nov 17 12:59:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25144 for ; Wed, 17 Nov 2004 12:59:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUU5J-000OFK-4B for multi6-data@psg.com; Wed, 17 Nov 2004 17:59:13 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUU5I-000OF6-Bz for multi6@ops.ietf.org; Wed, 17 Nov 2004 17:59:12 +0000 Received: from jurassic.eng.sun.com ([129.146.83.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAHHx9ui006396; Wed, 17 Nov 2004 10:59:09 -0700 (MST) Received: from [129.146.89.128] (d-mpk17-89-128.SFBay.Sun.COM [129.146.89.128]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAHHx9bf698553; Wed, 17 Nov 2004 09:59:09 -0800 (PST) Message-ID: <419B91A1.5010505@sun.com> Date: Wed, 17 Nov 2004 10:00:01 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun CC: Mohan Parthasarathy , jari.arkko@piuha.net, multi6@ops.ietf.org Subject: Re: flooding attacks and threats doc (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <419A5475.2000901@piuha.net> <009701c4cc21$ff7ce9e0$861167c0@adithya> <42A84E2B-38B3-11D9-AEEC-000D93ACD0FE@it> In-Reply-To: <42A84E2B-38B3-11D9-AEEC-000D93ACD0FE@it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo braun wrote: >> This flooding attack is slightly different from the one mentioned in the >> threats document because there is no real victim invovled. Just the >> routers and links which still needs to be prevented. >> > > perhaps it would make sense to mention explicitly in the threats > document that the target of a flooding attack may not be a host but an > access link or an access router? What do others think? I'll send in an updated threats document later this week (just waiting for an answer from Rob Austein) so if folks want a clarification about this let me know soon. (And text to include would be appreciated as always.) Erik From owner-multi6@ops.ietf.org Wed Nov 17 15:43:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10533 for ; Wed, 17 Nov 2004 15:43:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUWdG-000EzH-P3 for multi6-data@psg.com; Wed, 17 Nov 2004 20:42:26 +0000 Received: from [66.218.79.94] (helo=web80605.mail.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CUWdF-000Ez1-1t for multi6@ops.ietf.org; Wed, 17 Nov 2004 20:42:25 +0000 Message-ID: <20041117204224.37676.qmail@web80605.mail.yahoo.com> Received: from [206.132.194.3] by web80605.mail.yahoo.com via HTTP; Wed, 17 Nov 2004 12:42:24 PST Date: Wed, 17 Nov 2004 12:42:24 -0800 (PST) From: Mohan Parthasarathy Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt To: Erik Nordmark Cc: jari.arkko@piuha.net, marcelo bagnulo braun , multi6@ops.ietf.org In-Reply-To: <419B9135.8060608@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk --- Erik Nordmark wrote: > Mohan Parthasarathy wrote: > > > If you want to have an address that can be used > both > > by SEND and Multi6, then you would generate an > address > > that includes both the public key and multi-prefix > > extension as defined now. But my original question > > was more specific to HBA addresses that can be > > generated for all prefixes with the same > identifier. > > HBA only addresses anyway requires slightly > > different processing. So, i don't know what > > the issue is with generating the same identifier, > > if needed or someone finds a use for it. > > OK - sorry for misunderstanding. > > I think Marcelo stated the issues today. > > What do you see as the benefit of having the same > iid for all prefixes? > None :-) I was only trying to find out the reason as to why this can't be done or easily supported without changing the format. I am fine with having different IID for different prefixes. The reason that we don't want to support same IID could be that we don't see any use for it or that it is simplicity or something else. I was just trying to understand that. -mohan > Erik > > > From owner-multi6@ops.ietf.org Thu Nov 18 05:35:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10514 for ; Thu, 18 Nov 2004 05:35:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUjav-000K5R-Fx for multi6-data@psg.com; Thu, 18 Nov 2004 10:32:53 +0000 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUjao-000K56-34 for multi6@ops.ietf.org; Thu, 18 Nov 2004 10:32:46 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAIAWepN275898 for ; Thu, 18 Nov 2004 10:32:40 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAIAWgWX030282 for ; Thu, 18 Nov 2004 10:32:42 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iAIAWd3a018207 for ; Thu, 18 Nov 2004 10:32:40 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iAIAWdeJ018174; Thu, 18 Nov 2004 10:32:39 GMT Received: from zurich.ibm.com (sig-9-146-220-147.de.ibm.com [9.146.220.147]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA37736; Thu, 18 Nov 2004 11:32:35 +0100 Message-ID: <419C7A40.90400@zurich.ibm.com> Date: Thu, 18 Nov 2004 11:32:32 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: marcelo bagnulo braun , Mohan Parthasarathy , jari.arkko@piuha.net, multi6@ops.ietf.org Subject: Re: flooding attacks and threats doc (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <419A5475.2000901@piuha.net> <009701c4cc21$ff7ce9e0$861167c0@adithya> <42A84E2B-38B3-11D9-AEEC-000D93ACD0FE@it> <419B91A1.5010505@sun.com> In-Reply-To: <419B91A1.5010505@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > marcelo bagnulo braun wrote: > >>> This flooding attack is slightly different from the one mentioned in the >>> threats document because there is no real victim invovled. Just the >>> routers and links which still needs to be prevented. >>> >> >> perhaps it would make sense to mention explicitly in the threats >> document that the target of a flooding attack may not be a host but an >> access link or an access router? > > > What do others think? I'll send in an updated threats document later > this week (just waiting for an answer from Rob Austein) so if folks want > a clarification about this let me know soon. > (And text to include would be appreciated as always.) I wouldn't object to this being included, but flooding attacks on generic targets are kind of a generic Internet threat anyway. I'd want to see text that very explicitly says why this is a threat *made worse* by the presence of multi6. Brian From owner-multi6@ops.ietf.org Thu Nov 18 05:40:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11063 for ; Thu, 18 Nov 2004 05:40:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUjhC-000Kdg-AA for multi6-data@psg.com; Thu, 18 Nov 2004 10:39:22 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUjhB-000KdL-4N for multi6@ops.ietf.org; Thu, 18 Nov 2004 10:39:21 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 90BE58988E; Thu, 18 Nov 2004 12:39:19 +0200 (EET) Message-ID: <419C7B67.8090703@piuha.net> Date: Thu, 18 Nov 2004 12:37:27 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: Erik Nordmark , multi6@ops.ietf.org Subject: Re: flooding attacks and threats doc (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <419A5475.2000901@piuha.net> <009701c4cc21$ff7ce9e0$861167c0@adithya> <42A84E2B-38B3-11D9-AEEC-000D93ACD0FE@it> <419B91A1.5010505@sun.com> <419C7A40.90400@zurich.ibm.com> In-Reply-To: <419C7A40.90400@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I wouldn't object to this being included, but flooding attacks > on generic targets are kind of a generic Internet threat anyway. > I'd want to see text that very explicitly says why this is > a threat *made worse* by the presence of multi6. Right. And I think we have that explanation, it relates to amplification. There's plenty of documents that can be referenced regarding this issue from the threats doc. See for instance draft-ietf-mip6-ro-sec-02.txt Section 3.2.1, draft-vogt-mipv6-credit-based-authorization-00.txt Section 3, Aura et al: "Security of Internet Location Management" (ACSAC), etc. --Jari From owner-multi6@ops.ietf.org Thu Nov 18 08:15:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22737 for ; Thu, 18 Nov 2004 08:15:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUm7f-000I0t-8f for multi6-data@psg.com; Thu, 18 Nov 2004 13:14:51 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUm7e-000I0Z-1x for multi6@ops.ietf.org; Thu, 18 Nov 2004 13:14:50 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAIDEeJ19290; Thu, 18 Nov 2004 14:14:40 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iAIDEeSj031116; Thu, 18 Nov 2004 14:14:40 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411181314.iAIDEeSj031116@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Mohan Parthasarathy , jari.arkko@piuha.net, marcelo bagnulo braun , multi6@ops.ietf.org Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt In-reply-to: Your message of Tue, 16 Nov 2004 14:53:33 PST. <419A84ED.30309@sun.com> Date: Thu, 18 Nov 2004 14:14:40 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: Mohan Parthasarathy wrote: > I don't have any problems with IIDs being different :-) But i was more > trying to understand the compatibility problem. Multi6 module anyway > has to do different processing if the address is a HBA address or > if it is a CGA/HBA address. Now you can still use the same format for > generating a single IID for all the prefixes e.g. using all zeroes or all > ones for the subnet prefix field of the CGA parameters data structure. > (but including the multi-prefix extension at the end as specified now) > Assuming we can find such a thing, would it be considered simpler ? But then the IID(s) needed for SeND would be different than the IID(s) needed for multi6, right? => no, HBA idea has two parts: - an instance of the extensions (for this part HBAs are a subclass of CGAs) - a pseudo-public key (this removes only the ownership stuff, not the verification, of course this is optional). All the hash and signature stuff is exactly the same, so the IID(s). Then which of the addresses (with which IDD) would a host which wants to take advantage of both SeND and multi6 at the same time use? => HBAs with a real private/public key pair which are an extension of CGAs. Which addresses would it put in the DNS for itself? => the HBAs. Regards Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Thu Nov 18 09:04:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26348 for ; Thu, 18 Nov 2004 09:04:50 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUmtD-000Pe6-Rj for multi6-data@psg.com; Thu, 18 Nov 2004 14:03:59 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUmtC-000Pdm-Tn for multi6@ops.ietf.org; Thu, 18 Nov 2004 14:03:59 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id 8169B3037A; Thu, 18 Nov 2004 15:03:57 +0100 (CET) Received: from [163.117.139.34] (unknown [163.117.139.34]) by smtp03.uc3m.es (Postfix) with ESMTP id 396713036E; Thu, 18 Nov 2004 15:03:55 +0100 (CET) In-Reply-To: <419B82BE.5080109@piuha.net> References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <9E1079A2-37FE-11D9-AEEC-000D93ACD0FE@it.uc3m.es> <419A573A.90900@piuha.net> <419B82BE.5080109@piuha.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org, marcelo bagnulo braun From: marcelo bagnulo braun Subject: Re: reachability test verification (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Thu, 18 Nov 2004 15:03:59 +0100 To: jari.arkko@piuha.net X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 17/11/2004, a las 17:56, Jari Arkko escribi=F3: > marcelo bagnulo braun wrote: >> Hi Jari, >> El 16/11/2004, a las 20:38, Jari Arkko escribi=F3: >>> As for the number of hash verifications, it would seem that >>> you only have to verify those addresses that you actually use >>> for exchanging packets with the peer. That is, if there is no >>> problem you don't necessarily have to verify anything. And >>> if you have a problem, it suffices to test the addresses >>> that you actually end up switching to instead. (I'm still >>> wondering whether the test packets sent to address X need >>> verification of X; there may be some denial-of-service issues >>> if we don't do that.) >>> >> The question would be: do we do the reachanility test first or the=20 >> HBA verification first? is this what you have in mind? > > That was the question I had. It seems that it would be best > if you could verify HBA/CGA first and only then send a packet. > agree regards, marcelo > --Jari > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Thu Nov 18 10:24:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03324 for ; Thu, 18 Nov 2004 10:24:19 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUo7p-000CTR-2U for multi6-data@psg.com; Thu, 18 Nov 2004 15:23:09 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUo7l-000CSQ-1T for multi6@ops.ietf.org; Thu, 18 Nov 2004 15:23:05 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAIFNJQx068045; Thu, 18 Nov 2004 16:23:19 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4198D05A.9040009@piuha.net> References: <200411151525.iAFFP5Sj017261@givry.rennes.enst-bretagne.fr> <4198D05A.9040009@piuha.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: IPR (Was: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt) Date: Thu, 18 Nov 2004 16:23:03 +0100 To: jari.arkko@piuha.net X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 15-nov-04, at 16:50, Jari Arkko wrote: >> PS: BTW CGA IPR holders provide royalty-free licenses only for SEND, >> can they update their IPR texts on the IETF web for HBAs too? > FYI: I have asked the Ericsson IPR department to inform the > IETF about their licensing conditions regarding the HBA draft > and usage in MULTI6. Shouldn't we try to determine whether the patent even applies in the first place? From owner-multi6@ops.ietf.org Thu Nov 18 10:51:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05342 for ; Thu, 18 Nov 2004 10:51:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUoYS-000GEd-5Y for multi6-data@psg.com; Thu, 18 Nov 2004 15:50:40 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUoYC-000GCr-O2 for multi6@ops.ietf.org; Thu, 18 Nov 2004 15:50:25 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAIFoIJ29633; Thu, 18 Nov 2004 16:50:18 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iAIFoISj031838; Thu, 18 Nov 2004 16:50:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411181550.iAIFoISj031838@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Iljitsch van Beijnum cc: jari.arkko@piuha.net, multi6@ops.ietf.org Subject: Re: IPR (Was: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt) In-reply-to: Your message of Thu, 18 Nov 2004 16:23:03 +0100. Date: Thu, 18 Nov 2004 16:50:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: On 15-nov-04, at 16:50, Jari Arkko wrote: >> PS: BTW CGA IPR holders provide royalty-free licenses only for SEND, >> can they update their IPR texts on the IETF web for HBAs too? > FYI: I have asked the Ericsson IPR department to inform the > IETF about their licensing conditions regarding the HBA draft > and usage in MULTI6. Shouldn't we try to determine whether the patent even applies in the first place? => as the HBA idea is an extension of the CGA one, I can't see how the patent can apply to CGA but not to HBA... No, the problem is real, but it should very easy to fix with a better wording in the IPR note. Thanks Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Thu Nov 18 11:11:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06820 for ; Thu, 18 Nov 2004 11:11:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUor3-0001QC-Pm for multi6-data@psg.com; Thu, 18 Nov 2004 16:09:53 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUoqy-0001Pv-BT for multi6@ops.ietf.org; Thu, 18 Nov 2004 16:09:48 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5EBDA2DC3E; Thu, 18 Nov 2004 17:09:48 +0100 (CET) Received: from [163.117.139.34] (unknown [163.117.139.34]) by smtp02.uc3m.es (Postfix) with ESMTP id 455D42DC3D; Thu, 18 Nov 2004 17:09:48 +0100 (CET) In-Reply-To: <200411181550.iAIFoISj031838@givry.rennes.enst-bretagne.fr> References: <200411181550.iAIFoISj031838@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <44CEC4AE-397C-11D9-84BB-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org, jari.arkko@piuha.net, Iljitsch van Beijnum From: marcelo bagnulo braun Subject: Re: IPR (Was: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt) Date: Thu, 18 Nov 2004 17:09:47 +0100 To: Francis Dupont X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable El 18/11/2004, a las 16:50, Francis Dupont escribi=F3: > In your previous mail you wrote: > > On 15-nov-04, at 16:50, Jari Arkko wrote: > >>> PS: BTW CGA IPR holders provide royalty-free licenses only for SEND, >>> can they update their IPR texts on the IETF web for HBAs too? > >> FYI: I have asked the Ericsson IPR department to inform the >> IETF about their licensing conditions regarding the HBA draft >> and usage in MULTI6. > > Shouldn't we try to determine whether the patent even applies in = the > first place? > > =3D> as the HBA idea is an extension of the CGA one, I disagree The HBA uses the format of CGA in order to provide simoultaneous=20 support of SeND and CGA We could prefectly define HBA with a different format, so that it is=20 not extension of CGA (this would cause problems when using multi6 and=20 send of course, which is bad) But the point is that HBA are defined as a CGA extension just to allow=20= Send and multi6 run together regards, marcelo > I can't see how the > patent can apply to CGA but not to HBA... No, the problem is real, > but it should very easy to fix with a better wording in the IPR note. > > Thanks > > Francis.Dupont@enst-bretagne.fr > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Thu Nov 18 11:13:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06950 for ; Thu, 18 Nov 2004 11:13:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUouT-0001rj-NQ for multi6-data@psg.com; Thu, 18 Nov 2004 16:13:25 +0000 Received: from [63.103.94.23] (helo=ftmailgfi.flariontech.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUouS-0001rT-HL for multi6@ops.ietf.org; Thu, 18 Nov 2004 16:13:24 +0000 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Nov 2004 11:13:22 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: IPR (Was: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt) Date: Thu, 18 Nov 2004 11:13:17 -0500 Message-ID: Thread-Topic: IPR (Was: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt) Thread-Index: AcTNiLWDKxkcI6hbTDKxEytfnEBo0AAAJvWQ From: "Soliman, Hesham" To: "Francis Dupont" , "Iljitsch van Beijnum" CC: , X-OriginalArrivalTime: 18 Nov 2004 16:13:22.0243 (UTC) FILETIME=[86689130:01C4CD89] X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > In your previous mail you wrote: >=20 > On 15-nov-04, at 16:50, Jari Arkko wrote: > =20 > >> PS: BTW CGA IPR holders provide royalty-free licenses=20 > only for SEND, > >> can they update their IPR texts on the IETF web for HBAs too? > =20 > > FYI: I have asked the Ericsson IPR department to inform the > > IETF about their licensing conditions regarding the HBA draft > > and usage in MULTI6. > =20 > Shouldn't we try to determine whether the patent even=20 > applies in the=20 > first place? > =20 > =3D> as the HBA idea is an extension of the CGA one, I can't=20 > see how the > patent can apply to CGA but not to HBA... No, the problem is real, > but it should very easy to fix with a better wording in the IPR note. >=20 =3D> I think Microsoft also made claims about CGA, so I'm not sure if the Ericsson IPR statement alone will be sufficient. Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-multi6@ops.ietf.org Thu Nov 18 11:20:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07789 for ; Thu, 18 Nov 2004 11:20:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUp17-0002l5-1S for multi6-data@psg.com; Thu, 18 Nov 2004 16:20:17 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUp16-0002ks-26 for multi6@ops.ietf.org; Thu, 18 Nov 2004 16:20:16 +0000 Received: from [192.168.1.47] (lsanca1-ar42-4-61-185-150.lsanca1.dsl-verizon.net [4.61.185.150]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAIGINt17294; Thu, 18 Nov 2004 08:18:23 -0800 (PST) Message-ID: <419C1C1D.4030708@isi.edu> Date: Wed, 17 Nov 2004 19:50:53 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: john.loughney@nokia.com, multi6@ops.ietf.org Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <84DE7930-3487-11D9-9D6A-000A95CD987A@muada.com> In-Reply-To: <84DE7930-3487-11D9-9D6A-000A95CD987A@muada.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8E318A6702C72AA04D49BDD4" X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8E318A6702C72AA04D49BDD4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > John, > > On 11-nov-04, at 13:55, wrote: > >>>> So what I meant more was that if we use keep-alives at the multi6 >>>> layer, then perhaps this could be something that the upper layer >>>> could set the keep-alive behavior. > > >>> I could just go on disagreeing, but let me ask you this: assuming a >>> decent multihoming solution, under which circumstances would upper >>> layers want to do something like that, trying to achieve which >>> benefits? > > >> I'm not wedded to the use of keep-alives; to back it up a level, >> if there are keep alives at the multi6 level, it would be nice if >> the use of the keep-alive could be tunable by the ULP. If we >> toss out keep-alives at the multi6 level, I won't lose sleep at it. > > > Keepalives aren't really the correct name for what the multi6 layer > needs. The multi6 layer needs to know which address pairs work and which > don't. There are basically two approaches to this: try every combination > and pick the one that loooks best, or start trying combinations until > you find the first one that works and use that one. (These are extremes, > something in the middle is also possible.) This reachability testing > MUST happen in the multi6 layer for robustness and security reasons. > > The question that we've been talking about is when this reachability > testing should happen. I don't think sending keepalives all the time or > when idle is a good idea here. For multihoming purposes, it's enough to > do reachability tests when the traffic patterns indiciate a _possible_ > loss of connectivity. This would be when there is only traffic in one > direction. > > Now if applications or transports feel they need to notice immediately > when connectivity goes away, they can always send keepalives when the > session is otherwise idle. It doesn't make sense to subcontract this job > to the multihoming layer for two reasons: > > 1. There may not be any multihoming so no keepalives happen > 2. The added complexity of interfacing between layers > >> At the same time, how does the multi6 layer understand what kind of >> connectivity the application needs? With wireless links, its really >> easy to get intermittent connectivity. How do we classify when the >> connectivity is too poor to be useful - the application should be able >> to determine this and ask for using a different address pair. > > > This is an unsolved problem. I think at some point we need an interface > for this, so that multi6-aware applications can influence certain > aspects of multihoming operation. I've always assumed that once basic > multihoming is in the can the next step would be to make TCP > multihoming-aware so that it can load balance over more than one address > pair at a time in order to achieve x+y throughput rather than max(x,y) > throughput, or worse min(x,y)+abs(rand()+0.5)*(max(x,y)-min(x,y)) (ok > this means either x or y at random) throughput. IMO, this is a very bad idea, despite its prevalence in certain communities. If this is where you're going, you need TCP to know the AGGREGATE of its window, and behave accordingly, but as to load-balancing, that's building IP into TCP, and assumes that address pairs are meaningful in this context (if there are 8 pairs on each end, are there 8 end-to-end pairs, or 64? - there could be 64 unique routes, depending on what IP does). If you want to make a set of links look like one link, build a tunnel with a loadbalancing demux in it, but don't go to TCP for that functionality, IMO. We looked into it several times before (webmux, in particular), and it ends up creating substantial problems with priority inversion, layered multiplexing, etc. Joe --------------enig8E318A6702C72AA04D49BDD4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBnBwdE5f5cImnZrsRArs3AKCVf8QbH/zkpXbPW/I+9DXrdU+WCQCaAniJ EzYtP5l+rESLyyp8yHpUcC0= =aqZR -----END PGP SIGNATURE----- --------------enig8E318A6702C72AA04D49BDD4-- From owner-multi6@ops.ietf.org Thu Nov 18 11:22:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07987 for ; Thu, 18 Nov 2004 11:22:17 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUp2v-0002z9-D2 for multi6-data@psg.com; Thu, 18 Nov 2004 16:22:09 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUp2t-0002ys-HH for multi6@ops.ietf.org; Thu, 18 Nov 2004 16:22:08 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAIGLuSZ243336; Thu, 18 Nov 2004 16:21:56 GMT Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAIGLuuf194248; Thu, 18 Nov 2004 16:21:56 GMT Received: from zurich.ibm.com (sig-9-145-249-72.de.ibm.com [9.145.249.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA08766; Thu, 18 Nov 2004 17:21:53 +0100 Message-ID: <419CCC20.9080500@zurich.ibm.com> Date: Thu, 18 Nov 2004 17:21:52 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Soliman, Hesham" CC: Francis Dupont , Iljitsch van Beijnum , jari.arkko@piuha.net, multi6@ops.ietf.org Subject: Re: IPR (Was: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Can we leave this topic until this or some other WG faces the question of formally putting HBA on the standards track? Brian Soliman, Hesham wrote: > > In your previous mail you wrote: > > > > On 15-nov-04, at 16:50, Jari Arkko wrote: > > > > >> PS: BTW CGA IPR holders provide royalty-free licenses > > only for SEND, > > >> can they update their IPR texts on the IETF web for HBAs too? > > > > > FYI: I have asked the Ericsson IPR department to inform the > > > IETF about their licensing conditions regarding the HBA draft > > > and usage in MULTI6. > > > > Shouldn't we try to determine whether the patent even > > applies in the > > first place? > > > > => as the HBA idea is an extension of the CGA one, I can't > > see how the > > patent can apply to CGA but not to HBA... No, the problem is real, > > but it should very easy to fix with a better wording in the IPR note. > > > > => I think Microsoft also made claims about CGA, so I'm not > sure if the Ericsson IPR statement alone will be sufficient. > > Hesham > > =========================================================== > This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > =========================================================== > > > From owner-multi6@ops.ietf.org Thu Nov 18 11:57:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11321 for ; Thu, 18 Nov 2004 11:57:29 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUpaL-0007L4-DJ for multi6-data@psg.com; Thu, 18 Nov 2004 16:56:41 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUpaK-0007Kn-0T for multi6@ops.ietf.org; Thu, 18 Nov 2004 16:56:40 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAIGugQx069395; Thu, 18 Nov 2004 17:56:42 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <419C1C1D.4030708@isi.edu> References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <84DE7930-3487-11D9-9D6A-000A95CD987A@muada.com> <419C1C1D.4030708@isi.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org' List" From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Thu, 18 Nov 2004 17:56:26 +0100 To: Joe Touch X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 18-nov-04, at 4:50, Joe Touch wrote: >>> How do we classify when the >>> connectivity is too poor to be useful - the application should be >>> able >>> to determine this and ask for using a different address pair. >> This is an unsolved problem. I think at some point we need an >> interface for this, so that multi6-aware applications can influence >> certain aspects of multihoming operation. I'm assuming you're not disagreeing with this part? >> I've always assumed that once basic multihoming is in the can the >> next step would be to make TCP multihoming-aware so that it can load >> balance over more than one address pair at a time in order to achieve >> x+y throughput rather than max(x,y) throughput, or worse > IMO, this is a very bad idea, despite its prevalence in certain > communities. If this is where you're going, you need TCP to know the > AGGREGATE of its window, and behave accordingly, but as to > load-balancing, that's building IP into TCP, and assumes that address > pairs are meaningful in this context I don't see the problem...? > (if there are 8 pairs on each end, are there 8 end-to-end pairs, or > 64? - there could be 64 unique routes, depending on what IP does). Obviously a pair can't be on one end. If one host has 4 addresses and the other 3, then there are 12 pairs. Communication can happen over one pair in both directions (12 possibilities) or different pairs in different directions (132 possibilities) for a total of 144 different ways to communicate between these hosts. > If you want to make a set of links look like one link, build a tunnel > with a loadbalancing demux in it, but don't go to TCP for that > functionality, IMO. So you propose an additional layer of functionality that massages the different properties of the different links such that TCP's assumptions about the link it runs over (reasonably stable RTT, packet loss = congestion) work? This is exactly how we always get into trouble: add protocols that break the assumptions of previous protocols. It would be much better to change TCP so it has all the information and can make the right decisions. Basically this would be like running several TCP sessions in parallel, except that we have to ensure in-order delivery. Unless this aspect turns out unexpectedly difficult, I see no problems. > We looked into it several times before (webmux, in particular), and it > ends up creating substantial problems with priority inversion, layered > multiplexing, etc. Do you have links to stuff I can look at in this area? From owner-multi6@ops.ietf.org Thu Nov 18 12:15:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13009 for ; Thu, 18 Nov 2004 12:15:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUpri-0009oH-Gp for multi6-data@psg.com; Thu, 18 Nov 2004 17:14:38 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUprf-0009nz-J5 for multi6@ops.ietf.org; Thu, 18 Nov 2004 17:14:35 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAIHEnQx069679; Thu, 18 Nov 2004 18:14:49 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20041117204224.37676.qmail@web80605.mail.yahoo.com> References: <20041117204224.37676.qmail@web80605.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <500477EC-3985-11D9-BFE4-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org' List" From: Iljitsch van Beijnum Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Thu, 18 Nov 2004 18:14:32 +0100 To: Mohan Parthasarathy X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 17-nov-04, at 21:42, Mohan Parthasarathy wrote: >> What do you see as the benefit of having the same >> iid for all prefixes? > None :-) I was only trying to find out the reason > as to why this can't be done or easily supported > without changing the format. There are two reasons it is good to have the same IID for different prefixes: 1. At some point in the future, we may want to have routers rewrite the prefix part in the source addresses of outgoing packets. This is a very good way to deal with ingress filtering. However, it is unlikely that routers could hold all the state necessary to match individual addresses rather than prefixes. (Note that we are NOT proposing router rewriting at this point.) 2. Easier debugging. The reason you can't have the same IID in different prefixes for CGA is that in CGA the prefix is part of the data the hash is computed over. The reason the prefix is included is because otherwise someone could precompute all possible hashes. It would be possible to include one chosen prefix rather than the "real" prefix, though. This way out of N addresses there would be one that is SEND-compatible and N-1 that aren't. The SEND-compatible address could be the ULID. Not having SEND for additional locators wouldn't be too much of a hardship, IMO. From owner-multi6@ops.ietf.org Thu Nov 18 12:18:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13244 for ; Thu, 18 Nov 2004 12:18:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUpvR-000ABK-Er for multi6-data@psg.com; Thu, 18 Nov 2004 17:18:29 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUpvO-000AAu-Qv for multi6@ops.ietf.org; Thu, 18 Nov 2004 17:18:27 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAIHIEJ03175; Thu, 18 Nov 2004 18:18:14 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id iAIHIESj032264; Thu, 18 Nov 2004 18:18:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411181718.iAIHIESj032264@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Soliman, Hesham" cc: "Iljitsch van Beijnum" , jari.arkko@piuha.net, multi6@ops.ietf.org Subject: Re: IPR (Was: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt) In-reply-to: Your message of Thu, 18 Nov 2004 11:13:17 EST. Date: Thu, 18 Nov 2004 18:18:14 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => as the HBA idea is an extension of the CGA one, I can't > see how the > patent can apply to CGA but not to HBA... No, the problem is real, > but it should very easy to fix with a better wording in the IPR note. > => I think Microsoft also made claims about CGA, so I'm not sure if the Ericsson IPR statement alone will be sufficient. => Microsoft IPR uses the standard form and the b clause is checked for both royalty free, ... and limitation to standard track documents so IMHO it is less critical. Thanks Francis.Dupont@enst-bretagne.fr From owner-multi6@ops.ietf.org Thu Nov 18 14:32:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24479 for ; Thu, 18 Nov 2004 14:32:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUs00-000PeB-9t for multi6-data@psg.com; Thu, 18 Nov 2004 19:31:20 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUrzw-000Pdr-6r for multi6@ops.ietf.org; Thu, 18 Nov 2004 19:31:16 +0000 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAIJUwt10573; Thu, 18 Nov 2004 11:30:58 -0800 (PST) Message-ID: <419CF87A.3040907@isi.edu> Date: Thu, 18 Nov 2004 11:31:06 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <41937388.8070705@isi.edu> <781D52E9-3489-11D9-9D6A-000A95CD987A@muada.com> <4194D40D.9050309@isi.edu> <4196D120.1090705@isi.edu> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: | On 14-nov-04, at 4:29, Joe Touch wrote: | |>> But how do you know a session is completely idle vs there is still a |>> delayed ack coming? (Without looking too deep into TCP, that is.) | |> Delayed ACKs come within 200ms of the other end going idle, AFAIR. | | Ok. But then we have to account for normal packet loss and normal RTT | variations. Agreed, |>> (Note that is makes little difference whether you use persistent |>> connections: we work at the IP layer.) | | |> Persistent connections are the kind of TCP connections that might go |> idle for extended periods; | | | Actually I believe they are closed after a relatively short time when | they aren't used. And very few sessions use persistent connections last | time I checked. TCP connections are not closed just because they are idle, and idle means no packets exchanged at all. |> most other TCP connections tend to either be sending data or be closed |> quickly. | | | A better example of sessions that remain open long even if they're idle | are SSH sessions. | |>> The trick is detecting legitimate idleness because in that state no |>> action is necessary. For TCP this shouldn't be too hard, for other |>> protocols we have to find good timeout values. I think these need to |>> be higher than just a few RTTs. | | |> Such as? I was thinking 300ms-500ms as a ballpark. | | | I was thinking along the lines of 10 - 15 seconds for non-TCP stuff. I | heaven't really looked in detail, but I'm pretty sure transports for AV | streaming don't generate ACKs every 500 ms. Anything that doesn't generate ACKs every couple-hundred ms when the stream is active is asking for trouble ;-) | Alternatively, this could be made to auto-tune. Sure. | Note though that if you select value X for this and ACKs are sent every | 1.1*X interval, you'll be sending test packets every X. With a larger X | this is less likely to happen, but also results in less unnecessary | traffic if it does. | |>> Hm, my assumption was that after a successful test, there wouldn't be |>> any more tests until something changes. | | |> That presumes async notification from the lower layer. I wasn't, since |> I don't believe that's feasible. | | |> I.e., I would expect: |> - seeing packets exchanged is an in-band test that can be |> observed and serves as a keep-alive itself |> - send keepalives for the first 500ms after idle |> - stop sending keepalives after that | | | I think we're in agreement exept for the interval and the fact that you | use plural while I'd think a single successful exchange would be | enough. :-) Yes. |>> Since we don't do anything when the session is active in both |>> directions or completely idle, reachability tests only happen after a |>> suspicious active->idle transition. After the test, the multihoming |>> layer would be satisfied that this transition wasn't because of a |>> failure, and wouldn't have to do anything until there is a new |>> active->idle transition. | | |> I'd like it to do something - to keep verifying that reachability is |> still possible for exactly the period that an idle TCP 'expects' there |> not to be a substantial change in the channel. | | Wouldn't an outage happening right after a session goes idle and a | keepalive has been exchanged be such a corner case that we can safely | ignore it as a special case? I don't like ignoring corner cases, esp. where TCP is concerned. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBnPh6E5f5cImnZrsRAstRAJ9apCJHgtI8X4W9gpEPWkHYqJkZjgCg/ku6 NNLvA6qxNltFyt9sMYA2W54= =ybHa -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 18 14:50:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26200 for ; Thu, 18 Nov 2004 14:50:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUsIN-0001vm-FY for multi6-data@psg.com; Thu, 18 Nov 2004 19:50:19 +0000 Received: from [128.9.160.161] (helo=boreas.isi.edu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUsIM-0001vL-6X for multi6@ops.ietf.org; Thu, 18 Nov 2004 19:50:18 +0000 Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAIJn6t16315; Thu, 18 Nov 2004 11:49:06 -0800 (PST) Message-ID: <419CFCBA.4040001@isi.edu> Date: Thu, 18 Nov 2004 11:49:14 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <84DE7930-3487-11D9-9D6A-000A95CD987A@muada.com> <419C1C1D.4030708@isi.edu> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Iljitsch van Beijnum wrote: | On 18-nov-04, at 4:50, Joe Touch wrote: | |>>> How do we classify when the |>>> connectivity is too poor to be useful - the application should be able |>>> to determine this and ask for using a different address pair. | | |>> This is an unsolved problem. I think at some point we need an |>> interface for this, so that multi6-aware applications can influence |>> certain aspects of multihoming operation. | | I'm assuming you're not disagreeing with this part? Yes. |>> I've always assumed that once basic multihoming is in the can the |>> next step would be to make TCP multihoming-aware so that it can load |>> balance over more than one address pair at a time in order to achieve |>> x+y throughput rather than max(x,y) throughput, or worse | | |> IMO, this is a very bad idea, despite its prevalence in certain |> communities. If this is where you're going, you need TCP to know the |> AGGREGATE of its window, and behave accordingly, but as to |> load-balancing, that's building IP into TCP, and assumes that address |> pairs are meaningful in this context | | I don't see the problem...? | |> (if there are 8 pairs on each end, are there 8 end-to-end pairs, or |> 64? - there could be 64 unique routes, depending on what IP does). | | Obviously a pair can't be on one end. (sorry - I meant 'addresses on each end') | If one host has 4 addresses and | the other 3, then there are 12 pairs. Communication can happen over one | pair in both directions (12 possibilities) or different pairs in | different directions (132 possibilities) for a total of 144 different | ways to communicate between these hosts. | |> If you want to make a set of links look like one link, build a tunnel |> with a loadbalancing demux in it, but don't go to TCP for that |> functionality, IMO. | | | So you propose an additional layer of functionality that massages the | different properties of the different links such that TCP's assumptions | about the link it runs over (reasonably stable RTT, packet loss = | congestion) work? No; I'm asserting that the additional functionality is going to be needed, and we shouldn't step into that mess, since it has already been stepped in before in the IETF. | This is exactly how we always get into trouble: add | protocols that break the assumptions of previous protocols. It would be | much better to change TCP so it has all the information and can make the | right decisions. Er, well, that would argue that TCP should do the multihoming too, not a shim layer. We already discussed why _that_ isn't the case. For similar reasons, this is true here too. TCP is _NOT_ the muxing layer. IP is. | Basically this would be like running several TCP | sessions in parallel, except that we have to ensure in-order delivery. | Unless this aspect turns out unexpectedly difficult, I see no problems. | |> We looked into it several times before (webmux, in particular), and it |> ends up creating substantial problems with priority inversion, layered |> multiplexing, etc. | | Do you have links to stuff I can look at in this area? Check the IETF proceedings for webmux, HTTP-NG, and SOAP. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBnPy6E5f5cImnZrsRAtDpAKCGrKGKCZL9DnsctUGjt9cr0y92KwCgto/G Tgg4DhTIbsDF3FwMBdstEXI= =hJMa -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Nov 18 19:47:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10947 for ; Thu, 18 Nov 2004 19:47:53 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CUwv3-000CBo-NL for multi6-data@psg.com; Fri, 19 Nov 2004 00:46:33 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CUwv2-000CAd-N8 for multi6@ops.ietf.org; Fri, 19 Nov 2004 00:46:32 +0000 Received: from jurassic.eng.sun.com ([129.146.83.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iAJ0kTVu013821; Thu, 18 Nov 2004 17:46:30 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAJ0kSkm452921; Thu, 18 Nov 2004 16:46:28 -0800 (PST) Message-ID: <419D429A.3060703@sun.com> Date: Thu, 18 Nov 2004 16:47:22 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Mohan Parthasarathy , "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <20041117204224.37676.qmail@web80605.mail.yahoo.com> <500477EC-3985-11D9-BFE4-000A95CD987A@muada.com> In-Reply-To: <500477EC-3985-11D9-BFE4-000A95CD987A@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > There are two reasons it is good to have the same IID for different > prefixes: > > 1. At some point in the future, we may want to have routers rewrite the > prefix part in the source addresses of outgoing packets. This is a very > good way to deal with ingress filtering. However, it is unlikely that > routers could hold all the state necessary to match individual addresses > rather than prefixes. (Note that we are NOT proposing router rewriting > at this point.) It's far from clear to me that, should we pursue router rewriting in the future, that it can operate without being aware of individual hosts addresses. The issue is coordination with what the hosts thinks are their locator, and what host addresses the hosts can "prove" the the peers is their own. For instance, if you have a site with 7 prefixes but some small devices only choose to use 3 of them, and form HBA addresses using those 3, then if the routers rewrite the source locator to any of the other 4 prefixes then it might result in a complete failure to communicate since the peer might ignore the "spoofed" packet coming from an invalid source locator of the host. Likewise during graceful renumbering; when a site with multiple prefixes adds or changes a prefix, when can the router start rewriting to the new prefix (and must stop rewriting to the old prefix, which might happen at a different time). If a router doing rewriting maintains per-host state, for instance using the same multi6 protocol as is used e2e, then it can stay in synch with the prefixes/locators that the host is actually using. Erik From owner-multi6@ops.ietf.org Fri Nov 19 04:27:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08894 for ; Fri, 19 Nov 2004 04:27:56 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CV510-0001hb-Qn for multi6-data@psg.com; Fri, 19 Nov 2004 09:25:14 +0000 Received: from [195.212.29.136] (helo=mtagate3.uk.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CV50z-0001g9-7k for multi6@ops.ietf.org; Fri, 19 Nov 2004 09:25:13 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAJ9P75M212980 for ; Fri, 19 Nov 2004 09:25:07 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAJ9P92M065754 for ; Fri, 19 Nov 2004 09:25:10 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iAJ9P6YE031966 for ; Fri, 19 Nov 2004 09:25:06 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iAJ9P6n7031948; Fri, 19 Nov 2004 09:25:06 GMT Received: from zurich.ibm.com (sig-9-146-219-232.de.ibm.com [9.146.219.232]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA73190; Fri, 19 Nov 2004 10:25:03 +0100 Message-ID: <419DBBEF.1090809@zurich.ibm.com> Date: Fri, 19 Nov 2004 10:25:03 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: Iljitsch van Beijnum , Mohan Parthasarathy , "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <20041117204224.37676.qmail@web80605.mail.yahoo.com> <500477EC-3985-11D9-BFE4-000A95CD987A@muada.com> <419D429A.3060703@sun.com> In-Reply-To: <419D429A.3060703@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > Iljitsch van Beijnum wrote: > >> There are two reasons it is good to have the same IID for different >> prefixes: >> >> 1. At some point in the future, we may want to have routers rewrite >> the prefix part in the source addresses of outgoing packets. This is a >> very good way to deal with ingress filtering. However, it is unlikely >> that routers could hold all the state necessary to match individual >> addresses rather than prefixes. (Note that we are NOT proposing router >> rewriting at this point.) > > > It's far from clear to me that, should we pursue router rewriting in the > future, that it can operate without being aware of individual hosts > addresses. I agree. It also seems to me that requiring the same IID for all interfaces is architecturally wrong, and will cause significant difficulty anyway, for example in virtualized server networks where there is no fixed linkage between a host's identity and the machine or physical interface it happens to be assigned to at the moment. Brian > > The issue is coordination with what the hosts thinks are their locator, > and what host addresses the hosts can "prove" the the peers is their own. > > For instance, if you have a site with 7 prefixes but some small devices > only choose to use 3 of them, and form HBA addresses using those 3, then > if the routers rewrite the source locator to any of the other 4 prefixes > then it might result in a complete failure to communicate since the peer > might ignore the "spoofed" packet coming from an invalid source locator > of the host. > > Likewise during graceful renumbering; when a site with multiple prefixes > adds or changes a prefix, when can the router start rewriting to the new > prefix (and must stop rewriting to the old prefix, which might happen at > a different time). > > If a router doing rewriting maintains per-host state, for instance using > the same multi6 protocol as is used e2e, then it can stay in synch with > the prefixes/locators that the host is actually using. > > Erik > From owner-multi6@ops.ietf.org Fri Nov 19 04:28:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08951 for ; Fri, 19 Nov 2004 04:28:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CV53u-0001vh-Vh for multi6-data@psg.com; Fri, 19 Nov 2004 09:28:14 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CV53s-0001uf-3h for multi6@ops.ietf.org; Fri, 19 Nov 2004 09:28:12 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id iAJ9Rqug180482; Fri, 19 Nov 2004 09:27:52 GMT Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAJ9RnU8089594; Fri, 19 Nov 2004 10:27:50 +0100 Received: from zurich.ibm.com (sig-9-146-219-232.de.ibm.com [9.146.219.232]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA24198; Fri, 19 Nov 2004 10:27:50 +0100 Message-ID: <419DBC96.3000508@zurich.ibm.com> Date: Fri, 19 Nov 2004 10:27:50 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Joe Touch CC: Iljitsch van Beijnum , "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <84DE7930-3487-11D9-9D6A-000A95CD987A@muada.com> <419C1C1D.4030708@isi.edu> <419CFCBA.4040001@isi.edu> In-Reply-To: <419CFCBA.4040001@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm fairly close to declaring this conversation out of scope. Maybe you can come back to the list when you have reached a mutual consensus? Brian with co-chair hat Joe Touch wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Iljitsch van Beijnum wrote: > | On 18-nov-04, at 4:50, Joe Touch wrote: > | > |>>> How do we classify when the > |>>> connectivity is too poor to be useful - the application should be able > |>>> to determine this and ask for using a different address pair. > | > | > |>> This is an unsolved problem. I think at some point we need an > |>> interface for this, so that multi6-aware applications can influence > |>> certain aspects of multihoming operation. > | > | I'm assuming you're not disagreeing with this part? > > Yes. > > |>> I've always assumed that once basic multihoming is in the can the > |>> next step would be to make TCP multihoming-aware so that it can load > |>> balance over more than one address pair at a time in order to achieve > |>> x+y throughput rather than max(x,y) throughput, or worse > | > | > |> IMO, this is a very bad idea, despite its prevalence in certain > |> communities. If this is where you're going, you need TCP to know the > |> AGGREGATE of its window, and behave accordingly, but as to > |> load-balancing, that's building IP into TCP, and assumes that address > |> pairs are meaningful in this context > | > | I don't see the problem...? > | > |> (if there are 8 pairs on each end, are there 8 end-to-end pairs, or > |> 64? - there could be 64 unique routes, depending on what IP does). > | > | Obviously a pair can't be on one end. > > (sorry - I meant 'addresses on each end') > > | If one host has 4 addresses and > | the other 3, then there are 12 pairs. Communication can happen over one > | pair in both directions (12 possibilities) or different pairs in > | different directions (132 possibilities) for a total of 144 different > | ways to communicate between these hosts. > | > |> If you want to make a set of links look like one link, build a tunnel > |> with a loadbalancing demux in it, but don't go to TCP for that > |> functionality, IMO. > | > | > | So you propose an additional layer of functionality that massages the > | different properties of the different links such that TCP's assumptions > | about the link it runs over (reasonably stable RTT, packet loss = > | congestion) work? > > No; I'm asserting that the additional functionality is going to be > needed, and we shouldn't step into that mess, since it has already been > stepped in before in the IETF. > > | This is exactly how we always get into trouble: add > | protocols that break the assumptions of previous protocols. It would be > | much better to change TCP so it has all the information and can make the > | right decisions. > > Er, well, that would argue that TCP should do the multihoming too, not a > shim layer. We already discussed why _that_ isn't the case. For similar > reasons, this is true here too. TCP is _NOT_ the muxing layer. IP is. > > | Basically this would be like running several TCP > | sessions in parallel, except that we have to ensure in-order delivery. > | Unless this aspect turns out unexpectedly difficult, I see no problems. > | > |> We looked into it several times before (webmux, in particular), and it > |> ends up creating substantial problems with priority inversion, layered > |> multiplexing, etc. > | > | Do you have links to stuff I can look at in this area? > > Check the IETF proceedings for webmux, HTTP-NG, and SOAP. > > Joe > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (MingW32) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFBnPy6E5f5cImnZrsRAtDpAKCGrKGKCZL9DnsctUGjt9cr0y92KwCgto/G > Tgg4DhTIbsDF3FwMBdstEXI= > =hJMa > -----END PGP SIGNATURE----- > From owner-multi6@ops.ietf.org Fri Nov 19 05:43:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14537 for ; Fri, 19 Nov 2004 05:42:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CV6DG-000BQU-GF for multi6-data@psg.com; Fri, 19 Nov 2004 10:41:58 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CV6DF-000BQ2-0p for multi6@ops.ietf.org; Fri, 19 Nov 2004 10:41:57 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAJAg8Qx081626; Fri, 19 Nov 2004 11:42:09 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <419CF87A.3040907@isi.edu> References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <41937388.8070705@isi.edu> <781D52E9-3489-11D9-9D6A-000A95CD987A@muada.com> <4194D40D.9050309@isi.edu> <4196D120.1090705@isi.edu> <419CF87A.3040907@isi.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org' List" From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Fri, 19 Nov 2004 11:41:52 +0100 To: Joe Touch X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 18-nov-04, at 20:31, Joe Touch wrote: > |> Persistent connections are the kind of TCP connections that might go > |> idle for extended periods; > | Actually I believe they are closed after a relatively short time when > | they aren't used. And very few sessions use persistent connections > last > | time I checked. > TCP connections are not closed just because they are idle, and idle > means no packets exchanged at all. I was talking about HTTP connections, not about TCP in general. > |> Such as? I was thinking 300ms-500ms as a ballpark. > | I was thinking along the lines of 10 - 15 seconds for non-TCP stuff. > I > | heaven't really looked in detail, but I'm pretty sure transports for > AV > | streaming don't generate ACKs every 500 ms. > Anything that doesn't generate ACKs every couple-hundred ms when the > stream is active is asking for trouble ;-) Any particular reason why? I think so many ACKs are excessive. > |> I'd like it to do something - to keep verifying that reachability is > |> still possible for exactly the period that an idle TCP 'expects' > there > |> not to be a substantial change in the channel. > | Wouldn't an outage happening right after a session goes idle and a > | keepalive has been exchanged be such a corner case that we can safely > | ignore it as a special case? > I don't like ignoring corner cases, esp. where TCP is concerned. There is ignoring and then there is ignoring. Obviously when such a corner case happens our mechanisms must be able to deal with it in a reasonably way. What I'm saying is that not having code to specifically handle this case and thus potentially incurring a retransmit before the multihoming layer does its thing is ok here. Don't forget that outages are relatively rare. I don't find the situation where there is a significant hiccup when one happens problematic, as long as such a hiccup is short enough for sessions to recover and for users to wait for this. (I.e., recovering after 239 wouldn't do, but after 5 - 10 seconds would be just fine.) From owner-multi6@ops.ietf.org Fri Nov 19 05:52:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15442 for ; Fri, 19 Nov 2004 05:52:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CV6NA-000DYO-98 for multi6-data@psg.com; Fri, 19 Nov 2004 10:52:12 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CV6N7-000DWd-Al for multi6@ops.ietf.org; Fri, 19 Nov 2004 10:52:09 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAJAqLQx081762; Fri, 19 Nov 2004 11:52:22 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <419CFCBA.4040001@isi.edu> References: <3CF661B1787ABF41A869BE20108F8D6D095866@esebe056.ntc.nokia.com> <84DE7930-3487-11D9-9D6A-000A95CD987A@muada.com> <419C1C1D.4030708@isi.edu> <419CFCBA.4040001@isi.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0DB45070-3A19-11D9-992B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org' List" From: Iljitsch van Beijnum Subject: Re: Comments on draft-ietf-multi6-v4-multihoming-02 Date: Fri, 19 Nov 2004 11:52:06 +0100 To: Joe Touch X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 18-nov-04, at 20:49, Joe Touch wrote: > | This is exactly how we always get into trouble: add > | protocols that break the assumptions of previous protocols. It would > be > | much better to change TCP so it has all the information and can make > the > | right decisions. > Er, well, that would argue that TCP should do the multihoming too, not > a > shim layer. We already discussed why _that_ isn't the case. For similar > reasons, this is true here too. I disagree that these cases are similar enough that the tradeoffs for one can be applied to the other. > | TCP is _NOT_ the muxing layer. IP is. If memory serves me, port numbers happen in TCP and UDP, not IP... (Which is a mistake anyway, IMNSHO.) But anyway, we have a lot of other bridges to jump off before we reach this one, so we can hash this out at some point in the future in the then appropriate forum. > Check the IETF proceedings for webmux, HTTP-NG, and SOAP. I will, thanks. From owner-multi6@ops.ietf.org Fri Nov 19 06:00:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16048 for ; Fri, 19 Nov 2004 06:00:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CV6V6-000F4o-RK for multi6-data@psg.com; Fri, 19 Nov 2004 11:00:24 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CV6V5-000F4P-Tr for multi6@ops.ietf.org; Fri, 19 Nov 2004 11:00:24 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAJB0bQx081856; Fri, 19 Nov 2004 12:00:38 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <419D429A.3060703@sun.com> References: <20041117204224.37676.qmail@web80605.mail.yahoo.com> <500477EC-3985-11D9-BFE4-000A95CD987A@muada.com> <419D429A.3060703@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <357E2B5E-3A1A-11D9-992B-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "'multi6@ops.ietf.org' List" From: Iljitsch van Beijnum Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Fri, 19 Nov 2004 12:00:22 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 19-nov-04, at 1:47, Erik Nordmark wrote: > It's far from clear to me that, should we pursue router rewriting in > the future, that it can operate without being aware of individual > hosts addresses. Maybe not, but there is also the possibility that it could work per-prefix but not per-host. > For instance, if you have a site with 7 prefixes but some small > devices only choose to use 3 of them, and form HBA addresses using > those 3, then if the routers rewrite the source locator to any of the > other 4 prefixes then it might result in a complete failure to > communicate since the peer might ignore the "spoofed" packet coming > from an invalid source locator of the host. I think it's possible to solve this. We've been talking about a bit that indicates (among other things) that rewriting is allowed. For a long time, I've been saying that we could use the prefix in the source address for this. So magic prefix = rewrite, regular prefix = don't rewrite. We can reserve some bits in the magic prefix that indicate the type of rewriting that's allowed. For instance, if the prefix is then we can encode permission to rewrite to one or more of 16 different prefixes. There is the slight problem of having all systems involved know which prefix corresponds to which bit of course, but this should be doable. On 19-nov-04, at 10:25, Brian E Carpenter wrote: > It also seems to me that requiring the same IID for all interfaces is > architecturally wrong, I certainly wouldn't want to require this, just allow it. From owner-multi6@ops.ietf.org Fri Nov 19 06:22:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17843 for ; Fri, 19 Nov 2004 06:22:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CV6q9-000I67-FL for multi6-data@psg.com; Fri, 19 Nov 2004 11:22:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CV6q8-000I5b-7l for multi6@ops.ietf.org; Fri, 19 Nov 2004 11:22:08 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAJBM6v12886; Fri, 19 Nov 2004 13:22:06 +0200 Date: Fri, 19 Nov 2004 13:22:06 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents In-Reply-To: <4193C479.1090702@sun.com> Message-ID: References: <419112EC.3010706@sun.com> <41923BED.9040509@sun.com> <4193C479.1090702@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Following up on an old message, sorry... On Thu, 11 Nov 2004, Erik Nordmark wrote: >> Agreed. I wasn't sure of the context, just that IP+EXT+whatever might not >> do it. Destination options however provide the facilities today for >> skipping over them without making assumptions; this might not in practice >> be any better though. > > If a firewall is built on the philosophy to be conservative it will not > let anything new through, whether it is a new payload type, a new > option, or whatever. True .. but firewalls of today don't even have a _chance_ of skipping over the extension header, even if they, or their administrators would want that (well, if the extension header is in TLV format, maybe then, because some firewalls assume the next ext headers are in TLV). Destination options at least allow that possibility. >> So, the demux code needs to deal with ICMPv6 address translation. What >> about other protocols? Do we want to care for the others which might be >> doing similar things, or we just say 'just do the referral thing'? > > What other protocols do you have in mind? [...] Right out, I can't think of anything else than ICMP and multicast (which you already mentioned), but that doesn't of course mean those kind of protocols might not exist. Therefore I think it would make sense to put this sufficiently clearly in the document that people need to keep in mind that there may be some protocols which might call for special handling. >> The fact this is an ALG in a sense should possibly be stated, with the >> caveat that we're assuming that there aren't other equally "fundamental" >> protocols where you shouldn't be required deal with the full referral >> process. > > Why do you wish to confuse things by calling it an ALG? It is a local matter > for the implementation how it demuxes ICMP errors. ALGs and NATs make people > think of middleboxes which perform transformations which can not be reversed. Sorry, I was just trying to figure out a term which says, "requires the host's shim layer and possibly some weirder middleboxes (like stateful firewalls, when they want to figure whether to pass this error in or not) have knowledge of applications' semantics [and if there are new such applications, requiring that this application knowledge to be updated], to be able to mangle the addresses inside the payload correctly." -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Fri Nov 19 13:43:20 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00706 for ; Fri, 19 Nov 2004 13:43:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CVDhU-000CMl-Mu for multi6-data@psg.com; Fri, 19 Nov 2004 18:41:40 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CVDhT-000CMU-PW for multi6@ops.ietf.org; Fri, 19 Nov 2004 18:41:39 +0000 Received: from jurassic.eng.sun.com ([129.146.89.31]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAJIfapv005489; Fri, 19 Nov 2004 10:41:36 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAJIfaAW415469; Fri, 19 Nov 2004 10:41:36 -0800 (PST) Message-ID: <419E3E94.8090002@sun.com> Date: Fri, 19 Nov 2004 10:42:28 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <20041117204224.37676.qmail@web80605.mail.yahoo.com> <500477EC-3985-11D9-BFE4-000A95CD987A@muada.com> <419D429A.3060703@sun.com> <357E2B5E-3A1A-11D9-992B-000A95CD987A@muada.com> In-Reply-To: <357E2B5E-3A1A-11D9-992B-000A95CD987A@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > I think it's possible to solve this. We've been talking about a bit that > indicates (among other things) that rewriting is allowed. For a long > time, I've been saying that we could use the prefix in the source > address for this. So magic prefix = rewrite, regular prefix = don't > rewrite. We can reserve some bits in the magic prefix that indicate the > type of rewriting that's allowed. For instance, if the prefix is > then we can encode permission to > rewrite to one or more of 16 different prefixes. There is the slight > problem of having all systems involved know which prefix corresponds to > which bit of course, but this should be doable. Such an approach would require there to be a source locator rewriting router in the path, right? If the above funny prefix isn't rewritten in the path the peer will not be able to respond AFAIK. Since we want to allow incremental deployment of any multi6 technology, such an approach would require that the host can find out 1) whether there is a source locator rewriter out there 2) whether the source locator rewriter is in the path to reach a particular destination (for instance, the path to a destinations within the site may or may not go through a rewriter) If the host needs to probe the network per destination locator to answer #2, we might as well have the answer tell the host which is the preferred source locator to use so that there is no actual rewriting along the path. (Yes, there are some subtle differences should the path change.) The above complexity combined with Geoff's observations that in real networks today it is hard to define which is the "site border router" which would do the rewriting, makes me personally think that locator rewriting along the path might not be worth to complexity even in the future. Erik From owner-multi6@ops.ietf.org Fri Nov 19 13:51:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01435 for ; Fri, 19 Nov 2004 13:51:58 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CVDrD-000ECd-Me for multi6-data@psg.com; Fri, 19 Nov 2004 18:51:43 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CVDrC-000ECG-Pa for multi6@ops.ietf.org; Fri, 19 Nov 2004 18:51:42 +0000 Received: from jurassic.eng.sun.com ([129.146.87.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAJIpYun007805; Fri, 19 Nov 2004 11:51:40 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAJIpYQl424023; Fri, 19 Nov 2004 10:51:34 -0800 (PST) Message-ID: <419E40EB.2000707@sun.com> Date: Fri, 19 Nov 2004 10:52:27 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents References: <419112EC.3010706@sun.com> <41923BED.9040509@sun.com> <4193C479.1090702@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > True .. but firewalls of today don't even have a _chance_ of skipping > over the extension header, even if they, or their administrators would > want that (well, if the extension header is in TLV format, maybe then, > because some firewalls assume the next ext headers are in TLV). > Destination options at least allow that possibility. If any future extension headers follow the canonical format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ then one can build firewalls that are liberal in what they accept. But I still think this is moot because firewalls by nature will be conservative in what they accept. > Right out, I can't think of anything else than ICMP and multicast (which > you already mentioned), but that doesn't of course mean those kind of > protocols might not exist. Therefore I think it would make sense to put > this sufficiently clearly in the document that people need to keep in > mind that there may be some protocols which might call for special > handling. ok, I'll add some words. >> Why do you wish to confuse things by calling it an ALG? It is a local >> matter for the implementation how it demuxes ICMP errors. ALGs and >> NATs make people think of middleboxes which perform transformations >> which can not be reversed. > > > Sorry, I was just trying to figure out a term which says, "requires the > host's shim layer and possibly some weirder middleboxes (like stateful > firewalls, when they want to figure whether to pass this error in or > not) have knowledge of applications' semantics [and if there are new > such applications, requiring that this application knowledge to be > updated], to be able to mangle the addresses inside the payload correctly." It isn't "applications" - it is what I'd call "IP signaling protocols" or something like it; protocols which are not end-to-end but involve the routers along the path. ICMP errors from the routers, or RSVP signaling is what we currently have as examples. NSIS falls here as well. Erik From owner-multi6@ops.ietf.org Fri Nov 19 14:10:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02956 for ; Fri, 19 Nov 2004 14:10:09 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CVE8n-000I3W-Vq for multi6-data@psg.com; Fri, 19 Nov 2004 19:09:53 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CVE8n-000I39-2f for multi6@ops.ietf.org; Fri, 19 Nov 2004 19:09:53 +0000 Received: from jurassic.eng.sun.com ([129.146.81.144]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iAJJ9qpv019598; Fri, 19 Nov 2004 11:09:52 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAJJ9qqb445875; Fri, 19 Nov 2004 11:09:52 -0800 (PST) Message-ID: <419E4534.7020709@sun.com> Date: Fri, 19 Nov 2004 11:10:44 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: Brian E Carpenter , multi6@ops.ietf.org Subject: Re: flooding attacks and threats doc (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <419A5475.2000901@piuha.net> <009701c4cc21$ff7ce9e0$861167c0@adithya> <42A84E2B-38B3-11D9-AEEC-000D93ACD0FE@it> <419B91A1.5010505@sun.com> <419C7A40.90400@zurich.ibm.com> <419C7B67.8090703@piuha.net> In-Reply-To: <419C7B67.8090703@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since nobody suggested text, I've added the second paragraph below in section 4.3: An attacker can use the ability to perform redirection to cause overload on an unrelated third party. For instance, if A and B are communicating then the attacker X might be able to convince A to send the packets intended for B to some third node C. While this might seem harmless at first, since X could just flood C with packets directly, there are a few aspects of these attacks that cause concern. Such an attack might be against the resources of a particular host i.e., C in the example above, or it might be against the network infrastructure towards a particular IP address prefix, by overloading the routers or links even though there is no host at the address being targeted. Erik From owner-multi6@ops.ietf.org Fri Nov 19 15:27:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10948 for ; Fri, 19 Nov 2004 15:27:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CVFJ2-0001Hr-HQ for multi6-data@psg.com; Fri, 19 Nov 2004 20:24:32 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CVFJ0-0001HN-Qm for multi6@ops.ietf.org; Fri, 19 Nov 2004 20:24:31 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAJK5hG25873; Fri, 19 Nov 2004 22:05:43 +0200 Date: Fri, 19 Nov 2004 22:05:43 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: multi6@ops.ietf.org Subject: Re: Comments on multi6dt documents In-Reply-To: <419E40EB.2000707@sun.com> Message-ID: References: <419112EC.3010706@sun.com> <41923BED.9040509@sun.com> <4193C479.1090702@sun.com> <419E40EB.2000707@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 19 Nov 2004, Erik Nordmark wrote: > Pekka Savola wrote: >> True .. but firewalls of today don't even have a _chance_ of skipping over >> the extension header, even if they, or their administrators would want that >> (well, if the extension header is in TLV format, maybe then, because some >> firewalls assume the next ext headers are in TLV). Destination options at >> least allow that possibility. > > If any future extension headers follow the canonical format: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | Hdr Ext Len | .... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > then one can build firewalls that are liberal in what they accept. s/are liberal/can be configured to be liberal/ -- the point may be subtle but I believe it's rather important :) >> Sorry, I was just trying to figure out a term which says, "requires the >> host's shim layer and possibly some weirder middleboxes (like stateful >> firewalls, when they want to figure whether to pass this error in or not) >> have knowledge of applications' semantics [and if there are new such >> applications, requiring that this application knowledge to be updated], to >> be able to mangle the addresses inside the payload correctly." > > It isn't "applications" - it is what I'd call "IP signaling protocols" or > something like it; protocols which are not end-to-end but involve the routers > along the path. ICMP errors from the routers, or RSVP signaling is what we > currently have as examples. NSIS falls here as well. Yes, IP signaling protocols is probably closer, but with some warning because there appear to be people out there who think "signaling" in the IP world means invariably IntServ-like QoS... :-/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Sat Nov 20 08:07:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19710 for ; Sat, 20 Nov 2004 08:07:08 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CVUvZ-0007fr-Ki for multi6-data@psg.com; Sat, 20 Nov 2004 13:05:21 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CVUvX-0007ea-4D for multi6@ops.ietf.org; Sat, 20 Nov 2004 13:05:19 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BF261303AD; Sat, 20 Nov 2004 14:05:15 +0100 (CET) Received: from [163.117.252.23] (unknown [163.117.252.23]) by smtp03.uc3m.es (Postfix) with ESMTP id B6A84303A2; Sat, 20 Nov 2004 14:05:12 +0100 (CET) In-Reply-To: <419E4534.7020709@sun.com> References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <419A5475.2000901@piuha.net> <009701c4cc21$ff7ce9e0$861167c0@adithya> <42A84E2B-38B3-11D9-AEEC-000D93ACD0FE@it> <419B91A1.5010505@sun.com> <419C7A40.90400@zurich.ibm.com> <419C7B67.8090703@piuha.net> <419E4534.7020709@sun.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6BC722B8-3AD9-11D9-84BB-000D93ACD0FE@it> Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org, jari.arkko@piuha.net, Brian E Carpenter From: marcelo bagnulo braun Subject: Re: flooding attacks and threats doc (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt Date: Sat, 20 Nov 2004 10:49:07 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable This is good for me thanks, marcelo El 19/11/2004, a las 20:10, Erik Nordmark escribi=F3: > > Since nobody suggested text, I've added the second paragraph below in=20= > section 4.3: > > An attacker can use the ability to perform redirection to cause > overload on an unrelated third party. For instance, if A and B > are communicating then the attacker X might be able to convince A to > send the packets intended for B to some third node C. > While this might seem harmless at first, since X could just flood C=20 > with > packets directly, there are a few aspects of these attacks that cause > concern. > > > Such an attack might be against the resources of a particular host=20 > i.e., C > in the example above, or it might be against the network = infrastructure > towards a particular IP address prefix, by overloading the routers or=20= > links > even though there is no host at the address being targeted. > > Erik > > ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Sun Nov 21 00:05:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25639 for ; Sun, 21 Nov 2004 00:05:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CVjq2-000Gs5-2l for multi6-data@psg.com; Sun, 21 Nov 2004 05:00:38 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CVjpy-000Grk-Sl for multi6@ops.ietf.org; Sun, 21 Nov 2004 05:00:35 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id DB8FF6BC for ; Sun, 21 Nov 2004 00:00:31 -0500 (EST) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 21 Nov 2004 00:00:31 -0500 Message-Id: <20041121050031.DB8FF6BC@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=ADDRESS_IN_SUBJECT,BAYES_05 autolearn=no version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 13.79% | 8 | 17.49% | 43111 | marcelo@it.uc3m.es 12.07% | 7 | 17.29% | 42633 | mohanp@sbcglobal.net 13.79% | 8 | 13.05% | 32183 | brc@zurich.ibm.com 13.79% | 8 | 12.24% | 30178 | erik.nordmark@sun.com 12.07% | 7 | 9.98% | 24610 | iljitsch@muada.com 10.34% | 6 | 7.86% | 19378 | jari.arkko@piuha.net 5.17% | 3 | 7.27% | 17913 | touch@isi.edu 6.90% | 4 | 5.27% | 12994 | francis.dupont@enst-bretagne.fr 3.45% | 2 | 3.27% | 8071 | pekkas@netcore.fi 1.72% | 1 | 1.43% | 3518 | h.soliman@flarion.com 1.72% | 1 | 1.36% | 3358 | john.loughney@nokia.com 1.72% | 1 | 1.20% | 2968 | jinmei@isl.rdc.toshiba.co.jp 1.72% | 1 | 1.19% | 2926 | sra@hactrn.net 1.72% | 1 | 1.10% | 2700 | matthew.ford@bt.com --------+------+--------+----------+------------------------ 100.00% | 58 |100.00% | 246541 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Mon Nov 22 15:41:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13364 for ; Mon, 22 Nov 2004 15:41:37 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CWKxZ-0006xS-05 for multi6-data@psg.com; Mon, 22 Nov 2004 20:38:53 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CWKxX-0006xD-VJ for multi6@ops.ietf.org; Mon, 22 Nov 2004 20:38:52 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13079; Mon, 22 Nov 2004 15:38:49 -0500 (EST) Message-Id: <200411222038.PAA13079@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-multihoming-threats-02.txt Date: Mon, 22 Nov 2004 15:38:49 -0500 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Threats relating to IPv6 multihoming solutions Author(s) : E. Nordmark Filename : draft-ietf-multi6-multihoming-threats-02.txt Pages : 33 Date : 2004-11-22 This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-threats-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-multihoming-threats-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-multihoming-threats-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-22160509.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-threats-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-threats-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-22160509.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Tue Nov 23 09:55:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16827 for ; Tue, 23 Nov 2004 09:55:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CWc2g-000F15-Ay for multi6-data@psg.com; Tue, 23 Nov 2004 14:53:18 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CWWII-0007yE-24 for multi6@ops.ietf.org; Tue, 23 Nov 2004 08:45:02 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A0C6F2D887 for ; Tue, 23 Nov 2004 09:45:00 +0100 (CET) Received: from [163.117.139.34] (unknown [163.117.139.34]) by smtp02.uc3m.es (Postfix) with ESMTP id 7B7A32D858 for ; Tue, 23 Nov 2004 09:45:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: marcelo bagnulo braun Subject: MoMiPriv Mailing List Announcement Date: Tue, 23 Nov 2004 09:45:05 +0100 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, A new mailing list dedicated to Privacy for mobility and multi-homing (MoMiPriv) discussions has been set up. To subscribe, please visit: http://lacnic.net/mailman/listinfo/momipriv regards, marcelo ------------------------------------------ Please note that my former email address mbagnulo@ing.uc3m.es is no longer in use Please send mail to: marcelo at it dot uc3m dot es ------------------------------------------ From owner-multi6@ops.ietf.org Wed Nov 24 09:27:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27317 for ; Wed, 24 Nov 2004 09:27:05 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CWy57-0003Sh-Ls for multi6-data@psg.com; Wed, 24 Nov 2004 14:25:17 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CWy54-0003SN-Rr for multi6@ops.ietf.org; Wed, 24 Nov 2004 14:25:15 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id EE98D89877; Wed, 24 Nov 2004 16:25:13 +0200 (EET) Message-ID: <41A49952.3000201@piuha.net> Date: Wed, 24 Nov 2004 16:23:14 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: multi6@ops.ietf.org Subject: Re: flooding attacks and threats doc (was Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <003801c4cc04$a74ddd50$861167c0@adithya> <003f01c4cc07$ce2587e0$861167c0@adithya> <419A5475.2000901@piuha.net> <009701c4cc21$ff7ce9e0$861167c0@adithya> <42A84E2B-38B3-11D9-AEEC-000D93ACD0FE@it> <419B91A1.5010505@sun.com> <419C7A40.90400@zurich.ibm.com> <419C7B67.8090703@piuha.net> <419E4534.7020709@sun.com> In-Reply-To: <419E4534.7020709@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, Your text looks good. --Jari From owner-multi6@ops.ietf.org Fri Nov 26 01:23:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27644 for ; Fri, 26 Nov 2004 01:23:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CXZSy-000ApE-I7 for multi6-data@psg.com; Fri, 26 Nov 2004 06:20:24 +0000 Received: from [213.204.46.35] (helo=mariehamn.kurtis.pp.se) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CXZSx-000Aoe-CP for multi6@ops.ietf.org; Fri, 26 Nov 2004 06:20:23 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by mariehamn.kurtis.pp.se (Postfix) with ESMTP id 6BC9F3091C0 for ; Fri, 26 Nov 2004 08:20:18 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <44BEF211-3F73-11D9-B14D-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Mini WGLC draft-ietf-multi6-multihoming-threats-02.txt Date: Fri, 26 Nov 2004 07:20:29 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 All, hereby we start a "mini" Working Group Last Call for the threats document. This concludes on December the 1th 17.00 CET. Kurtis & Brian Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: den 22 november 2004 21.38.49 MET > To: i-d-announce@ietf.org > Cc: multi6@ops.ietf.org > Subject: I-D ACTION:draft-ietf-multi6-multihoming-threats-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Site Multihoming in IPv6 Working > Group of the IETF. > > Title : Threats relating to IPv6 multihoming solutions > Author(s) : E. Nordmark > Filename : draft-ietf-multi6-multihoming-threats-02.txt > Pages : 33 > Date : 2004-11-22 > > This document lists security threats related to IPv6 multihoming. > Multihoming can introduce new opportunities to redirect packets to > different, unintended IP addresses. > > The intent is to look at how IPv6 multihoming solutions might make > the Internet less secure than the current Internet, without studying > any proposed solution but instead looking at threats that are > inherent in the problem itself. The threats in this document build > upon the threats discovered and discussed as part of the Mobile IPv6 > work. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming- > threats-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-multi6-multihoming-threats-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-multi6-multihoming-threats-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2004-11-22160509.I-D@ietf.org> -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQabLMaarNKXTPFCVEQLZNgCcDjH1iOpmbG6a+w2Mapw4cNs4pyMAn25F zdYuTl9UHWQyGhpfpn9MfkGt =Dqn2 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sun Nov 28 00:03:38 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20884 for ; Sun, 28 Nov 2004 00:03:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CYHAw-00035A-Fa for multi6-data@psg.com; Sun, 28 Nov 2004 05:00:42 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CYHAv-00034m-MC for multi6@ops.ietf.org; Sun, 28 Nov 2004 05:00:41 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id CB666685 for ; Sun, 28 Nov 2004 00:00:40 -0500 (EST) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 28 Nov 2004 00:00:40 -0500 Message-Id: <20041128050040.CB666685@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=0.3 required=5.0 tests=ADDRESS_IN_SUBJECT,AWL, BAYES_00 autolearn=no version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.00% | 1 | 30.71% | 5200 | internet-drafts@ietf.org 20.00% | 1 | 28.66% | 4852 | kurtis@kurtis.pp.se 20.00% | 1 | 16.05% | 2717 | sra@hactrn.net 20.00% | 1 | 12.49% | 2115 | marcelo@it.uc3m.es 20.00% | 1 | 12.09% | 2046 | jari.arkko@piuha.net --------+------+--------+----------+------------------------ 100.00% | 5 |100.00% | 16930 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Nov 28 17:24:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21267 for ; Sun, 28 Nov 2004 17:24:42 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CYXRM-0003gF-TT for multi6-data@psg.com; Sun, 28 Nov 2004 22:22:44 +0000 Received: from [169.237.104.165] (helo=rome.ucdavis.edu) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CYXRL-0003fj-An; Sun, 28 Nov 2004 22:22:43 +0000 Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by rome.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iASMMW4a022966; Sun, 28 Nov 2004 14:22:33 -0800 (PST) Received: from phaenicia.ucdavis.edu (localhost [127.0.0.1]) by phaenicia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iASMMWE1009821; Sun, 28 Nov 2004 14:22:32 -0800 (PST) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id iASMMVNR009820; Sun, 28 Nov 2004 14:22:31 -0800 (PST) Date: Sun, 28 Nov 2004 14:22:31 -0800 (PST) Message-Id: <200411282222.iASMMVNR009820@phaenicia.ucdavis.edu> To: fanzhao@ucdavis.edu Subject: Call for Papers: IEEE JSAC MRNM From: "Fan Zhao" Cc: manet@ietf.org, nemo@ietf.org, mip6@ietf.org, hipsec@honor.trusecure.com, mip4@ietf.org, mipshop@ietf.org, multi6@ops.ietf.org, v6ops@ops.ietf.org, mobopts@irtf.org X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications and models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com From owner-multi6@ops.ietf.org Tue Nov 30 07:40:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13161 for ; Tue, 30 Nov 2004 07:40:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZ7HN-000NY8-R0 for multi6-data@psg.com; Tue, 30 Nov 2004 12:38:49 +0000 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZ7H4-000NTq-A1 for multi6@ops.ietf.org; Tue, 30 Nov 2004 12:38:47 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAUCc8VQ054740 for ; Tue, 30 Nov 2004 12:38:10 GMT Received: from sihl.zurich.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAUCcEtC263648 for ; Tue, 30 Nov 2004 12:38:14 GMT Received: from zurich.ibm.com (sig-9-145-133-194.de.ibm.com [9.145.133.194]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA09422 for ; Tue, 30 Nov 2004 13:38:05 +0100 Message-ID: <41AC69B2.6020009@zurich.ibm.com> Date: Tue, 30 Nov 2004 13:38:10 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Draft multi6 minutes Content-Type: multipart/mixed; boundary="------------010902080601010708060306" X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,START_NOW_CAPS autolearn=no version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------010902080601010708060306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please check for substantive errors in the next day or so. Thanks to our scribes, and to Kurtis for merging the raw notes. Brian --------------010902080601010708060306 Content-Type: text/plain; name="multi6-ietf61-minutes.txt" Content-Disposition: inline; filename="multi6-ietf61-minutes.txt" Content-Transfer-Encoding: 7bit Multi6 notes, IETF 61, Nov. 9 2004 - Session 1 ---------------------------------------------- Notes taken by Tom Henderson Jabber log by George Michaelson Meeting opened 9:02am. Chaired by Kurtis Lindqvist and Brian Carpenter Brian Carpenter (BC): looking for a jabber scribe? BC: Tom Henderson will take the minutes BC: Who will be our jabber scribe today? George Michaelson (GGM): I can do jabber. BC: please, Roy Brabson will also help Kurtis Lindqvist (KL): Agenda review. Meeting continues tomorrow-- may have to cut some time. Close tomorrow on the next steps for the working group. KL: Reminder to note the terms and conditions of IETF meetings and contributions, and signing blue sheets. KL: Starts the agenda. Notes that we may have to cut the line, save discussions for tomorrow. ** draft-ietf-multi6-multihoming-threats-01.txt i) threats documents-- did have some comments. BC: IESG made mistake and looked at previous version of the draft, but most comments relevant anyway, and new version addresses them. Will run through group as mini-repeat last call, but nothing substantial? Erik Nordmark (EN): No substantial changes. KL: so short last call! ** draft-ietf-multi6-v4-multihoming-02.txt KL: It was observed that it won't pass id-nits check due to lack of index. BC: One substantial comment received: is it worth publishing? Any comments on this question? Elwyn Davies (ED): Needs serious rework, if it is to go out at all. Can't deal with upstream failures, not on the local link. John Loughney (JL): Would be a good document if editorial could be cleaned up. ED: Offers to help to edit language and get remaining issues fixed. BC: Will send out for new last call after that. ** draft-ietf-multi6-things-to-think-about-00.txt KL: As far as I know there is a new version coming, comments being factored in. Eliot Lear (EL): Pekka Savola and Tim-- only comments received-- specifically clarification on what problem are you trying to solve, piggybacking issues, IPv6 renumbering, and Pekka wants more detail on DNS. Wants people to spend more time and see whether and how the document is useful to them. ** draft-ietf-multi6-architecture-02.txt Geoff Huston (GH): I got one comment from Pekka Savola, and one form John. They where the same and are close to being solved. I will resubmit an -03. BC: Will do mini-last call on all four documents. One week repeat last call. 2. General report from design team (Erik Nordmark) =================================================== EN: We met twice in SanDiego, to get common understanding. We have then had email discussions, strawmen. We also met for 2 full days in Manchester/RIPE. EN: The forced deadline, and writeup pressure kept us away from contentious issues. EN: We have tried to accomplish: - Minimal/no dependency on DNS (working for hosts without FQDN). - Tried to allow application referrals to work. Maybe not optimally, - 'Good enough' security. - Time-shifting attack avoidance . - We wanted to think about privacy. - Id's in v6 addresses. EN: We acknowledge we can't solve mobility but extensible to it. EN: We also wanted to (perhaps controversial?) avoid hard-coded /64 subnet boundary. EN : Things that we assumed - Ingress filtering can make it hard to go out to ISPs. We want to cope with that with interactions btween routing, filtering. - We assumed DNS has its own idea of 'redundancy' with multiple DNS recs. No known circular dependencies. EN: Things still needed are - Congestion control. Test for multiple locator at both ends, cartesian product is the worst-case test. Can we parallelize? EN: Things we didn't explore in depth - No packet formats in draft. Not even how many types. - Nothing on state management. How to remove state? When? Coordinated e2e? EN: We also discussed non-reachable locators, used as ULIDSs. eg ULAs. I believe nothing in approach developed to prevent. But don't have all the pieces to do it. EN: We can use registered form of ULAs. People that use them can decide to populate reverseDNS, add capabilities, given ULA find all locaters via DNS. EN: One optional thing. Can we handle non-/64 boundary stuff? Shorter or longer prefixes? Believe can be done. But it is not clear if community care/support. EN: The next steps for the design team is - Drafts in-hand, - Team should cease to exist. - Maybe an editing team. - Do stuff on WG ML. EN: Next steps are not clear, chairs discussion needed on what to do with loose ends, things like that and specific questions. Iljitsch van Beijnum (IvB): what's this dnsop unreachable issue? George Michaelson (GGM): I have a draft in DNSOP about not publishing unreachables. This needs liaison. 3. Erik next presented the first design team draft: Multihoming L3 Shim Approach draft (draft-nordmark-multi6dt-shim-00.txt) ======================================================================== EN: This is an overview. It does not introduce a new namespace. Where does the shim go? Deferring context, assumptions about DNS, receive side demux, and open issues . EN: Define upper-layer identifier, ULID as a 128 bit quantity. It is not well defined, useful to have term. EN; Locators are not different to what we do today. ULID seen by TCP, UDP as well as applications. EN: Placement of l3 shim? - Above IP endpoint layer, below frag, IPSEC. EN: Has to be above first hop router, i/f logic. EN: This is not written down, but is clean split between these functions. EN: Benefits are, things above can operate based on ULID. Do re-assembly on them. IPSEC security association bound on them. When we rehome, security assoc still there. EN: The disadvantages are that the shim needs to insert bytes in packet. This implies needs to make that visible to upper layer proto for fragmentation issues. EN: Deferred context establishement EN: 3 events occurring at different times. i) Initial contact. ii) Deciding to setup multi6 congtext state. Based on local policy-- port numbers, #packets sent, etc. iii) Rehoming the connection after a failure. Also need to handle failures during the initial contact, which is the base case-- punt to the application layer to try different ULIDs possible to optimize by having shim do something. EN: We need to handle failures during initial contact. Multiple handles for local peer, first attempted connect doesn't work. The shim draft talks about easiest case: punt to application. EN: Assumptions about the DNS EN: none. (!) EN: FQDN may be for service or host. DNS returns set of potential ULIDs. Try one until we find a working locator. This is not neccessarily a locator used for failover (could be 3 different hosts). When we set up Multihoming context, find out 'other locaters, not ones found in DNS'. EN: But we want to optimize initial contact failure issues. This means we need to be aware of multiple host issues. EN: Receive side demux issue EN: Some people call this approach NAT. EN: Packets going from one upper-layer protocol to other, sending side, on a failure IP adddresses get changed. There is a need to reset receiving side before passing to upper layer. EN: To do this, need to avoid being confused! Example was discussed. ULID A starts to communicate with two hosts ULIDs B and C. then discovers they are the same. Then locator B fails. now,send packets from locator A to locator C. Some need rewrite to ULID B, some don't. EN: Things upper layer explicitly sent to B and C have to be separated. How to make sure enough info to correctly re-write things. Pekka Savola (PS): Two clarifications (one from previous slide) i) I think you have some assumptions about how you deal with DNS for referrals, right? EN: Maybe confusing things. There is a potential to do things differently with registered ULAs. We could use DNS for some things or have applications using DNS for referrals without that. Applications which operate on domain names are part of reason to put stuff up here, to contrast with other things, like NOID. PS: Yes. Basic service doesn't have assumptions on DNS. Great. But there might be underlying hidden assumptions about stuff. BC: There is a draft on this nontrivial application layer issue. We can discuss this tomorrow. PS: I think one thing that needs explicit consideration is whether receiving ICMP errors from network is sufficiently satisfied as special case of referral. EN: I have slide on that. This was also brought up on the mailinglist. EN: RSD: prevent receive side confusion EN: Only use locator with single ULID. EN: This means that a host with 3 prefixes would have 3 prefixes and 9 locators. EN: During initial contact we have fallback opportunities, during dialogue, we need six additional locators, these are locators ONLY, and never used as ULID. uniquely identify ULID. EN: Just looking at locators, addresses sufficient to map. EN: RSD carry additional info EN: eg call it context tag. Something to help identify where does it go in the packet? Believe can use flow-id. Or as a new extension header? EN: After rehoming, failures, add ext header, minimum after size/alignment rules is 8 bytes. Please send comments to the mailinglist. EN: Open issues are - Carrying flow label across the shim. - Hard to understand constraints due to overloading. - We need to discuss checking againts things to think about. EN: We also need to discuss Pekka's issues with ICMP error demux. Erik thinks less severe problem than Pekka. EN: We need more clarity on ULAs. Our intent is to study centrally assigned ULAs. These may make it easier for applications. Erik's' personal opion is that we can not only support these. We will need non-central as well. EN: Handling unreachable ULIDs. Two issues. Registered (in reverse DNS), are they permanently unreachable? During initial context establishment, using permanently unreachable from most of internet (most unique locals) then should know, use other ones. end of presention. BC: Encourages people at the microphone to stick to clarification issues, and keep discussion tomorrow Christian Huitema (CH): Very nice piece of work. One question: you propose using locator as ID for flow-- we actually have some experience at Microsoft and ran into problem-- what happens if locator is only on loan? You move to a place, they give you an address, you move on, then address is given to someone else. EN: These addresses are not permanent-- for how long are these addresses assigned to you? BC: I am not sure. This on boundary of mobility/MultiHoming. EN: These addresses are not permanent-- for how long are these addresses assigned to you? CH: Using temporary locator to maintain long duration connection creates an issue-- should be listed as such. EN: Normally, address would become unreachable, but here we are making it explicitly bound in the TCP state. EL: This is crux of Tim's issue that he wanted to add to things-to-think-about. Can't get into situation where we always sweep it under the mobility rug. BC: After next talk, ask question again. 4. Marcelo presents next draft: Hash Based Addresses (draft-bagnulo-multi6dt-hba-00.txt) ======================================================== Marcelo Bagnulo(MB): presents security issues, and threats in Erik's draft. Hijack/flooding issues. But focus on hijacking for now. MB: Have approaches to deal with hijacking. This is based on using cookies, (time shifting attacks issue) or PK crypto (seems overkill). MB: Characteristics of HBAs MB: resulting set of HBA are static. can't add new ones. MB: Main idea is to include info about multiple prefixes in addresses themselves. HBAs are a hash of interface plus a random number. MB: Discusses example of two host dialogue. Then he loses one path, can check validity of new dialogue via HBA. HostA in multihomed site: P1&P2 Generate HBAs for HostA - iid = Hash(P1|P2|rand) - Addresses for Host 1: P1:iid and P2:iid - Host communicates set of prefixes and rand to peer (can be in clear text) - If failure occurs, communication rehomed to P2, because peer can verify that P2 belonged to the hash-- this is main idea behind idea MB: Shows flow/event sequence MB: Compatibility with CGAs MB: Use same interface id bit. SeND uses CGAs. Interesting not to impose requirement to use ours or theirs. MB: CGA based multi6 can do dynamic cases. Useful for renumbering. If they are compatible, we can support both. MB: We can define HBA as CGA extension MB: Resulting address types i) CGA-only addresses ii) CGA/HBA addresses iii) HBA addresses MB: Discussing hash/generation sequence, some consideration of privacy outcomes. MB: HBA set verification, be sure the prefix included is the proper one. This is verified by runing CGA process. MB: Security considerations MB: How to attack. Generate CGA structure with own prefix. Then find a modifier such that it matches H1 under hash test. O(2^59) or O(2^(59+16*Sec)). MB: For this a brute force attack is required. MB: Privacy considerations. MB: There is no fixed identifier on low 64 bits. MB: The first implementation of HBAs by Frances Dupont {ENST}, feedback on ML. end presentation CH: Marcello, one point of extension that I want to understand. If address is CGA address, do I still need to hash all prefixes, know in advance to be secure? MB: If just CGA you don't need that. You can build only using CGA. CH: in signalling done negotiating locators, can use either CGA or HBA? MB: No. It is an idea, and could be an option, but idea here is to generate HBA addresses. If move between ones made in HBA, we can use without PK crypto. If we want to add new ones, have to move to PK crypto, use CGA. CH: Idea is to stay within HBA, we can use simple hash method. If move outside that site, constrained to use CGA. MB: We can have one addresses, but stay within prefixes, can use properties of HBA. But new prefixes have to use CGA. Don't have to change address but verification method is different in one case to other. CH: I did not understand from the presentation. Secondary hash for null bits. I don't understand applying that ? How to do that without any reference to PK. MB: Security parameter increases amount of work. It is used exactly the same way as in CGA. CH: Intellectual property on SEND also probably applies here. BC: (co-chair hat is off): I sent a mail to the mailinglist that I got no answer to. The remote host need copy of CGA parameter structure, right? I don't quite understand how man in the middle can't capture the parameters and add one more bogus address to the set by running the loop in the algorithm one more time. MB: I didn't get the mail. IID will be different-- will be hijacking. If you add something to the prefix set, the IID will change for all of them. BC: The remote host, needs complete copy of CGA param data structure. This includes in HBA case, pseudo random modifier which replaces PK. I don't understand why Man in the middle can't run the algorithm one more step, add one address at end. MB/BC: Discusses implication of mitm able to add extra address. now believed by receiver. BC: We can take this discussion off-line. EN: Following on that, there is a class of MiTM, eg TCP relay, NAT box, what being described, those attacks exist in V6, will exist in this one Property of these attacks is that it is only effective while MiTM is on the link. as soon as attacker off link, he cannot intercept pkts. BC: I am not sure, not thinking about time-shifter attack. EN: To Christian's point about CGA vs CGA/HBA hybrids. There are a few things we haven't written up about hybrid HBA/CGA addresses. If you use HBA property, can just use the hash. If you fall back on CGA properties, verification becomes more expensive. This could be a useful property. BC: We need to wrap up soon on this one. ??: Time shifting attack-- can change interface ID-- but then moves to where his other prefixes are, and has shifted the traffic. EN: I am not sure. If we have created TCP connection in peer for new interface id, prefix different state. Fundamental MITM attack is same as a TCP proxy. CH: If there is no link to actual identity, then you risk a third party capture of one of the locators of the host, and then I can move a TCP connection-- that is the attack if you do not have a secret. (EN or MB): If not using SECURE neighbour discovery, can be caught. this doesn't change under Multi6. MB: We don't need CGA for secure neighbour discovery. what do you publish in DNS as IP addresses ??: What do you publish in DNS? MB: The set. Use any one. BC: How many people actually read this draft? It is complicated. Is this too complicated to implement except for ambitious implementors? CH: Would be more comfortable if you could run a pure CGA solution. Tradeoff between performance and complexity of software. Doing CGA should be enough if that is all I have implemented. Hannes Tschofenig (HT): Concern is IPR issue. It is great that these addresses have self-certifying properties, but there is a fundamental piece in the Internet, and strikes me strange that it has intellectual property attached to it. Matt Ford(MT): Complexity question. HBA is actually simpler to implement than CGA. CH: If already done CGA, it is more work to also do HBA. BC: Don't confuse technical discussion with IPR discussion right now. EL: My concern with Christian's proposal that only implementing CGA should be sufficient is that you need at least one way to interoperate. 6. Marcelo presents next draft: Functional decomposion of M6 (draft-bagnulo-multi6dt-functional-dec-00.txt) =================================================== MB: On initial contact we need to do capabilities detection stuff. MB: Failure during startup. Hhow to deal with legacy hosts. Either retry using different address or try same ULID, change locator, needs v6 support so implies capability detection. MB: M6 capabilities detection. There are several ways to do it. The non-scaleable is manual config or DNS config. Let's say target is M6 capable or make part of protocol. MB: This is preferred, simple, more flexible. MB: M6 host-pair context establishment. Whats in the context? ULIDs, at least one locator, can add more, means sending more info. but gives fault-tolerance MB: It is probably a good idea to leave open, leave to host, balance fault tolerance/cost issues. We may need context tag for multiplexing. security info. MB: Continuing M6 host establishment. State can imply memory exhaustion. What we need is - ULIDs - at least one locator per host - additional locators? - context tag? -> demux - security info - cookie/key/hash chain anchor - additional info to prevent future time-shifting attacks MB: Goes through slide of time-sequence exchange diagram. Then goes through the sequences of adding additional locators, security exchanges, cookies. MB: For locator set management we have to manage (add/remove) locators. Need to communicate e2e. We may need to remove for local reasons eg router deprecates, want to let other end know. This could be state differencing with ack, or atomic send of set with ack. There are issues with synchronizing incremental. atomic doesn't require, but impose other additional overhead. re-sending stable state. MB: Locator set mgt security. We need to provide strong security to avoid time-shifting attacks. EN: It might seem odd, that it doesn't talk about HBA at all, but it's intentional. This presentation doesnt assume any particular security scheme. HBA might/would satisfy requirements, but not assumed. BC: But it does say 'we need solution in this space'. MB: Removing locators, simpler. MB: Rehoming. Sequenced move to a new locator. Failure detection, reachability testing. This is not trivial with unidirectional paths. Jari presents on complex cases. MB: Removal of M6 session state. May be unilateral, or coordinated. could be DoS attack to do unilateral. coordinated means ACK flows (eg NOID). EL: In case of unilateral, how to envision case handled have long standing state, one side reboots? I am concerned about error msg, ddos attack, but don't get answer, is the idea to timeout and re-initialize state 0? MB: One side reboots, other end send new packets. error msg should be answered? EL: But there are ddos concerns there right? MB: Yes. I am not sure how to deal with it. But hoping we could do better. EN: Not the main concern here. If you establish the state, presumably you can define things such that MITM that shows up late is not as effective. Such an error message can aid the MITM attacker that shows up late. EL: Another question going back. Is it possible to take advantage of pre-established stuff? MB: First we have initial context, then we have deferred. BC: (not co-chair) You indicate that it is not the complete solution right? So my comment is that we've seen other bits of functional proposal, and Eliot reminded me of the database where stuff could be stored (CELP). Does design team want to go there-- a complete functional decomposition with architecture and interfaces and diagrams? EN: Answer question with question. What is complete? can store quality metrics. can choose good ahead of just working but complete is 'scary' BC: Complete not to the level of UML, but so that Francis (Dupont) could implement all of the boxes. EN: How would hardware? work together with this software? Probably not looked at yet. BC: Very happy with documents, but all leave open questions right now (possible exception is HBA). How quickly to get rid of these questions? Another three years? CH: Some of the points similar to mobility. I wonder to what extent there are possibilities to use common code? GH: This is not a new question. Not a new answer coming: asked in March, again in August. The response was drafted by Marcello in arch draft. The response is that fundamental issues in MobV6 depend on 'tethering' with timers, update timers. A bunch of timers would be a showstopper in Multi6, never sure where tether point is. Not a lot translates, but if you disagree, doc is not published, if feel analysis is incorrect 'send words' to the list. BC: We have 10 minutes to continue then have to move on[chair] EN: There aren't many things undefined that would prevent you from getting up and running. However, people will likely be concerned with detailed packet design-- up to working group to resolve that. We could build something today, we don't have big architectural questions-- but we have to agree on details. MB: Some open issues with state management, though. We've identified that. 7. Jari Arkko presents next draft: Failure Det./ Loc. Selection (draft-arkko-multi6dt-failure-detection-00.txt) ============================================================================ Jari Arkko (JA): Background. Some problems are quite similar to MULTI6 and HIP, and what MOBIKE needs. Work ongoing on those two. SCTP is a bit different than what is being worked on here. More static, with apps telling transport what to use Mobility and host address configuration work as well as Multihoming basics JA: What is multihoming? Typically multiple prefixes for some of tte participants. May be one or both ends. Nodes know their own addresses, but don't know all the locators for peer. Need to learn those through multi6 protocols. Need to learn peers addresses before a problem occurs. Both peers can loose their addresses, and you can't switch to the other since you haven't told the peer. Where do node's own addresses come from? From other parts of the stack - e.g., DHCP, Neighbor Discovery Processes are not trivial - DAD, etc. JA: Where do a node's addresses go? Addresses taken away by same mechanisms. JA: Addresses - what is their status? JA: Security: need to believe what configuration mechanisms tell us. If we have an address, and a spoofer tries to convince a node the address is no longer valid - while this is possible, can't do anything in MULTI6 as other parts of the stack believe this information. If lower layers believe link is down or address not usable, MULTI6 can't do anything about that. Even if assign address to interface, link may be down so you may not be able to use it. [A few address-related definitions] JA: Available address: address assigned to interface, valid, but may not be able to use it. Locally-operational address: address is available, default router is reachable. JA: Interface to related modules. Configuration modules (e.g., DHCP) that handle address assignment tasks. Other work in DNA and DHCP to improve characteristics to changing connectivity at the "lower layer"? Answer is no. Not even if you can talk to someone else, it doesn't guarantee you can talk to another node. JA: Definition of address pair. Address pair: pair of addresses (src,dst) used in communications between two peers. Operational address pair: both addresses locally operational, traffic flows when the pair is used. This is what you need in multihoming. JA: Symmetric vs. assymetric address pair reachability. Reachability may not always be two-way. Can use one pair in one direction, but can't be used in the other. Can construct multi6 to handle this, but do we want to add complexity for this? BC: Do we want to add this to the goals to address this? Not in goals, but may be useful. CH: Also noted in analysis of egress filtering that it is something that can happen. If we can support without making too complex, then we should do it. BC: In other words, reachability is not commutative. JA: Selecting an address pair. How do we know if there is a problem? If lower layers tell us the address went away or can't be used, we know we have a problem. Can also have explicit tests - periodic ping between pairs, for instance. If this doesn't get through, may have a problem (might be transient). Lack of TCP progress also can be used as an indication of a problem. ICMP may or may not be a problem. Picking another pair. SCTP has some functionality, but no other protocols to pick pairs. HT: ICE and STUN use some of these types of mechanisms. JA: Picking another address pair. Need exponential backoff on selecting new pair - e.g., to handle site link going down. Downside is backoff can cause the time to recover can take a long time if there are enough addresses. As a result, try address pair that is most likely to work. Nodes may have preferences on addresses they want to use. You can signal partner about your preferences for your addresses within multi6. For rest, can have heuristics. Leave these to implementations. Testing for bidrectional reachability is easy. Unidirectional connectivity is harder. JA: Finding pairs - unidirectional case. Chart showing case: - Peer A sends a poll to Peer B using a particular pair. - B sees A has a problem, and starts the same process. - B sends a packet to A using hte same pair, but that message is lost, so you can't answer. - A continues a pair, with a different src address, with the same dst. This is lost. - B sends a different packet with a different src to A, and it reaches A. - A now knows its packet reached. - A then sends a poll to B saying its poll messages are getting through. JL: Whatever mechanism you decide, please make sure it works through middleboxes. Must assume something that generally works-- if you use TCP for probing, for example, your UDP might not get through. EN: Depends-- does it make sense to make test packet get through if failover traffic will not. BC: Does discovery mechanism meet same constraints as data traffic? JL: Polling needs to work no better than regular traffic, but can work worse. CH: Avoid e.g., IPsec problem where IKE might work and IPsec doesnt. JA: Suggested Design Principles. Multi6 should not reinvent DHPC, and should believe what ND tells us. Own addresses learned locally, peer addresses are communicated. Search proecedures need to apply exponential backoff multi6 only works as a fail-over. No load balancing (would cause prolems to TCP), and no selection of "best" path (harder than a "working" path). No mandated search order, and no application input on "primary" and "backup". JA: Some open design principles. Do we need to support unidirectional? OK not to support link-locals? JA: Some architectural issues. Need to tell ULPs that we changed prefixes or addresses. Division of work in multi6 and transport/app layers. Some reachability at multi6 and at transport (e.g., TCP). Congestion information at transport, and application requirements on what is acceptable connection. For instance, application needs higher throughput even if there is connectivity, and wants multi6 to switch to new connection. end of presentation. BC: You are hinting at some components not in Marcelo's presentation. EL: I have two questions. First, I don't understand issues with different levels of scoping, where things break down. until he does, don't know why it is architectural. EL: Second is the application requirements - want app to make decision on whether current connection is usable, and if not, get more? JA: More of a question EL: Yes, we do. CH: I have two questiosn, on assymetric, the diagram shows assymetric and walking through it. -- may not be that hard, then, to handle it. CH: Second, on negotiation issue. If we think about firewalls, it would be good that verifying reachability is side effect of sending TCP packets. Firewalls will be open for application traffic, so if signaling piggybacked on this, then it will get through. JA: What if packets only sent in one direction? CH: Yes, but would still be nice. CH: I understand there are border conditions. But in common case, would be nice. CH: Erik's idea to solve multiplexing is to carry in the flow an index to use for demuxing/rewriting. Might be beneficial to have a symmetric index so you can indicate "which of my sources to reply to". CH: Also the point on applications and addresses-- common scenario is some apps allowed on some interfaces but not on others, so we need to be careful there. JA: We have, but just haven't included it in this presentation. Can say that addresses only used for some apps. EN: Contrast between app requirements, and just finding a working path. Way for app to say "try to find something better if you can"? EN: Was wondering about search order-- any work in SCTP on this? Are there heuristic in SCTP search order (differences in high order bits?). Also, if you don't know whether source address or dest. is problem, do you change both at same time? JA: SCTP doesn't say what "different" means. Probably is some previous work there, but I don't know. EN: Reasonable strategies that can be used? If so, we should write them down. EL: Do we need a draft on application requirements? Don't think we need to go that far. Three issues,though. Don't talk to app. App says "not good enough, get me something else". Or mechanism that app can indicate preference based on performance in app. That one needs work. KL: May need section in all the drafts on this topic. JL: More useful also to talk about what are the forms of the API? e.g., OK, try another path... rather than trying to figure out too strictly how to figure out the division. BC: John just said 1/2 of what I want to say. Don't focus on algorithm, but what is interface between module that determines that and the module that requests it. CH: Today, socket API allows application to pin itself to interface, by binding it to a specific address. Means, application can bypass certain multihoming capabilities. Need to preserve this semantics. JA: Only works in one direction. CH: Peer can do what it wants. EN: Interesting thing in application interaction, but we need to understand what it means to bind to an address. CH: Bound to an interface, and all traffic goes through the interface. EN: Maybe we should make this more explicit-- more than just address (such as prefix?) END OF DAY ONE DAY TWO Multi6 notes, IETF 61, Nov. 10 2004 - Session 2 ----------------------------------------------- BC: solicits a name for the minutes... Roy Brabson takes the leaden chalice! BC/KL: next steps discussion, chairs have done some work and will present later. now design team Erik Nordmark will do referrals draft. draft-nordmark-multi6dt-refer-00.txt EN: Was also presented in OpenApps meeting to wake them up a bit. whats needed/tbd for them, in multihoming. EN: [slide: solution approaches] EN: There are several possible solutions. One aspect the design team has explored uses multiple locators without a separate identifier space. This can be contrasted with HIP, which uses a new identifier space that maps to a locator. EN: The identifiers are a 128-bit quantity, called a ULID. Underneath, there are multiple 128-bit locators. A new identifier name space will either take a long time to deploy, or implies a hierarchical allocation in DNS. EN: [slide implications of approaches] EN: Imply at the API, have to see 128bit IDs. calling it the ULID. underneath are multiple 128bit locators. Can be one of the locators. or can be HIP approach, separate thing. might, doesn't matter if reachable or not. EN: [slide, picture of stack/shim issues] EN: To make it explicit where it might be. EN: [slide likely outcome] EN: New ID namespace. delays introducing it, mapping. locator/id. HIP people talking about distributed hash tables. interesting longterm but take a while to get EN: or reuse what we have. AAAA or A6 allocations, in hierarchical manner, ensure only one owner. manage ID space. costs of management. fees but don't want to constrain, apps have to deal with multiple locators when they do stuff. EN: [slide the good news] EN: Applications use 'short term handles' from DNS. no changes required. don't care. EN: If application uses IP addresses in other ways, have to deal with setup, doc tries to name these things. - 'long term handles' - 'callbacks' - referral - identity comparison -dont know to what extent people do this (do people do this? higher level ids sure, cookies, certs..) EN: [slide possible application approaches] EN Use FQDNs as much as possible, bu not always possible. Use single IP addrress. Could use set of locators, or set plus ULID, if different. EN: [slide recommendations] EN: If possible, switch to FQDN. EN: I could say 'use URI' but can contain IP literals. EN: Use set of locators, ULID to get additional benefits (robustness). EN: Need new api getlocalallocators() getpeeralocators() setpeerlocators(). EN: [slide open issues] EN: Where do we do this work? here or apps people or ? EN: Some comment. Makes clear not proposing app interpret set of locators. Just a bunch o bits to store and use in referrals. EN: Questions about applications, should they already have fixed this? could be both 4 and 6?, done ad-hoc today. EN: Some clarifications. People commenting, need to specify API to permit FQDN in the scopes where it would make sense. some people only use the first thing they get from DNS UDP worries, EN: Questions? BC: Not in chair mode. People do comparisons on addresses in the long term. E.g., cookies used by web. Christian H. said in apps area that real serious app suites already handle using multiple addresses, so is it worth replicating at a lower level? Jim Bound(JB): Reading specs, watching, trying to be silent. good presentation. do not tell me again we can't do SCTP because you don't want to change the end node. Changing applications reopens handling multi6 via SCTP. EN: I agree want to be able to do it, but without being SCTP specific. have some technical work, non-specific, shim approach;. L2 shim and want to run SCTP need to work well JB: I want HBA. waiting until we decide. apps have to change. EN: We don't have to change everything. Only those doing referalls, not already using URIs or something else. This seems like mostly p2p which run into this. run between clients with referrals. servers have FQDN, can do things. dont think we need to change that much. JB: The greatest use is 2 providers on wireless. Don't have a way to do this right now. Want to. If we start whacking APIs, then that means we can change transport layer. BC: Need to be careful forcing upper layers to change to get very basic multihoming. If you do, then you might as well make a large change. But, if you can avoid this for simple case, then have a deployable way forward. If this also cuts off alternative solutions, then big mistake. Andrew McGreggan(sp)(MG): Serious apps go to some effort to get things right. need to provide methods for unserious, old, broken apps to do things right as well. Tim Shepherd (TS): Any reaction from IPsec or SAAG on this? EN: More of a discussion on running IPsec on top of shim approach, but has not happened yet. Bill Sommerfeld (BS): Entire WG on multiaddress/multihoming for MobIKE. Useful to wave in that direction. TS: Helps people with broken networks. Give in plenary. BC: Line is empty. We want to spend 15-20m on summary discussion on design team output. BC: We now need to clear out open issues with design team. Everyone understood HBA's? I wonder if going to HBA solution would be viewed as complex by implementers. Jim? comment on complexity? is it something which implementers are going to find too complex? JB: I don't think so. my Q is, will it scale? By the time I build the key, for 10,000,000 google sessions...We build servers with that number per hour. But it would be easier with SCTP! MB: We have to make hash verification each time you re-home. assuming that not likely re-home all communications simultaneuously. If it happens, just have to hash. The goal is to provide better performance than PK for these cases. EN: Having thought about it, and after some discussion with Christian H the way we cope with performance, don't think its verification, think its state creation, dealing with lots of connections, thats an issue, say in drafts, have local policy to say when I am going to try and establish the state. What we haven't talked about, client sitting with one connection 'think its great idea to have state with google' and google says 'I don't think so' not in spec. Other end needs to deny and push back. I want to distinguish between that, and server not implementing v6. BC: Flow label or extenstion header? Wondering. I agree extension header is clean/simple design, except takes 8 bytes out of some packets but not all of them. IvB: Extension header is dangerous regardinge firewalls. And it is additional n*2 -n locators. If there is an additional header between ip and tcp a firewall may decide this is dangerous and block the packet. PS: There are at least two issues here. Use 8byte ext header, something current f/w impl don't support. So, want to use something like TLV. Other point is that some look for TCP/UDP header, might not want the ext headers. bitof a fine line. With regard to flow label or ext-header. don't have big opinion, saying if going to loose some bytes, doesn't matter if its 8 or 16 or 20 in my opinio. BC: We are not meant to do protocol design here. This no simple decision. TS: I am wondering if hash based address approach, seems to give little security but not much. can choose to give work factor of 1, attacker 2^59 or give them or take 2^72 to give them 2^91 (or another choice) and the constraints are to fit the hash into the space. don't want to make the /64 boundary rigid. somebody might want to be routing longer prefixes. so hash is even smaller. wondering if need to go to 2^32 work factor to make this secure enough, set the puzzle, might as well go ahead and do PK work. The high level question is, what are we trying to secure, and is it secure enough? BC: Threat mitigation. Everything is relative. PS: I am not sure if relevant or important in previous comment, I don't think we should be asking if somenbody wants to route behind 64 bits, or behind 64 and also wants to use MH solution. MB: Security of HBAs. The limit of security is 64 bits. It doesn't have to do with PK, if you need more security, you need more bits. This brings us back to apps and referalls, if we want to use routable ULIDs all we have is 64. If we want more than this, have to use ULIDs which are non-routables. This doesn't relate to HBAs CGA have same problem. BC: Key management in internet as whole is hard problem. EN: What threats, it's redirection attacks. Security need e2e crypto anyway, ssl or whatever. If you do that, e2e IPSEC, combine with whats going on underneath and get better protections? redirect to /dev/null. Just DoS. BC: I am trying to persuade Marcello there is a MiTM attack. He thinks I'm wrong. I hope I'm wrong. TS: Key mgt. Even Christian mentioned this, can use PK in ways which dont need mgt, purpose built keys, draft written a while ago. BC: But without the advantages of HBA. TS: Purpose built keys, guarantees person start talking to will be person finish talking to. Other examples check neighbour discovery IvB: Could someone mention that (IIRC) the design team meant HBA to be a good option for situations where additional strong crypto isn't appropriate. So it's not meant to be the pinnacle of strong security. Ingress Filtering Compatibility for IPv6 Multihomed Sites (Marcello) ==================================================================== Personal submission with Christian H and, Richard Draves and Marcello. draft-huitema-multi6-ingress-filtering-00.txt MB: Scenario description of 'legacy host' in the m-h site. Approaches: relax ingress filtering (remove it) OR some form of source routing posits some boundary domain that allows an exit selection based on the source address in the packet. MB: A degenerate case is a single site exit router (in which case why multi-home?) or the DMZ as a boundary zone IvB: Wouldn't it be possible to make sure all the legacy hosts only talk to one router? i think keeping legacy / new hosts apart would be relatively easy with vlans. Francis Dupont(FD): Tried this before. Not easy to setup. Based on an access list, so it isn't dynamic. Need to find something better. EN: Something we need. Concerned that full SAD is too much. Need to keep this as small as possible. If you are at home, and have two routers you don't control (e.g., one from ADSL, one from cable), need a solution. This means you have to push it into the host. MB: If you want to support legacy hosts, then changing the host isn't an alternative. BC: Giving a host a second prefix introduces failure cases. MB: You need to configure internal routing to get the packet to the correct exit router. KL: Problem you are trying to solve is simpler than the SAD terminology. Most hosts only have a single default router that they need to reach. It is the default router that gets the traffic to the correct exit router. MB: If you can change the host, the host can tunnel packets to the correct router. KL: Not much you can change at the host. The hosts next hop is a default router. Short of giving it a full routing table, there isn't much more you can give. EN: A host would need to know internal vs. external, which it doesn't know today. EN: Hosts today maintain multiple default routers. The routing in the host doesn't tend to check the source IP address in making the choice of the default router. BC: Need to list this as an in issue in the next revision. Address Selection in Multihomed Environments (MB) ================================================= draft-huitema-multi6-addr-selection-00.txt MB: This is a short presentation. MB: Address selection in MH env is the same basic problem. Depending on source addr, assuming some sort of ingress filter mechanism, when outage in one of the ISPs, depending on src addr, selected by host in MH site, packets fail. Host has to select src addr containing right address for filter but, if host wants to commnuicate after outage, it will use one, doesn't consider this. We need to change mechanism for selecting src addr, complement, in order to take this into account. MB: This draft tries to analyse mechanisms. The goal is not to make changes to external hosts. MB [slide possible approaches] MB: Two types of mechanism. Proactive: let them know which not to use eg deprecate addresses via RADV. Other failure modes. MB: However need to learn. eg routing information from BGP could be used to complement, need more fine grained. Based on proposal of a while ago. Other mechanism are reactive. Try one, if it fails, pick other until one works. MB: Question here is who will do the trials? The application, or the IP layer, or try all at once. open issues. EN: How to get src address back into packet. Split of conceptual address selection, because of API, done in two places, getaddr() and down in TCP. BC: This is a good moment to switch speakers.. Arifumi. Source Address Selection Policy Distribution for Multhoming (Arifumi Matsumoto) ===================================================================== draft-arifumi-multi6-sas-policy-dist-00.txt Arifumi Matsumoto (AM): Three drafts closely linked on source address selection policy. AM: These items may not be in scope of the WG, but we want to have comments about the approach. The longest-match algorithm won't solve two-prefix two provider problem. AM: If one provider is not fully connected (eg closed network) the wrong src address cannot return to internet. AM: Broadband users in JP, 1/2 fall into mix of global and closed network providers (ie have both potentially available to them) eg closed file share, TV streaming services using closed nets, so this is a real problem. AM: Our approach: distribute src address selection policy to endpoints. RFC3484 defines address selection process. The policy table specifies matches, and delivery is done through route advertizement. Wecan use client router to control route visibility. AM: If endnode can handle more than one route default, better to give them all. AM: Why use DHCP-PD instead of RIPng, OSPF? Information may be the same, but usage is different. AM: Using OSPF or IPRng would require changes to routing, SAS policy should be more stable. AM: RA or DHCP? each has good points. AM: Summary: propose method to distribute SAS policy to end nodes. methods provides failure avoidance, but not detection or recovery. AM: This method can be used soon. This is not entire MH solution but it is a neccessary part of many networks. PS: Coudl you get back to 'walled garden' slide. Why do you need policy? Wouldn't it go to longest prefix? Tony Hain (TH): I can conceive of scenarios which can be constructed to cause this. Scaling. in terms of protocols, scaling issues. Have Service Provder push to end devices, don't think it scales. RA from edge router possible, from service provider to every edge device I am not sure. AM: I dont see issue. TH: Break the problem in half. PS: Not sure we are able in all cases, to talk to all devices using these mechanisms. can't know using DHCP. BC: Since affects 3848, then should follow up on IPv6 WG, not here. DHCP solution would have to be done elsewhere as well. Ask on ML if we should follow up here, or in IPv6 WG. Next Steps for the WG (Kurtis) ============================== BC: One remaining agenda item until end of tape.. next steps See slides following agenda slides... KL: The chairs have been talking over with ADs since yesterday. We now have work done by the design team, and there has not many questions. Do we agree the way forward is the way proposed by DT? (noting missing people) BC: Jim Bound has left. I need to channel Jim. Earlier on, raised issue of SCTP approach. I think point is, not rejected SCTP, not in position whole internet should switch to SCTP. Not practical proposition. But we do have to remember what Jim said, make sure have to talk to SCTP people. We need to make sure what we do, way we do it, affects stack, means SCTP can take advantage of shim, rather than fighting. BC: We want a discussion before show of hands. IvB: So what's the question on the table? PS: I am not sure what's the way forward. I am not sure what's being asked of me here. I think there are missing peices, though we are going the right direction. could be useful. asking for more here, or whats the assumption? BC: We can show all the slides, and cycle back to the beginning to ask the questions. JL: Read them all,I want to see work continue. I can guess where going, not going to talk to that. I think design team did good work, and this is a viable way for problem space. EN: The way forward may be nebulous. Is the question that the WG recommends, IESG sees work in this area or something? BC: That's is why I think it is better to show slides. KL: (not in chairmode) The question is also, that we have the solution categories, and we said we would evaluate them as equals until some point, then limit solutions on the table. This is part of that discussion. KL: I am now assuming yes to last question. KL: We have come long way. We are at the end of milestones, and end of charter. All docs are either with IESG or close. KL: We need to produce a solution architecture document. KL: This is not explicit in charter, but can be interpreted as that. KL: The proposal from chairs is to complete it in multi6, then take on current documents as WG docs, but not publish as RFCs. Publish the solutions document, as informational RFC or kick over wall to some other WG. Then close multi6 down. KL: Re-charter before next IETF, before 2005, new WG in internet area. can either/or complete document, develop protocols, APIs, for solution. We'd need an Internet Area Director to agree... Margaret Wasserman (MW): 'already asked me the question yesterday and I said yes.' KL: Question to WG: Do we agree to charter new WG in internet area? Agree to close multi6 when work done? agree to need for solution or arch document. GH: Going to say yes yes and yes, but we are better off starting solution arch document now, not a lot of work. It needs to document relationship between thinking of design team and framework. BC: So do it here, then when have other WG throw to them GH: Start now KL: Yes that was the intention GH: I will volunteer to work with others. BC: Procedural question is if we leave the design team, or form a editorial team PS: I am curious what was justification to take design team as ed team. Is it a recognition issue? BC: Wouldnt ask on 00 draft, wait for 01 drafts. MW: I think I was listed as member, but I was more a fly on wall, read, little care if published as separate or one. I want to see published in some form. More than 6 months to standardize, want doc on justifications, goals. arch. IvB: Do you guys want us (the design team) to make the current docs publishable, or to go on developing them technically? MW: Yes. BC: Question, so is the direction the way we see things going forward? Meta Q is this is the right question? GH: IT is not in our interests to publish incomplete docs, solutions architecture, nail to wall. BC: These are work in progress drafts. Some parts justification. Solution needs finishing, justification shouldn't get lost. Rationale documents. PS: On Geoffs comment, solutions arch doc needed soon. IvB: Maybe it would make sense to have a non-dt editor create a rough draft out of the parts of thye current documents that make sense to publish now? KL: Now asking other questions. KL: Is this the right advice to give IESG? charter, internet area, close multi6, arch document PS: I am not 100% sure internet area is right place. MW: WG doesnt get to decide on areas but is important to call the question. IvB: Brian: do you mean now (soon) or in 6 or 12 months or so? Because I feel we should have some time to prepare splitting up between a new wg, stuff that should stay here (if any) and stuff that needs to go too tother existing wgs BC: I want charter by March IETF, before next IETF. We may discover when we do analysis, little bits don't fit in internet, need ops WG. PS: I am bit uncomfortable about saying we should close multi6. I don't think we have missing pieces. BC: It may be new work we don't know about to be done. AD Question. David Kessens (DK): I like to get opportunity to close my first WG [laughter]. I like to thank everyone. You have done a great job on difficult topic to work on. come to the point quick. longer than thought, ready for recharter, can continue in internet area BC: WG chairs glad too. BC: Do people agree we need solns arch document? BC: Do we agree need to charter new work, probably new WG, probably internet area [not 100%] [but many] BC: Do we need to charter new work? [yes] BC: Question about area, discussed over weeks, personally do not want 9 month discussion. BC: Middle Q rather silly one. WG finished, stops. We are really asking we're done? [tentative hum] BC: and haven't finished? [silence] IvB: Are there no angry draft authors anymore? BC: In good shape. now need to encourage design team to do 01 versions. and, 00 solutions. Geoff Volunteered. BC: I would personally leave design team in place. True we had bunch of proto solutions drafts. close to infinity. clearly design team has selected major options, excludes things on the thable. IvB: Re interim meeting where we took a whole day to deal with unhappy draft authors (my take). BC: Clear chosen direction, recommend IESG to charter work in that direction. people who feel strongly wrong direction, tell IESG, or write draft. BC: Last words from Area Director? BC: still some tidying up in march, may have to meet. will try to make one hour session. BC: we're done. [close] --------------010902080601010708060306-- From owner-multi6@ops.ietf.org Tue Nov 30 07:43:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13404 for ; Tue, 30 Nov 2004 07:43:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZ7LS-000Nzr-Qi for multi6-data@psg.com; Tue, 30 Nov 2004 12:43:02 +0000 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZ7LR-000Nzb-J8 for multi6@ops.ietf.org; Tue, 30 Nov 2004 12:43:02 +0000 Received: from d06nrmr1507.portsmouth.uk.ibm.com (d06nrmr1507.portsmouth.uk.ibm.com [9.149.38.233]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAUCh0pN354038 for ; Tue, 30 Nov 2004 12:43:00 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1507.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAUCh51a070790 for ; Tue, 30 Nov 2004 12:43:05 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iAUCgxJS007279 for ; Tue, 30 Nov 2004 12:43:00 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iAUCgxrH007254; Tue, 30 Nov 2004 12:42:59 GMT Received: from zurich.ibm.com (sig-9-145-133-194.de.ibm.com [9.145.133.194]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA08798; Tue, 30 Nov 2004 13:42:55 +0100 Message-ID: <41AC6AD4.1060009@zurich.ibm.com> Date: Tue, 30 Nov 2004 13:43:00 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Erik Nordmark CC: Iljitsch van Beijnum , "'multi6@ops.ietf.org' List" Subject: Re: Comments on draft-bagnulo-multi6dt-hba-00.txt References: <20041117204224.37676.qmail@web80605.mail.yahoo.com> <500477EC-3985-11D9-BFE4-000A95CD987A@muada.com> <419D429A.3060703@sun.com> <357E2B5E-3A1A-11D9-992B-000A95CD987A@muada.com> <419E3E94.8090002@sun.com> In-Reply-To: <419E3E94.8090002@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [catching up] Erik Nordmark wrote: > Iljitsch van Beijnum wrote: > >> I think it's possible to solve this. We've been talking about a bit >> that indicates (among other things) that rewriting is allowed. For a >> long time, I've been saying that we could use the prefix in the source >> address for this. So magic prefix = rewrite, regular prefix = don't >> rewrite. We can reserve some bits in the magic prefix that indicate >> the type of rewriting that's allowed. For instance, if the prefix is >> then we can encode permission to >> rewrite to one or more of 16 different prefixes. There is the slight >> problem of having all systems involved know which prefix corresponds >> to which bit of course, but this should be doable. > > > Such an approach would require there to be a source locator rewriting > router in the path, right? > If the above funny prefix isn't rewritten in the path the peer will not > be able to respond AFAIK. > > Since we want to allow incremental deployment of any multi6 technology, > such an approach would require that the host can find out > 1) whether there is a source locator rewriter out there > 2) whether the source locator rewriter is in the path to reach a > particular destination (for instance, the path to a destinations > within the site may or may not go through a rewriter) > > If the host needs to probe the network per destination locator to answer > #2, we might as well have the answer tell the host which is the > preferred source locator to use so that there is no actual rewriting > along the path. (Yes, there are some subtle differences should the path > change.) > > The above complexity combined with Geoff's observations that in real > networks today it is hard to define which is the "site border router" > which would do the rewriting, makes me personally think that locator > rewriting along the path might not be worth to complexity even in the > future. For me, encoding semantics in the address in any way is an architectural red alert. It always comes back to bite. With multipath routing and virtualized IP addressing common, I just don't see how to ensure consistent behaviour (i.e. I don't see how to make it one atom better than NAT). Brian From owner-multi6@ops.ietf.org Tue Nov 30 07:54:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14190 for ; Tue, 30 Nov 2004 07:54:49 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZ7WI-000PfF-CC for multi6-data@psg.com; Tue, 30 Nov 2004 12:54:14 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZ7WB-000PdV-7G for multi6@ops.ietf.org; Tue, 30 Nov 2004 12:54:07 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iAUCs6SZ252436 for ; Tue, 30 Nov 2004 12:54:06 GMT Received: from sihl.zurich.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAUCsCtC250140 for ; Tue, 30 Nov 2004 12:54:12 GMT Received: from zurich.ibm.com (sig-9-145-133-194.de.ibm.com [9.145.133.194]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA71560 for ; Tue, 30 Nov 2004 13:54:04 +0100 Message-ID: <41AC6D70.30204@zurich.ibm.com> Date: Tue, 30 Nov 2004 13:54:08 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: mumti6dt drafts as WG drafts? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In accordance with the consensus to proceed with the direction proposed by the design team, does anyone object to the next versions of the following drafts being formally adopted as WG drafts? This would mean they have names like draft-ietf-multi6-* Please let us know this week if you object, and why. Multihoming Level 3 Shim Approach (draft-nordmark-multi6dt-shim-00.txt) Hash Based Addresses (HBA) (draft-bagnulo-multi6dt-hba-00.txt) Functional decomposition of the M6 protocol (draft-bagnulo-multi6dt-functional-dec-00.txt) Failure Detection and Locator Selection in Multi6 (draft-arkko-multi6dt-failure-detection-00.txt) Multi6 Application Referral Issues (draft-nordmark-multi6dt-refer-00.txt) Brian multi6 co-chair From owner-multi6@ops.ietf.org Tue Nov 30 10:06:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25540 for ; Tue, 30 Nov 2004 10:06:33 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZ9Yj-00011f-4P for multi6-data@psg.com; Tue, 30 Nov 2004 15:04:53 +0000 Received: from [66.92.66.146] (helo=alva.home) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZ9YX-0000xZ-AR for multi6@ops.ietf.org; Tue, 30 Nov 2004 15:04:41 +0000 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1CZ9YJ-00077y-00; Tue, 30 Nov 2004 10:04:27 -0500 From: Tim Shepard To: Brian E Carpenter Cc: Multi6 Subject: Re: Draft multi6 minutes In-reply-to: Your message of Tue, 30 Nov 2004 13:38:10 +0100. <41AC69B2.6020009@zurich.ibm.com> Date: Tue, 30 Nov 2004 10:04:27 -0500 Message-Id: X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Tim Shepherd (TS): Any reaction from IPsec or SAAG on this? My name is spelled Shepard. > TS: I am wondering if hash based address approach, seems to give > little security but not much. can choose to give work factor of 1, > attacker 2^59 or give them or take 2^72 to give them 2^91 (or another > choice) and the constraints are to fit the hash into the space. don't > want to make the /64 boundary rigid. somebody might want to be routing > longer prefixes. so hash is even smaller. wondering if need to go to > 2^32 work factor to make this secure enough, set the puzzle, might as > well go ahead and do PK work. The high level question is, what are we > trying to secure, and is it secure enough? > I was trying to point out that the HBA scheme seems to allow you these three choices (if I understand it correctly): user work factor attacker work factor ---------------- -------------------- 1 2^59 2^16 2^75 2^32 2^91 and it's not clear that any of those are useful. If security is not needed, then perhaps we don't even need to use the HBA scheme. If security is needed, then perhaps this scheme isn't much better than using some public key cryptography. > TS: Key mgt. Even Christian mentioned this, can use PK in ways which > dont need mgt, purpose built keys, draft written a while ago. I do remember saying that, but: > TS: Purpose built keys, guarantees person start talking to will be > person finish talking to. Other examples check neighbour discovery I do not remember saying that. I thinks someone else got up and said that at the same mic I had used, and it might have been Eliot Lear. (But I'm not sure.) -Tim Shepard shep@alum.mit.edu From owner-multi6@ops.ietf.org Tue Nov 30 13:03:55 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14980 for ; Tue, 30 Nov 2004 13:03:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZCKH-000ByC-Vp for multi6-data@psg.com; Tue, 30 Nov 2004 18:02:09 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZCKE-000BxX-58 for multi6@ops.ietf.org; Tue, 30 Nov 2004 18:02:06 +0000 Received: from jurassic.eng.sun.com ([129.146.82.37]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAUI22un028477; Tue, 30 Nov 2004 11:02:03 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAUI21kZ582062; Tue, 30 Nov 2004 10:02:02 -0800 (PST) Message-ID: <41ACB5D5.7040902@sun.com> Date: Tue, 30 Nov 2004 10:03:01 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Shepard CC: Brian E Carpenter , Multi6 Subject: Re: Draft multi6 minutes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Shepard wrote: > I was trying to point out that the HBA scheme seems to allow you these > three choices (if I understand it correctly): > > user work factor attacker work factor > ---------------- -------------------- > 1 2^59 > 2^16 2^75 > 2^32 2^91 > > > and it's not clear that any of those are useful. Because? Note that in any case (independent of the sec parameter) the peer's verification cost is constant. Thus what you call "user work factor" is the work factor for creating an HBA set of addresses. > If security is not needed, then perhaps we don't even need to use the > HBA scheme. If security is needed, then perhaps this scheme isn't > much better than using some public key cryptography. We know that security is needed. full stop. The question, given that we assume that when the payload requires security there will be some e2e payload security (ipsec, tls, ssh), is how hard we need to make it for 1) off path attackers to redirect the traffic (which for the e2e secure payload would have the effect of a DoS; packets will not be delivered to the peer) 2) on path attackets to redirect the traffic (which for the e2e secure payload would have the effect of a DoS) With HBA we can get the work factor for an on-path attacker to be 2^59 higher than the work factor to construct the HBA set of addresses. Given that an on-path attacker might be able to cause packets not to be delivered using other means (after all it is on the path so it might be able to perform ARP/ND spoofing, overload the local link, cut the cable, or might be sitting inside a router or switch). For off-path attackers we can make things arbitrarely more hard to guess by just using large random nonces (in addition to the HBA/CBA addresses). So I'm not concerned about dropping the number of hash bits further to be able to support longer than /64 subnet prefixes in the future; cutting 16 bits seems to be ok. Erik From owner-multi6@ops.ietf.org Tue Nov 30 18:32:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00301 for ; Tue, 30 Nov 2004 18:32:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZHSe-000Epq-GW for multi6-data@psg.com; Tue, 30 Nov 2004 23:31:08 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CZHSd-000EpZ-Gw for multi6@ops.ietf.org; Tue, 30 Nov 2004 23:31:07 +0000 Received: from [IPv6:::1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id iAUNVCQx079039; Wed, 1 Dec 2004 00:31:12 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <44BEF211-3F73-11D9-B14D-000A95928574@kurtis.pp.se> References: <44BEF211-3F73-11D9-B14D-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Mini WGLC draft-ietf-multi6-multihoming-threats-02.txt Date: Wed, 1 Dec 2004 00:31:04 +0100 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 26-nov-04, at 7:20, Kurt Erik Lindqvist wrote: > hereby we start a "mini" Working Group Last Call for the threats > document. This concludes on December the 1th 17.00 CET. The link doesn't work. What exactly is the purpose of this last call? Iljitsch From owner-multi6@ops.ietf.org Tue Nov 30 21:12:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13258 for ; Tue, 30 Nov 2004 21:12:32 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CZJxb-000F4H-Pr for multi6-data@psg.com; Wed, 01 Dec 2004 02:11:15 +0000 Received: from [66.163.168.180] (helo=smtp801.mail.sc5.yahoo.com) by psg.com with smtp (Exim 4.43 (FreeBSD)) id 1CZJxa-000F44-Tt for multi6@ops.ietf.org; Wed, 01 Dec 2004 02:11:15 +0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp801.mail.sc5.yahoo.com with SMTP; 1 Dec 2004 02:11:14 -0000 Message-ID: <010901c4d74b$02984870$861167c0@adithya> From: "Mohan Parthasarathy" To: "Brian E Carpenter" , "Multi6" References: <41AC6D70.30204@zurich.ibm.com> Subject: Re: mumti6dt drafts as WG drafts? Date: Tue, 30 Nov 2004 18:11:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.1 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian, So, the solution architecture document will come later on based on the WG documents i guess. What is the rationale behind having it as separate documents still ? Having read some of them, i felt that it might be good to have some of them at least merged to understand the solution better. For example, the first three below (shim, hba and func) can be merged. -mohan > In accordance with the consensus to proceed with the direction > proposed by the design team, does anyone object to the next versions > of the following drafts being formally adopted as WG drafts? > This would mean they have names like draft-ietf-multi6-* > > Please let us know this week if you object, and why. > > Multihoming Level 3 Shim Approach > (draft-nordmark-multi6dt-shim-00.txt) > Hash Based Addresses (HBA) > (draft-bagnulo-multi6dt-hba-00.txt) > Functional decomposition of the M6 protocol > (draft-bagnulo-multi6dt-functional-dec-00.txt) > Failure Detection and Locator Selection in Multi6 > (draft-arkko-multi6dt-failure-detection-00.txt) > Multi6 Application Referral Issues > (draft-nordmark-multi6dt-refer-00.txt) > > > Brian > multi6 co-chair >