From owner-multi6@ops.ietf.org Sun Feb 1 16:08: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 QAA11942 for ; Sun, 1 Feb 2004 16:08:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AnOje-0005BJ-FW for multi6-data@psg.com; Sun, 01 Feb 2004 21:02:30 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnOjM-00059h-V5 for multi6@ops.ietf.org; Sun, 01 Feb 2004 21:02:13 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i11L2lGe046745 for ; Sun, 1 Feb 2004 22:02:47 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <4013E7E9.12F9D87A@zurich.ibm.com> References: <4013E7E9.12F9D87A@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: HIP draft Date: Sun, 1 Feb 2004 22:02:13 +0100 To: Multi6 List X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 25-jan-04, at 16:59, Brian E Carpenter wrote: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-00.txt Ok, I'm missing two things here: 1. Failover. The draft says the wg should come up with this. Ok. 2. What mechanism makes it possible for unmodified ULPs to set up connections to HIP-capable destinations? I would expect either the application to be modified so it knows to ask for the HIP DNS RR, or there must be some shady resolver hacks that trick the app and TCP (or other ULPs) so they think they're dealing with a regular IPv6 address but in effect they're using HIP identifiers and the associated IP addresses are recovered at the HIP layer. And would it be possible to implement HIP in middleboxes so that unmodified hosts can talk to HIP boxes? From owner-multi6@ops.ietf.org Mon Feb 2 04:39: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 EAA29211 for ; Mon, 2 Feb 2004 04:39:03 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AnaP3-000Bs2-UT for multi6-data@psg.com; Mon, 02 Feb 2004 09:30:01 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnaOl-000Bhv-On for multi6@ops.ietf.org; Mon, 02 Feb 2004 09:29:43 +0000 Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i129TSRT059822; Mon, 2 Feb 2004 09:29:28 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i129TQbL150078; Mon, 2 Feb 2004 10:29:27 +0100 Received: from zurich.ibm.com (sig-9-145-171-24.de.ibm.com [9.145.171.24]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA49000; Mon, 2 Feb 2004 10:29:22 +0100 Message-ID: <401E189D.B9C4130F@zurich.ibm.com> Date: Mon, 02 Feb 2004 10:30:05 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: multi6@ops.ietf.org CC: dcrocker@brandenburg.com Subject: Re: Evaluating multiaddressing proposals References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave Crocker wrote as below, but it bounced due to a list subscription issue. I see these comments as input to Eliot's draft. Brian - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM *** I will be on vacation February 3-25, 2004 *** > > Folks, > > I put together a list of categories that seem interesting for > evaluating different multiaddressing proposals. > > No doubt the list is terrible. That's ok. Think of what follows as an > excuse for everyone to fix it: > > Features > Multiaddressing > Multihoming, mobility, both > Infrastructure > None, sometimes, always > IP version(s) > Identifier > Registered vs. ephemeral > Rendezvous > Creating the association > After service interruption > > Overhead > Per payload packet > Control protocol > Transport startup delay > Scaling impact > Constant per association, vs. deferred > Administration > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Feb 2 06:40: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 GAA04930 for ; Mon, 2 Feb 2004 06:40:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AncMZ-0000iT-EN for multi6-data@psg.com; Mon, 02 Feb 2004 11:35:35 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AncM1-0000eN-DD for multi6@ops.ietf.org; Mon, 02 Feb 2004 11:35:01 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id 3BA4D212C31; Mon, 2 Feb 2004 13:34:59 +0200 (EET) Message-ID: <401E34E3.9090503@nomadiclab.com> Date: Mon, 02 Feb 2004 13:30:43 +0200 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20040114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: New multi6 draft: WIMP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Marcelo, Thanks for reading through our draft. marcelo bagnulo wrote: >Hi Jukka, > >I am trying to understand your draft, and i have some questions about some >points that you perhaps can help me with. > > > You have pointed out several important issues that need clarification. I already apologize my long email. >1. About the Context establishement exchange (section 3.4) >I fail to see what you mean when you state that the responder remains >stateless. >I mean, the responder has to generate the temrporary hash chain. This hash >chain has to be specific to this particular host pair context, right? (this >is what it is stated in section 3.3 about generating reverse hash chains) >So, this means that when the responder receives an INIT message it has to >generate a new hash chain (or reserve a pre computed hash chain for this >initiated context establishement), would this be correct?. If so, the >responder has to at least store a state that is that this hash chain is >reserved and cannot be used for a future INIT, right? > > > The responder has one long term secret that is common for different contexts. Basically, the responder remains stateless, and does not store the temporary hash chain values. It is still able to safely recompute the hash chain after receiving the CCR message. Appendix A describes an example how the hash chain can be generated. The responder generates its hash chain using a long term local secret, IDs and a challenge (i.e. a nonce). The initiator's ID is a hash of a nonce. The secret, in turn, is never reavealed to the peers. The responder protects the CC message with its newly generated hash chain value. It does not create a state. It is important to notice that the state machine plays an important role. If a responder already has a state for a specific ID pair, it does not reply with CC message. In other words, an attacker cannot pump out the hash chain values of other ID pairs. The responder cannot generate similar hash chain for a new ID pair during the lifetime of the authentic ID pair. The attacker is not able to use the same ID as the authentic initiator is currently using. In addition, it does not matter if the attacker creates a context with the responder, using the authentic inititor's ID and challenge, after the authentic initiator has destroyed its context with the responder. Once the authentic initiator creates a new context-pair with the responder, it generates a new random ID for itself, and therefore also the hash chain is changed. Once the responder receives the CCR message, it is able to recompute the hash chain using the long term secret, IDs and the challenge. The HMACs bind the earlier exchange messages (INIT and CC) together and quarantee that the hash chain is bound to the requested ID pair. [Do not hesitate to ask more questions about this, if I my answer was not clear enough.] >If so, wouldn't this imply that an attacker sending INIT messages could >force the responder to gnerate hash chains, sort of DoS attack? I ask this >because, if i understand correctly, this is what you are trying to prevent, >but i just fail to see how you actually prevent it :-( > > > A short hash chain generation is a quite fast operation compared to signature calculation. (If I remember correct, e.g., computing SHA1 five times over a 160bit string takes under 0.5 ms with 2Ghz pentium.) The operation is efficient and makes it more diffucult for an attacker to cause a DoS situation. >The you state that: >"The initiator replies to the CC message with a context check reply > message (CCR) and proves that it was reachable at the specific > location by disclosing the anchor value." > >I don't really agree with this... I think that the initiator can prove that >he is reachable by inlcuding the HMAC_CC value in the CCR message, and not >by disclosing the anchor value. > >I mean, the anchor value would prove that the initiator is the same that the >one who sent the INIT message, but if the RESPONDER is stateless, the >responder has no information about the INIT message received, . >I guess that the important is to inlude the HMAC_CC and since the responder >has the H0_R it can verify that the HMAC__CC was generated by himself (the >responder) > >(i am probably missing something here....) > > > Excellent analysis! Thanks! However, as I pointed out above, the responder is able to recompute its hash chain without creating a state. A short description: Once Responder receives INIT message it protects the received values , including HMAC_INIT, with HMAC_CC. The responder uses the temporary hash chain value as a key in HMAC_CC. Finally, the responder receives CCR message and recomputes the hash chain. It uses the long term secret to recompute the chain. The responder verifies HMAC_CC to see that it already has reveived INIT message with a specific ID pair. The initiator, in turn, discloses its anchor value to prove that is was reachable in the specific location. In other words, the HMAC_INIT in INIT message, and the anchor_I value in the CCR message bind the messages together and implement a kind of return-routability test. >after you mention that: > >"The anchor value of the initiator hash chain > binds the INIT and CCR messages together, and in this way the > responder is able to verify that messages are coming from the same > host. " > >again if the responder is stateless, he has no knowledge about the INIT >message by the time he receives the CCR message, so what does it means that >it can verify that both messages come from the same host? > > See above. >2. Re-addressing exchange > >First, a simple question: the re-addressing exchange can be initiated by the >responder? (i think so, but i couldn't find it stated clearly in the draft) > > > Yes, the responder of the context establishment exchange is an initiator if it starts the re-addressing exchange. The initiator of an context establishment or re-addressing exchange is called the initiator. See below: Section 7: "The initiator of the context establishment exchange is called the initiator. Once the host-pair contexts are established, this initial distinction is lost. The sender of the REA message is called the initiator of the re-addressing exchange. In a case of state loss, the sender of the RESYNCH message becomes a responder." >Second, i am really having a hard time to understand how the key masks and >the key pieces work and how you can verify which of the locators are >reachable. I guess that part of the reasons is because my own comprehension >problems, but the fact that part of the explanation is contained in section >3.5 and that the rest is contained in section 6.12, where the packet format >is explained, is not helping me much :-( >Could you provide me a simpel example, with for instance a REA message >conatining 3 new locators, and detail which would be the AC1, AC2 and AC3 >messages, how they are generated and which would be the ACR message (and its >generation)? >Sorry to ask this, but i am really stuck here... > > > You are right. That part needs more clarification in the draft. Thanks for commenting that. I have included a short example: REA: IP header: Addr-R, Addr-I1 WIMP: IDs, Addr-I1, Addr-I2, Addr-I3, H1(I), H0_new(I), challenge, HMAC Secret splitting: I refer here the "2nd edition of Applied Cryptography by Bruce Schneier", page 70. Hash chain value H1(R) = 160 bit string A = 160 bit random string B = 160 bit random string Responder computes: H1(R) xor A xor B = C, where A, B and C are final key pieces. Initiator computes: C xor B xor A = H1(R), where H1(R) is the combined key. AC1: IP header: Addr-I1, Addr-R WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=001, Key_piece=A AC2: IP header: Addr-I2, Addr-R WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=010, Key_piece=B AC1: IP header: Addr-I3, Addr-R WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=100, Key_piece=C If the initiator receives all of the keys. ACR: IP header: Addr-R, Addr-I1 WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=111, combined_key=H1(R), H2(I) If the initiator receives only AC2 and AC3. ACR: IP header: Addr-R, Addr-I2 WIMP: IDs, AC_ID=1, Key_count=2, Key_mask=110, combined_key=(B xor C), H2(I) >3. After that a REA message is received, and some of the locators are >verified, which locator is used for following packets? >Do you use the address contained in the source address field of last >received packets? > > > The draft does not define an address selection policy. I think the WG should define a separate draft that defines the address selection policy for all different multi6 protocols. However, your prososal sounds good for default address selection. I hope my comments clarify the draft and give answers to your questions. Br, Jukka >Thanks, marcelo > > > > > > > >>-----Mensaje original----- >>De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En >>nombre de Jukka Ylitalo >>Enviado el: jueves, 29 de enero de 2004 10:09 >>Para: multi6@ops.ietf.org >>Asunto: New multi6 draft: WIMP >> >> >>(uh oh, the previous email was incorrectly aligned) >> >>Hi, >> >>We have submitted a new multi6 draft to I-D directory. The draft >>defines a Weak Identifier Multihoming Protocol (WIMP), and we >>wrote it in order to see how opportunistic/weak authentication >>methods could >>be used to solve the multi6 problem. >> >>WIMP is one of those protocols that introduce a new protocol layer >>between IP and upper layers. Our approach uses some very basic >>cryptograpahic funtions (reverse hash chains and secret splitting) in >>order to have light and (hopefully) simple solution. The protocol >>is not buller broof from security point of view, however, it intends >>to be secure enough and easy to implement. >> >>We hope it will stimulate discussion on various solution to >>multi6 problem. >> >>See more details from the draft itself, available in: >> >>http://www.hip4inter.net/multi6/draft-ylitalo-multi6-wimp-00.txt >> >>Thanks, Jukka Ylitalo >> >> >> >> >> > > > > > From owner-multi6@ops.ietf.org Mon Feb 2 09:02: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 JAA13267 for ; Mon, 2 Feb 2004 09:02:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AneaS-0003D0-CK for multi6-data@psg.com; Mon, 02 Feb 2004 13:58:04 +0000 Received: from [130.104.229.109] (helo=info.ucl.ac.be) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AneaC-0003An-6b for multi6@ops.ietf.org; Mon, 02 Feb 2004 13:57:48 +0000 Received: from descartes.info.ucl.ac.be (descartes [130.104.229.82]) by info.ucl.ac.be (8.12.10/8.12.8) with ESMTP id i12Dvg4H009590; Mon, 2 Feb 2004 14:57:42 +0100 (MET) Subject: RE: Host Centric Multi-Homing From: Cedric de Launois To: mbagnulo@ing.uc3m.es Cc: multi6@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1075730296.26686.6.camel@descartes> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 02 Feb 2004 14:58:16 +0100 Content-Transfer-Encoding: 7bit X-INGI-MailScanner-Information: Please contact the ISP for more information X-INGI-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I have already updated the draft with some of your comments, you can check > it at the same location: > > http://www.it.uc3m.es/marcelo/draft-huitema-multi6-hosts-02.txt Thanks for the changes. Here are some other comments. Yes, I like your draft ;) 6.4 Solution 4: Host based exit path selection + source address based routing "Required modifications: implementation of the path discovery mechanism" What is exactly the path discovery mechanism ? Is it the path failure detection described 5.1.2.2.2 ? You should perhaps refer to the appropriate section where the mechanism is described. 7. Proposed solution 7.1 Multihoming solutions for small sites I don't see clearly which solution (from the ones you describe in section 6) you recommend. In fact, you are recommending 2 (optimized) solutions for small sites : - Host based exit path selection + site exit discovery - Host based exit path selection + source address based routing Some mechanisms you discuss in section 7.1 apply to the first solution while others apply to the second. This is a little bit confusing, and it is difficult to have a coherent view of each solution you propose. You should perhaps present the mechanisms separately for each solution. BTW, it would be interested to know which solution (based on source routing or based on site exit discovery) is preferred by you and by people out of this wg. There is an important design choice to make here. 7.2. Multihoming solution for medium sites Which solution from section 6 are you recommending ?? >From what you described, it seems that it is solution 5 (host based exit path selection + site exit discovery). But this is contradicting since you said solution 5 is only suitable for small sites. I also deduce you are not recommending source based routing. Maybe you should make this point more explicit. ------------------------------- Purely editorial 1. Introduction "There are two basic forms of multihoming, multiple interface [...]" s/interface/interfaces/ 3.2 Source address selection "the normal procedure is to select the address" s/address/destination address/ "[...] and finally selects a source address" s/selects/select/ "When the hosts has multiple addresses" s/hosts/host/ 3.3 The site exit issue The example is more clear. Thanks. "ISP C, similarly, sees a packet whose match the prefix assigned by that ISP to Y." s/whose match/whose source address does not match/ 4.1 Relaxing the source address checks "the provider has to be believe that the site will transmit the right prefixes" s/believe/believed/ ?? 5.1.2 Internally initiated communications "to let the intra-site routing system to perform both tasks." s/to perform/perform/ "The second possibility presented is to let the host to do both tasks" s/to do/do/ 5.1.2.1 Exit path selection by the intra-site routing system "to let the intra-site routing system to perform" s/to perform/perform/ "a single ehternet" s/ehternet/ethernet/ 5.1.2.2 Host based exit path selection "a mechanism that to the host force the routing of packets" ? 7.1.2.1.1 Site exit redirection ICMP message "Site Exit Address: An IP address of the preferred exit router touse" "touse" ? 7.1.2.2.2.3 Presering established communications s/Presering/Preserving/ 7.1.2.2.1 Direct link failures "be used as source address at anay given time" s/anay/any/ 7.2.1 Reaction to topology changes "Each entry contain for each Destination Address" s/contain/contains/ "If it does exists, the host obtains the source address [...]" s/exists/exist/ 7.3 Multihoming solution for big sites "This mechanism is simpler becuase no ingress filtering" s/becuase/because/ Cedric From owner-multi6@ops.ietf.org Mon Feb 2 11: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 LAA20892 for ; Mon, 2 Feb 2004 11:17:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Anghp-000Lyq-Qg for multi6-data@psg.com; Mon, 02 Feb 2004 16:13:49 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AnghV-000Lw2-5N for multi6@ops.ietf.org; Mon, 02 Feb 2004 16:13:29 +0000 Received: (qmail 66858 invoked from network); 2 Feb 2004 16:26:32 -0000 Received: from h219-110-032-253.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.253) by necom830.hpcl.titech.ac.jp with SMTP; 2 Feb 2004 16:26:32 -0000 Message-ID: <401E777F.8070902@necom830.hpcl.titech.ac.jp> Date: Tue, 03 Feb 2004 01:14:55 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: multi6@ops.ietf.org, dcrocker@brandenburg.com Subject: Re: Evaluating multiaddressing proposals References: <401E189D.B9C4130F@zurich.ibm.com> In-Reply-To: <401E189D.B9C4130F@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,RCVD_IN_SORBS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > Dave Crocker wrote as below, but it bounced due to a list subscription issue. > > I see these comments as input to Eliot's draft. The only thing I should say is that there is absolutely no evaluation nor evalutation criteria. Masataka Ohta From owner-multi6@ops.ietf.org Mon Feb 2 11:33: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 LAA21671 for ; Mon, 2 Feb 2004 11:33:42 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AngzX-000OHf-5m for multi6-data@psg.com; Mon, 02 Feb 2004 16:32:07 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Angz8-000OB3-1j for multi6@ops.ietf.org; Mon, 02 Feb 2004 16:31:42 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 22AF7907E; Mon, 2 Feb 2004 17:31:41 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 033169027; Mon, 2 Feb 2004 17:31:41 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Jukka Ylitalo" , Subject: RE: New multi6 draft: WIMP Date: Mon, 2 Feb 2004 17:30:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <401E34E3.9090503@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Jukka, thanks for this detailed explanation, more below... [...] > [Do not hesitate to ask more questions about this, if I my answer was > not clear enough.] I think i understand that part, i see now why it is stateless. > > >If so, wouldn't this imply that an attacker sending INIT messages could > >force the responder to gnerate hash chains, sort of DoS attack? [...] > A short hash chain generation is a quite fast operation compared to > signature calculation. why do you compare it with the processing required to perform a signature calculation? I mean if i were an attacker, i would do the following: The goal of the DoS attack is to consume the processing power by soliciting the victim to produce (useless) hash chains. So, the attacker generates a random number as an ID(I) and also a challenge(I) and then simply generate a random string which length is the same than the expected length of the HMAC_INIT. I think the attacker can do this because the victim (i.e. the responder) cannot verify the HMAC_INIT since it doesn't know H0(I). The attacker can generate as much INIT messages as he wants, he just has to add 1 to the ID(I) values (in order to avoid the duplication of IDs) So, the attacker can force the responder to generate hash chains based on the ID(I). As far as i know (note that i am no security expert nor anything close to this), the idea to avoid DoS attacks is to impose more workload to the initiator to the responder. Now, in this case, in order to generate INIT messages the initiator just has to perform an addition operation (adding 1 to the ID(I)) However, the responder has to generate a hash chain. I don't have computation time values but i would say that the responder task is more time consuming than the attacker task. Am i missing something? [...] > >The you state that: > >"The initiator replies to the CC message with a context check reply > > message (CCR) and proves that it was reachable at the specific > > location by disclosing the anchor value." [...] > Excellent analysis! Thanks! However, as I pointed out above, the responder > is able to recompute its hash chain without creating a state. > i understand the stateless part, buti a have a minor observation. see below... > A short description: > > Once Responder receives INIT message it protects the received values, > including HMAC_INIT, with HMAC_CC. The responder uses the temporary hash > chain value as a key in HMAC_CC. Finally, the responder receives CCR message > and recomputes the hash chain. It uses the long term secret to recompute > the chain. > The responder verifies HMAC_CC to see that it already has reveived INIT > message with a specific ID pair. The initiator, in turn, discloses its > anchor value to prove that is was reachable in the specific location. Well, this is not really a big issue, but i think that the proof that the initiator is reachable at the specific location is provided by the fact that the initiator has received the HMAC_CC value (and he is proving it because he is including it in the CCR packet) Disclosing the anchor value does not prove that he is reachable at the specific location. Displaying the anchor value proves that the initiator has generated both the INIT message and the CCR message. Now, the responder is stateless and thanks to the anchor values it can verify that the same initiator has sent both the INIT and the CCR message. But, as i said, this is really minor. [...] > >2. Re-addressing exchange > > > >First, a simple question: the re-addressing exchange can be > initiated by the > >responder? (i think so, but i couldn't find it stated clearly in > the draft) > > > > > > > Yes, the responder of the context establishment exchange is an initiator > if it starts the re-addressing exchange. The initiator of an context > establishment or re-addressing exchange is called the initiator. > See below: > > Section 7: > "The initiator of the context establishment exchange is called the > initiator. Once the host-pair contexts are established, this initial > distinction is lost. The sender of the REA message is called the > initiator of the re-addressing exchange. In a case of state loss, the > sender of the RESYNCH message becomes a responder." > > >Second, i am really having a hard time to understand how the key > masks and > >the key pieces work and how you can verify which of the locators are > >reachable. I guess that part of the reasons is because my own > comprehension > >problems, but the fact that part of the explanation is contained > in section > >3.5 and that the rest is contained in section 6.12, where the > packet format > >is explained, is not helping me much :-( > >Could you provide me a simpel example, with for instance a REA message > >conatining 3 new locators, and detail which would be the AC1, AC2 and AC3 > >messages, how they are generated and which would be the ACR > message (and its > >generation)? > >Sorry to ask this, but i am really stuck here... > > > > > > > You are right. That part needs more clarification in the draft. Thanks for > commenting that. I have included a short example: > > REA: > > IP header: Addr-R, Addr-I1 > WIMP: IDs, Addr-I1, Addr-I2, Addr-I3, H1(I), H0_new(I), challenge, HMAC > > Secret splitting: > > I refer here the "2nd edition of Applied Cryptography by Bruce > Schneier", page 70. > > Hash chain value H1(R) = 160 bit string > A = 160 bit random string > B = 160 bit random string > > Responder computes: H1(R) xor A xor B = C, > where A, B and C are final key pieces. > > Initiator computes: C xor B xor A = H1(R), > where H1(R) is the combined key. > > AC1: > > IP header: Addr-I1, Addr-R > WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=001, Key_piece=A > > AC2: > > IP header: Addr-I2, Addr-R > WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=010, Key_piece=B > > AC1: > > IP header: Addr-I3, Addr-R > WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=100, Key_piece=C > > If the initiator receives all of the keys. ACR: > > IP header: Addr-R, Addr-I1 > WIMP: IDs, AC_ID=1, Key_count=3, Key_mask=111, combined_key=H1(R), H2(I) > > If the initiator receives only AC2 and AC3. ACR: > > IP header: Addr-R, Addr-I2 > WIMP: IDs, AC_ID=1, Key_count=2, Key_mask=110, > combined_key=(B xor C), H2(I) > perfect, thanks IMHO you should include this example in the draft, it really makes things so much clearer (at least for me) > >3. After that a REA message is received, and some of the locators are > >verified, which locator is used for following packets? > >Do you use the address contained in the source address field of last > >received packets? > > > > > > > The draft does not define an address selection policy. I think > the WG should define a separate draft that defines the address selection > policy > for all different multi6 protocols. However, your prososal > sounds good for > default address selection. > > I hope my comments clarify the draft and give answers to your questions. > Yes, thanks. I think that WIMP may be susceptible to the following hijacking attack. Let me know if i am wrong. Attacker A with address IPA Server S with IP=IPS and FQDN=www.server.com Victim V with IP=IPV and FQDN=FQDNV The attacker will try to impersonate S. Now if you consider that S is server, usually is V who contacts (think for instance a newspaper web server where V reads the news every morning). So the attacker will try to establish some malicious state in V so that when V tries to send packets to S, he will actually send them to A. The attacker calculates ID(S)=Hash(www.server.com) and ID(V)=Hash(FQDNV) The attacker sends a INIT value with ID(I)=ID(S) and ID(R)=ID(V) using its own IP address Now the attacker has generated this state in V. It can preserve this state by simply sending periodical pings or just UDP packets to unused ports (since WIMP is below UDP, this would be enough to preserve the state at the wimp layer, right?) Eventually, V will try to contact S to read the news. At this point, V will calculate Hash(www.server.com) Considering that V already has a state with ID(R)=Hash(www.server.com) and according to the rule 2 described in section 4.1, V will simply use the available state in the wimp layer. This means that when V tries to communicate with S, V will be actually sending packets to the IP address associated to this state, that is IPA, so V will send packets to the attacker. So the attacker will impersonate the server. Would this attack work? Thanks, marcelo > Br, Jukka > > >Thanks, marcelo > > > > > > > > > > > > > > > > > >>-----Mensaje original----- > >>De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > >>nombre de Jukka Ylitalo > >>Enviado el: jueves, 29 de enero de 2004 10:09 > >>Para: multi6@ops.ietf.org > >>Asunto: New multi6 draft: WIMP > >> > >> > >>(uh oh, the previous email was incorrectly aligned) > >> > >>Hi, > >> > >>We have submitted a new multi6 draft to I-D directory. The draft > >>defines a Weak Identifier Multihoming Protocol (WIMP), and we > >>wrote it in order to see how opportunistic/weak authentication > >>methods could > >>be used to solve the multi6 problem. > >> > >>WIMP is one of those protocols that introduce a new protocol layer > >>between IP and upper layers. Our approach uses some very basic > >>cryptograpahic funtions (reverse hash chains and secret splitting) in > >>order to have light and (hopefully) simple solution. The protocol > >>is not buller broof from security point of view, however, it intends > >>to be secure enough and easy to implement. > >> > >>We hope it will stimulate discussion on various solution to > >>multi6 problem. > >> > >>See more details from the draft itself, available in: > >> > >>http://www.hip4inter.net/multi6/draft-ylitalo-multi6-wimp-00.txt > >> > >>Thanks, Jukka Ylitalo > >> > >> > >> > >> > >> > > > > > > > > > > > From owner-multi6@ops.ietf.org Mon Feb 2 11:55: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 LAA22462 for ; Mon, 2 Feb 2004 11:55:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AnhKm-0001qO-IW for multi6-data@psg.com; Mon, 02 Feb 2004 16:54:04 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnhId-0001DA-DU for multi6@ops.ietf.org; Mon, 02 Feb 2004 16:51:51 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 624B97CCC; Mon, 2 Feb 2004 17:51:50 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp03.uc3m.es (Postfix) with SMTP id 4E15F7CBB; Mon, 2 Feb 2004 17:51:50 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , "Multi6 List" Subject: RE: HIP draft Date: Mon, 2 Feb 2004 17:50:32 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > 2. What mechanism makes it possible for unmodified ULPs to set up > connections to HIP-capable destinations? I would expect either the > application to be modified so it knows to ask for the HIP DNS RR, or > there must be some shady resolver hacks that trick the app and TCP (or > other ULPs) so they think they're dealing with a regular IPv6 address > but in effect they're using HIP identifiers and the associated IP > addresses are recovered at the HIP layer. My understanding is that the last option is proposed. > > And would it be possible to implement HIP in middleboxes so that > unmodified hosts can talk to HIP boxes? > I think so. But the doc states that this will be detailed in another document. However, i haven't been able to find it as a item neither in the pwg carter nor in the prg charter. Shouldn't this be explicitely included? Regards, marcelo From owner-multi6@ops.ietf.org Mon Feb 2 12:54: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 MAA26379 for ; Mon, 2 Feb 2004 12:54:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AniFJ-0009c5-B6 for multi6-data@psg.com; Mon, 02 Feb 2004 17:52:29 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AniF4-0009at-7j for multi6@ops.ietf.org; Mon, 02 Feb 2004 17:52:14 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6FE6E90CB; Mon, 2 Feb 2004 18:52:13 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 59B2490C8; Mon, 2 Feb 2004 18:52:13 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Cedric de Launois" Cc: Subject: RE: Host Centric Multi-Homing Date: Mon, 2 Feb 2004 18:50:55 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1075730296.26686.6.camel@descartes> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Hi Cedric, thank you very much for your feedback and your interest > > 6.4 Solution 4: Host based exit path selection + source address based > routing > > "Required modifications: implementation of the path discovery > mechanism" > > What is exactly the path discovery mechanism ? Is it the path failure > detection described 5.1.2.2.2 ? Yes > You should perhaps refer to the > appropriate section where the mechanism is described. > I will do that > 7. Proposed solution > 7.1 Multihoming solutions for small sites > > I don't see clearly which solution (from the ones you describe in > section 6) you recommend. Yes, this is not clear the proposed solution is a combination of some of the solutions > In fact, you are recommending 2 (optimized) solutions for small sites : > > - Host based exit path selection + site exit discovery > - Host based exit path selection + source address based routing > This is correct. the basic solution is the one based in source address routing and the site exit discovery is an optimization > Some mechanisms you discuss in section 7.1 apply to the first solution > while others apply to the second. This is a little bit confusing, and it > is difficult to have a coherent view of each solution you propose. > > You should perhaps present the mechanisms separately for each solution. > Yes, it is confusing, i agree the point is that section 6 is an abstract analysis of the options, while section 7 is an attempt of solution. The optimal solution is a combination of multiple mecahnisms, as you have already pointed out. But i will try to improve the readability of the doc. > BTW, it would be interested to know which solution (based on source > routing or based on site exit discovery) is preferred by you and by > people out of this wg. There is an important design choice to make here. > IMHO the adoption of a multihomed solution can be proposed as a three step process. The different steps require different amount of modifications 1- the first step would be source address based routing restricted to the site exit routers (a mesh of tunnels between the site exit routers). This si simple, and required no upgrading (neither on hosts nor in routers) This first step overcomes the site exit issue and allows regular (non upgraded) IPv6 hosts to work propoerly in a multihomed site. The problem here is that the routing of the packets will be suboptimal 2- the second step is to modify the hosts to make the site exit router discovery. If so, upgraded hosts would obtain an optimized performance, since they would directly send the packets to the appropriate exitr router. This way we achieve optimal (internal) routing. The problem here is that we still introduce overhead 3- The third step woulñd be based in source address based routing. This may require a upgrade of the routers and perhaps routing protocol. At least it requires to understand better what is needed to achieve this, and why people don't like it > > 7.2. Multihoming solution for medium sites > > Which solution from section 6 are you recommending ?? In this case the hybrid approach is proposed. Path availability is discovered using BGP and the site exit routers inform the host which is the correct isp (source address) that they should use (something like putting a NAROS server in the exit router) > >From what you described, it seems that it is solution 5 (host > based exit path selection + site exit discovery). But this is > contradicting since you said solution 5 is only suitable for small > sites. > > I also deduce you are not recommending source based routing. Maybe > you should make this point more explicit. Well, you could use source address routing or let the host tunnel the packet directly to the host. The three step roadmap would also fit here. > > > ------------------------------- > Purely editorial > Ok, thanks Regards, marcelo From owner-multi6@ops.ietf.org Mon Feb 2 12:58: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 MAA26447 for ; Mon, 2 Feb 2004 12:58:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AniJt-000A8r-PG for multi6-data@psg.com; Mon, 02 Feb 2004 17:57:13 +0000 Received: from [128.4.40.12] (helo=mail.eecis.udel.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AniJP-000A2Z-Uz for multi6@ops.ietf.org; Mon, 02 Feb 2004 17:56:44 +0000 Received: by mail.eecis.udel.edu (Postfix, from userid 62) id E315532B84; Mon, 2 Feb 2004 12:54:42 -0500 (EST) Received: from stimpy.eecis.udel.edu (stimpy.eecis.udel.edu [128.4.40.17]) by mail.eecis.udel.edu (Postfix) with ESMTP id 3558B32B54 for ; Mon, 2 Feb 2004 12:54:42 -0500 (EST) Date: Mon, 2 Feb 2004 12:54:42 -0500 (EST) From: "Armando L. Caro Jr." X-X-Sender: acaro@stimpy.eecis.udel.edu To: Multi6 List Subject: proposal list In-Reply-To: Message-ID: References: X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: UDEL-ECECIS: Sanitizer.pm,v 1.64 2002/10/22 MIME-Version: 1.0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset="US-ASCII" X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Is anyone maintaining a list of all the proposals and their URLs? I am trying to get up to speed on this list and want to go through all the proposals. Thanks. ~armando 0-- --0 | Armando L. Caro Jr. | Protocol Engineering Lab | | www.armandocaro.net | University of Delaware | 0-- --0 From owner-multi6@ops.ietf.org Mon Feb 2 16:02: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 QAA09204 for ; Mon, 2 Feb 2004 16:02:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Anl9g-000645-C3 for multi6-data@psg.com; Mon, 02 Feb 2004 20:58:52 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Anl9T-00062b-IQ for multi6@ops.ietf.org; Mon, 02 Feb 2004 20:58:39 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08940; Mon, 2 Feb 2004 15:58:36 -0500 (EST) Message-Id: <200402022058.PAA08940@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-van-beijnum-multi6-cbhi-00.txt Date: Mon, 02 Feb 2004 15:58:36 -0500 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Crypto Based Host Identifiers Author(s) : I. van Beijnum Filename : draft-van-beijnum-multi6-cbhi-00.txt Pages : 7 Date : 2004-2-2 Abstract This memo specifies a 64-bit crypto-based host identifier that can be used as an interface identifier in protocols that allow address agility, such as [ODT]. The cryptographic nature of the host identifier makes it possible to determine whether a correspondent is legitimately using said host identifier or not. The host identifiers can be used as regular interface identifiers in protocols that don't require an identifier that is separate from locators, or they can be expanded to 128-bit IPv6 address like values for use with protocols that do need such an identifier-only value. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-cbhi-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-van-beijnum-multi6-cbhi-00.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-van-beijnum-multi6-cbhi-00.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-2-2150314.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-van-beijnum-multi6-cbhi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-van-beijnum-multi6-cbhi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150314.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Mon Feb 2 16: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 QAA09310 for ; Mon, 2 Feb 2004 16:03:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AnlDk-0006jd-U0 for multi6-data@psg.com; Mon, 02 Feb 2004 21:03:04 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnlDW-0006hF-Va for multi6@ops.ietf.org; Mon, 02 Feb 2004 21:02:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09232; Mon, 2 Feb 2004 16:02:47 -0500 (EST) Message-Id: <200402022102.QAA09232@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Mon, 02 Feb 2004 16:02:47 -0500 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multihoming: the SCTP solution Author(s) : L. Coene Filename : draft-coene-multi6-sctp-00.txt Pages : 14 Date : 2004-2-2 This document describes the multhoming solution used in SCTP. It tries to answer the questions posed in 'Things MULTI6 developers should think about' [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-coene-multi6-sctp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-coene-multi6-sctp-00.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-coene-multi6-sctp-00.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-2-2150544.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-coene-multi6-sctp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-coene-multi6-sctp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150544.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Mon Feb 2 21:11: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 VAA00724 for ; Mon, 2 Feb 2004 21:11:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Anpvw-000DJq-BB for multi6-data@psg.com; Tue, 03 Feb 2004 02:05:00 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnpvZ-000DGl-Ib for multi6@ops.ietf.org; Tue, 03 Feb 2004 02:04:37 +0000 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAB26947; Mon, 2 Feb 2004 18:04:23 -0800 (PST) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3/8.9.2/MBS-AV-02) with ESMTP id SAA29383; Mon, 2 Feb 2004 18:04:23 -0800 (PST) Received: from XCH-NWBH-01.nw.nos.boeing.com (xch-nwbh-01.nw.nos.boeing.com [192.33.62.231]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i13237P28768; Mon, 2 Feb 2004 18:03:07 -0800 (PST) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-01.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6662); Mon, 2 Feb 2004 18:03:29 -0800 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: HIP draft Date: Mon, 2 Feb 2004 18:03:28 -0800 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C020AC281@xch-nw-27.nw.nos.boeing.com> Thread-Topic: HIP draft Thread-Index: AcPpCZR4eUR9l0H/RluhNvjGwJBUFwA7bw+g From: "Henderson, Thomas R" To: "Iljitsch van Beijnum" , "Multi6 List" X-OriginalArrivalTime: 03 Feb 2004 02:03:29.0297 (UTC) FILETIME=[EADCC010:01C3E9F9] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]=20 > Sent: Sunday, February 01, 2004 1:02 PM > To: Multi6 List > Subject: HIP draft >=20 >=20 > On 25-jan-04, at 16:59, Brian E Carpenter wrote: >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-00.txt >=20 > Ok, I'm missing two things here: >=20 > 1. Failover. The draft says the wg should come up with this. Ok. I assume you mean path failure detection. This seems to me to be a transport layer issue, although a local interface failure could be detected below the transport layer. Coupling between HIP and=20 transport layers is presently unspecified. =20 >=20 > 2. What mechanism makes it possible for unmodified ULPs to set up=20 > connections to HIP-capable destinations? I would expect either the=20 > application to be modified so it knows to ask for the HIP DNS RR, or=20 > there must be some shady resolver hacks that trick the app=20 > and TCP (or=20 > other ULPs) so they think they're dealing with a regular IPv6 address=20 > but in effect they're using HIP identifiers and the associated IP=20 > addresses are recovered at the HIP layer. >=20 See Appendix A in the HIP draft specification for a discussion on this issue. Both approaches you mention have been considered, as well as the inverse case of your last approach that keeps the application, = resolver,=20 and sockets API unmodified (still using IP addresses) but replaces the=20 IP addresses in-kernel with HITs. http://www.ietf.org/internet-drafts/draft-moskowitz-hip-08.txt > And would it be possible to implement HIP in middleboxes so that=20 > unmodified hosts can talk to HIP boxes? >=20 There have been some informal discussions about this. This would=20 probably be a topic for the proposed research group. Tom =20 From owner-multi6@ops.ietf.org Mon Feb 2 21:46: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 VAA01777 for ; Mon, 2 Feb 2004 21:46:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AnqXI-000HPu-9Y for multi6-data@psg.com; Tue, 03 Feb 2004 02:43:36 +0000 Received: from [134.193.143.155] (helo=kc-msxproto2.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnqX6-000HOy-7V for multi6@ops.ietf.org; Tue, 03 Feb 2004 02:43:24 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Feb 2004 20:43:21 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.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: HIP draft Date: Mon, 2 Feb 2004 20:43:22 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B01108285@KC-MAIL4.kc.umkc.edu> Thread-Topic: HIP draft Thread-Index: AcPpCZR4eUR9l0H/RluhNvjGwJBUFwA7bw+gAAHIP8k= From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Henderson, Thomas R" , "Iljitsch van Beijnum" , "Multi6 List" X-OriginalArrivalTime: 03 Feb 2004 02:43:21.0621 (UTC) FILETIME=[7CCC6C50:01C3E9FF] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >> 1. Failover. The draft says the wg should come up with this. Ok. > > I assume you mean path failure detection. This seems to me to be > a transport layer issue, although a local interface failure could > be detected below the transport layer. Coupling between HIP and=20 > transport layers is presently unspecified.=20 =20 HIP has to depend on MA for failover. P. Nikander mentioned something in similar lines @hipsec (i.e. possibility of combining both shared locator address pool and HIP.) From owner-multi6@ops.ietf.org Tue Feb 3 04:32: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 EAA29551 for ; Tue, 3 Feb 2004 04:32:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Anwpx-0009EJ-Px for multi6-data@psg.com; Tue, 03 Feb 2004 09:27:17 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Anwpk-0009D8-Nd for multi6@ops.ietf.org; Tue, 03 Feb 2004 09:27:04 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7F0B97F0A for ; Tue, 3 Feb 2004 10:27:03 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp03.uc3m.es (Postfix) with SMTP id 6AC4B7D13 for ; Tue, 3 Feb 2004 10:27:03 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: Subject: RV: I-D ACTION:draft-bagnulo-multi6-mhtb-00.txt Date: Tue, 3 Feb 2004 10:25:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0126_01C3EA40.1483E2E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0126_01C3EA40.1483E2E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, we have submited the following draft to the wg consideration. It basically addresses an operational issue, rather than the key issues Feedback about if this is a real deployment issue would be very welcome. Regards, marcelo > -----Mensaje original----- > De: owner-ietf-announce@ietf.org [mailto:owner-ietf-announce@ietf.org]En > nombre de Internet-Drafts@ietf.org > Enviado el: lunes, 02 de febrero de 2004 22:02 > Para: IETF-Announce: > Asunto: I-D ACTION:draft-bagnulo-multi6-mhtb-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Multi-Homing Tunnel Broker (MHTB) > Author(s) : M. Bagnulo > Filename : draft-bagnulo-multi6-mhtb-00.txt > Pages : 13 > Date : 2004-2-2 > > RFC 3178 [1] describes a solution to provide site multi-homing > support in IPv6. RFC 3178 multi-homing solution uses tunnels between > the different ISPs and the multi-homed site to provide alternative > paths in case that one of the exit links is down, protecting the > multi-homed site from outages in the direct link with its providers. > > However, the wide adoption of RFC 3178 multi-homing solution implies > the manual configuration of numerous tunnels on the ISPs, which may > impose an important workload in ISP network administrators. This note > proposes the usage of Multi-Homing Tunnel Brokers to automatically > configure the ISP tunnel endpoint in order to ease the adoption of > the solution. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-multi6-mhtb-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of > the message. > > 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-bagnulo-multi6-mhtb-00.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-bagnulo-multi6-mhtb-00.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_000_0126_01C3EA40.1483E2E0 Content-Type: Message/External-body; name="ATT00155.dat" Content-Disposition: attachment; filename="ATT00155.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-2150511.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bagnulo-multi6-mhtb-00.txt ------=_NextPart_000_0126_01C3EA40.1483E2E0 Content-Type: Message/External-body; name="draft-bagnulo-multi6-mhtb-00.txt" Content-Disposition: attachment; filename="draft-bagnulo-multi6-mhtb-00.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-2-2150511.I-D@ietf.org> ------=_NextPart_000_0126_01C3EA40.1483E2E0-- From owner-multi6@ops.ietf.org Tue Feb 3 05:18: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 FAA00696 for ; Tue, 3 Feb 2004 05:18:02 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AnxYq-000EkS-0r for multi6-data@psg.com; Tue, 03 Feb 2004 10:13:40 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnxYb-000Ei2-Kz for multi6@ops.ietf.org; Tue, 03 Feb 2004 10:13:25 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1CB9E9370; Tue, 3 Feb 2004 11:13:24 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id E3D1C9362; Tue, 3 Feb 2004 11:13:23 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , Cc: Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Tue, 3 Feb 2004 11:12:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200402022102.QAA09232@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Just a couple of comments, IMHO one of the important benefits of using a transport layer mechanism to preserve established communications is that the security is simpler than the mechanisms at 3.5 layer. The reason for this is that only a connection is at stake, and not the complete identity of the host. This allows to build simple return routability checks which may be acceptable, while they are probably not acceptable for lower layer solutions. Perhaps a comment about this would fit in section 2.3.2 or in the section 3? Another comment is about how does an sctp solution deals with ingress filtering? thanks, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Internet-Drafts@ietf.org > Enviado el: lunes, 02 de febrero de 2004 22:03 > Para: IETF-Announce: > CC: multi6@ops.ietf.org > Asunto: I-D ACTION:draft-coene-multi6-sctp-00.txt > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > Title : Multihoming: the SCTP solution > Author(s) : L. Coene > Filename : draft-coene-multi6-sctp-00.txt > Pages : 14 > Date : 2004-2-2 > > This document describes the multhoming solution used in SCTP. It > tries to answer the questions posed in 'Things MULTI6 developers > should think about' [1]. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-coene-multi6-sctp-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of > the message. > > 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-coene-multi6-sctp-00.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-coene-multi6-sctp-00.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. > From owner-multi6@ops.ietf.org Tue Feb 3 07: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 HAA05710 for ; Tue, 3 Feb 2004 07:03:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AnzDB-0002JX-ML for multi6-data@psg.com; Tue, 03 Feb 2004 11:59:25 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnzC9-00026I-RF for multi6@ops.ietf.org; Tue, 03 Feb 2004 11:58:22 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id D6C18212C31; Tue, 3 Feb 2004 13:58:20 +0200 (EET) Message-ID: <401F8BD5.3050506@nomadiclab.com> Date: Tue, 03 Feb 2004 13:53:57 +0200 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20040114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: New multi6 draft: WIMP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, marcelo bagnulo wrote: >>>If so, wouldn't this imply that an attacker sending INIT messages could >>>force the responder to gnerate hash chains, sort of DoS attack? >>> >>> > >[...] > > > >>A short hash chain generation is a quite fast operation compared to >>signature calculation. >> >> > >why do you compare it with the processing required to perform a signature >calculation? > >I mean if i were an attacker, i would do the following: > >The goal of the DoS attack is to consume the processing power by soliciting >the victim to produce (useless) hash chains. > >So, the attacker generates a random number as an ID(I) and also a >challenge(I) and then simply generate a random string which length is the >same than the expected length of the HMAC_INIT. I think the attacker can do >this because the victim (i.e. the responder) cannot verify the HMAC_INIT >since it doesn't know H0(I). > >The attacker can generate as much INIT messages as he wants, he just has to >add 1 to the ID(I) values (in order to avoid the duplication of IDs) > >So, the attacker can force the responder to generate hash chains based on >the ID(I). > >As far as i know (note that i am no security expert nor anything close to >this), the idea to avoid DoS attacks is to impose more workload to the >initiator to the responder. > >Now, in this case, in order to generate INIT messages the initiator just has >to perform an addition operation (adding 1 to the ID(I)) > >However, the responder has to generate a hash chain. > >I don't have computation time values but i would say that the responder task >is more time consuming than the attacker task. >Am i missing something? > > > > You are right. DoS is always a difficult problem. There is a trade-off between DoS resistance and other security features. The current hash chain generation is designed to support state-loss, and it is dependent of parameters coming from the initiator. Basically, the responder could protect the HMAC_CC with a local secret and generate the hash chain after receiving CCR message. In that case, the responder could not bind the CC and CONF messages together. The protocol were open for MitM attack. In other words, an attacker could send CONF message before the authentic responder. We have to think more about the DoS situation. However, I would not like to include any puzzle to the INIT message. > > >>A short description: >> >>Once Responder receives INIT message it protects the received values, >>including HMAC_INIT, with HMAC_CC. The responder uses the temporary hash >>chain value as a key in HMAC_CC. Finally, the responder receives CCR >> >> >message > > >>and recomputes the hash chain. It uses the long term secret to recompute >>the chain. >>The responder verifies HMAC_CC to see that it already has reveived INIT >>message with a specific ID pair. The initiator, in turn, discloses its >>anchor value to prove that is was reachable in the specific location. >> >> > >Well, this is not really a big issue, but i think that the proof that the >initiator is reachable at the specific location is provided by the fact that >the initiator has received the HMAC_CC value (and he is proving it because >he is including it in the CCR packet) > > > Yes! >Disclosing the anchor value does not prove that he is reachable at the >specific location. Displaying the anchor value proves that the initiator has >generated both the INIT message and the CCR message. > > > Right. >Now, the responder is stateless and thanks to the anchor values it can >verify that the same initiator has sent both the INIT and the CCR message. > >But, as i said, this is really minor. > >[...] > > > > > >perfect, thanks > >IMHO you should include this example in the draft, it really makes things so >much clearer (at least for me) > > > Ok. I'll put it into the draft > >I think that WIMP may be susceptible to the following hijacking attack. Let >me know if i am wrong. > >Attacker A with address IPA >Server S with IP=IPS and FQDN=www.server.com >Victim V with IP=IPV and FQDN=FQDNV > >The attacker will try to impersonate S. Now if you consider that S is >server, usually is V who contacts (think for instance a newspaper web server >where V reads the news every morning). So the attacker will try to establish >some malicious state in V so that when V tries to send packets to S, he will >actually send them to A. > >The attacker calculates ID(S)=Hash(www.server.com) and ID(V)=Hash(FQDNV) >The attacker sends a INIT value with ID(I)=ID(S) and ID(R)=ID(V) using its >own IP address > >Now the attacker has generated this state in V. It can preserve this state >by simply sending periodical pings or just UDP packets to unused ports >(since WIMP is below UDP, this would be enough to preserve the state at the >wimp layer, right?) > >Eventually, V will try to contact S to read the news. > >At this point, V will calculate Hash(www.server.com) > >Considering that V already has a state with ID(R)=Hash(www.server.com) and >according to the rule 2 described in section 4.1, V will simply use the >available state in the wimp layer. > >This means that when V tries to communicate with S, V will be actually >sending packets to the IP address associated to this state, that is IPA, so >V will send packets to the attacker. So the attacker will impersonate the >server. > >Would this attack work? > > > Unfortunately it works :-) thanks! We can fix the problem in a couple of ways. 1) the initiator must verify that the existing context has at least one verified IP addresses that corresponds the IP addresses in the DNS. or 2) The initiating party must not re-use a context if it is initiated by other party. As a consequence, p2p applications will have two contexts. One per direction. Br, Jukka >Thanks, marcelo > > > > >>Br, Jukka >> >> >> >>>Thanks, marcelo >>> >>> >>> >>> >>> >>> >> >> >>> >>> >>> >>>>-----Mensaje original----- >>>>De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En >>>>nombre de Jukka Ylitalo >>>>Enviado el: jueves, 29 de enero de 2004 10:09 >>>>Para: multi6@ops.ietf.org >>>>Asunto: New multi6 draft: WIMP >>>> >>>> >>>>(uh oh, the previous email was incorrectly aligned) >>>> >>>>Hi, >>>> >>>>We have submitted a new multi6 draft to I-D directory. The draft >>>>defines a Weak Identifier Multihoming Protocol (WIMP), and we >>>>wrote it in order to see how opportunistic/weak authentication >>>>methods could >>>>be used to solve the multi6 problem. >>>> >>>>WIMP is one of those protocols that introduce a new protocol layer >>>>between IP and upper layers. Our approach uses some very basic >>>>cryptograpahic funtions (reverse hash chains and secret splitting) in >>>>order to have light and (hopefully) simple solution. The protocol >>>>is not buller broof from security point of view, however, it intends >>>>to be secure enough and easy to implement. >>>> >>>>We hope it will stimulate discussion on various solution to >>>>multi6 problem. >>>> >>>>See more details from the draft itself, available in: >>>> >>>>http://www.hip4inter.net/multi6/draft-ylitalo-multi6-wimp-00.txt >>>> >>>>Thanks, Jukka Ylitalo >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >>> > > > > > From owner-multi6@ops.ietf.org Tue Feb 3 07:13:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06020 for ; Tue, 3 Feb 2004 07:13:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AnzPm-0003sC-4a for multi6-data@psg.com; Tue, 03 Feb 2004 12:12:26 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AnzPX-0003qO-I4 for multi6@ops.ietf.org; Tue, 03 Feb 2004 12:12:11 +0000 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i13CCA209289 for ; Tue, 3 Feb 2004 14:12:10 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Feb 2004 14:12:08 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 14:12:08 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 3 Feb 2004 14:12:07 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Tue, 3 Feb 2004 14:12:07 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-coene-multi6-sctp-00.txt Thread-Index: AcPqPzhIphAKTBUbT0qGcewj3q+NbQACYKZw From: To: , Cc: X-OriginalArrivalTime: 03 Feb 2004 12:12:07.0780 (UTC) FILETIME=[F1930A40:01C3EA4E] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Marcelo, You were quick. A small preface before I get to your points. I worked with Lode to get this document done by Friday, it could stand some = improvement. Additionally, the SCTP multihoming document needs updating. We can try = to get these both updated before Seoul. Secondly, my general feeling is that SCTP is one tool for Multi6 - I am not sure if it is the entire answer. I think we need to discuss this. Finally, there have been some interesting ideas on how to transition = SCTP on the ietf.org mailing list, I am not sure if they should/could be = discussed in this document. If so, I can try to capture some of them when we update = the document. Now onto your points: > Just a couple of comments, IMHO one of the important benefits of using = a > transport layer mechanism to preserve established communications is = that the > security is simpler than the mechanisms at 3.5 layer. The reason for = this is > that only a connection is at stake, and not the complete identity of = the > host. =20 I agree. One of the interesting properties of SCTP is that it is = possible to=20 for connections to set the addresses to use from the host, for example, = over=20 all/any available interfaces & IP addresses. Applications could use = this,=20 or could include just the IP addresses that they consider important for = their needs. > This allows to build simple return routability checks which may be > acceptable, while they are probably not acceptable for lower layer > solutions. Perhaps a comment about this would fit in section 2.3.2 or = in the > section 3? This I can include. In a way, SCTP employs a return routable-like = mechanism in the initialization phase. > Another comment is about how does an sctp solution deals with ingress > filtering? In what way do you mean? SCTP has some resistence to DoS-style attacks, like SYN floody, by way of its setup. This won't solve everything, of = couse, I am sure that hackers will find other ways to cause mischief. thanks, John From owner-multi6@ops.ietf.org Tue Feb 3 09:23: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 JAA09440 for ; Tue, 3 Feb 2004 09:22:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao1Nv-000KQY-W2 for multi6-data@psg.com; Tue, 03 Feb 2004 14:18:39 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao1Nh-000KPH-Qm for multi6@ops.ietf.org; Tue, 03 Feb 2004 14:18:26 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 93AA783B7; Tue, 3 Feb 2004 15:18:24 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 7DC8C8388; Tue, 3 Feb 2004 15:18:24 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , Cc: Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Tue, 3 Feb 2004 15:17:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, > You were quick. A small preface before I get to your points. I worked > with Lode to get this document done by Friday, it could stand > some improvement. > Additionally, the SCTP multihoming document needs updating. We > can try to get > these both updated before Seoul. Thanks for providing this doc so fast. IMHO the SCTP POV is important. > > Secondly, my general feeling is that SCTP is one tool for Multi6 - I am > not sure if it is the entire answer. I think we need to discuss this. I agree with you, IMHO SCTP is just one of the tools that can be used to preserve established communications in mh environments > > Finally, there have been some interesting ideas on how to transition SCTP > on the ietf.org mailing list, I am not sure if they should/could > be discussed in > this document. If so, I can try to capture some of them when we > update the document. I don't know about the document, but i would find useful to understand how easy is to migrate to sctp, this would have a great impact on the deployability of the solution. > This I can include. In a way, SCTP employs a return > routable-like mechanism > in the initialization phase. Ok, and this would be acceptable from a security POV becuase it only affect this particular connection and not all the present and future connections of this host > > > Another comment is about how does an sctp solution deals with ingress > > filtering? > > In what way do you mean? SCTP has some resistence to DoS-style attacks, > like SYN floody, by way of its setup. This won't solve > everything, of couse, > I am sure that hackers will find other ways to cause mischief. No, this is not a security issue, sorry if my writing was misleading. this is a functional issue. Please check section 3.3 of draft-huitema-multi6-hosts-02.txt for a detailed explanation Basically you have to make sure that the packets are not filtered by ingress filters that is you have to make sure that the source address contained in the packets is the correct one (or that the exit router through which the packet is carried is the appropriate one) Regards, marcelo > > thanks, > John From owner-multi6@ops.ietf.org Tue Feb 3 09:27: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 JAA09620 for ; Tue, 3 Feb 2004 09:27:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao1Vc-000LNk-Gd for multi6-data@psg.com; Tue, 03 Feb 2004 14:26:36 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao1VA-000LLb-HX for multi6@ops.ietf.org; Tue, 03 Feb 2004 14:26:08 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 03 Feb 2004 06:32:47 +0000 Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id i13EQ6DI013472 for ; Tue, 3 Feb 2004 06:26:06 -0800 (PST) Received: from cisco.com (rtp-vpn3-428.cisco.com [10.82.217.174]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA15028 for ; Tue, 3 Feb 2004 06:26:04 -0800 (PST) Message-ID: <401FAF79.3070803@cisco.com> Date: Tue, 03 Feb 2004 09:26:01 -0500 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Multi6 List Subject: new draft available X-Enigmail-Version: 0.83.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It's draft-lear-multi6-things-to-think-about-01.txt. Eliot From owner-multi6@ops.ietf.org Tue Feb 3 10:11: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 KAA12334 for ; Tue, 3 Feb 2004 10:11:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao2Aa-0001eI-EC for multi6-data@psg.com; Tue, 03 Feb 2004 15:08:56 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao2AN-0001dS-1O for multi6@ops.ietf.org; Tue, 03 Feb 2004 15:08:43 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3A5D58724; Tue, 3 Feb 2004 16:08:42 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 2A3D48711; Tue, 3 Feb 2004 16:08:42 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Jukka Ylitalo" , Subject: RE: New multi6 draft: WIMP Date: Tue, 3 Feb 2004 16:07:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <401F8BD5.3050506@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Unfortunately it works :-) thanks! We can fix the problem in a couple of > ways. > > 1) the initiator must verify that the existing context has at least one > verified IP addresses that corresponds the IP addresses in the DNS. I don't know about this... some random thoughts: - if you use the DNS to validate addresses, i think you loose much of the beauty of your solution. Actually, you could only use the DNS and you end-up in NOID. The only benefit AFAICS would be to support a more dynamic prefix change, for instance to support faster renumbering, but i am not really sure if this is worth it. I mean, probably DNS times and renumbering times are quite compatible - besides, i am not sure that this would be really enough becuase you will have to consider time-shifted attacks. Requiring a valid IP address only means that this IP address was checked once when the REA message was sent. This is not good enough to prevent a time shifted variation of the described attack - the only way i can figure out is to verify the reachability of the address contained in the DNS again when the responder wants to initate the new communication (this is starting to seem a lot to the second solution, i guess) > > or > > 2) The initiating party must not re-use a context if it is initiated by > other party. > As a consequence, p2p applications will have two contexts. One per > direction. Yes, this may wotk... I can see how would you this for TCP and even for connected UDP socket, but is don't know how would you recognize who has initiated the communication in the case of non-connected UDP though (but i have little knowledge about how this work) I would recomend to verify the time shifted attacks in this case either regards, marcelo > > Br, Jukka > > >Thanks, marcelo > > > > > > > > > >>Br, Jukka > >> > >> > >> > >>>Thanks, marcelo > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >>> > >>> > >>> > >>>>-----Mensaje original----- > >>>>De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > >>>>nombre de Jukka Ylitalo > >>>>Enviado el: jueves, 29 de enero de 2004 10:09 > >>>>Para: multi6@ops.ietf.org > >>>>Asunto: New multi6 draft: WIMP > >>>> > >>>> > >>>>(uh oh, the previous email was incorrectly aligned) > >>>> > >>>>Hi, > >>>> > >>>>We have submitted a new multi6 draft to I-D directory. The draft > >>>>defines a Weak Identifier Multihoming Protocol (WIMP), and we > >>>>wrote it in order to see how opportunistic/weak authentication > >>>>methods could > >>>>be used to solve the multi6 problem. > >>>> > >>>>WIMP is one of those protocols that introduce a new protocol layer > >>>>between IP and upper layers. Our approach uses some very basic > >>>>cryptograpahic funtions (reverse hash chains and secret splitting) in > >>>>order to have light and (hopefully) simple solution. The protocol > >>>>is not buller broof from security point of view, however, it intends > >>>>to be secure enough and easy to implement. > >>>> > >>>>We hope it will stimulate discussion on various solution to > >>>>multi6 problem. > >>>> > >>>>See more details from the draft itself, available in: > >>>> > >>>>http://www.hip4inter.net/multi6/draft-ylitalo-multi6-wimp-00.txt > >>>> > >>>>Thanks, Jukka Ylitalo > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> > >>> > >>> > > > > > > > > > > > > From owner-multi6@ops.ietf.org Tue Feb 3 10:53: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 KAA15278 for ; Tue, 3 Feb 2004 10:53:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ao2ot-0006m2-JV for multi6-data@psg.com; Tue, 03 Feb 2004 15:50:35 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ao2oQ-0006he-Qq for multi6@ops.ietf.org; Tue, 03 Feb 2004 15:50:07 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id A85A07800; Tue, 3 Feb 2004 16:50:05 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp03.uc3m.es (Postfix) with SMTP id 0DD5077F5; Tue, 3 Feb 2004 16:50:05 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , "Jukka Ylitalo" , Subject: RE: New multi6 draft: WIMP Date: Tue, 3 Feb 2004 16:48:44 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > > 2) The initiating party must not re-use a context if it is initiated by > > other party. > > As a consequence, p2p applications will have two contexts. One per > > direction. > > Yes, this may wotk... > I can see how would you this for TCP and even for connected UDP > socket, but is don't know how would you recognize who has initiated the > communication in the case of non-connected UDP though Just one more thought... Perhaps an option for this would be: suppose that A wants to initiate acommunication with B A calculates ID(R)=hash(FQDNB) A then searches for a context with ID(R) If one context with ID(R) is found, A verifies ID(I), if ID(I) = hash(FQDNA) then it creates a new context with ID(R) and ID(I)=random if ID(I) =! hash(FQDNA) then it just uses this context This way, you implicetly discover who has created the context. Do you think this may work? regards, marcelo From owner-multi6@ops.ietf.org Wed Feb 4 02:44: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 CAA23724 for ; Wed, 4 Feb 2004 02:44:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AoHbr-000FfK-17 for multi6-data@psg.com; Wed, 04 Feb 2004 07:38:07 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AoHbd-000FeT-1q for multi6@ops.ietf.org; Wed, 04 Feb 2004 07:37:53 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id EAEC7212C31; Wed, 4 Feb 2004 09:37:51 +0200 (EET) Message-ID: <4020A042.3070907@nomadiclab.com> Date: Wed, 04 Feb 2004 09:33:22 +0200 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20040114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: New multi6 draft: WIMP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo bagnulo wrote: >>>2) The initiating party must not re-use a context if it is initiated by >>>other party. >>>As a consequence, p2p applications will have two contexts. One per >>>direction. >>> >>> >>Yes, this may wotk... >>I can see how would you this for TCP and even for connected UDP >>socket, but is don't know how would you recognize who has initiated the >>communication in the case of non-connected UDP though >> >> > >Just one more thought... > >Perhaps an option for this would be: > >suppose that A wants to initiate acommunication with B > >A calculates ID(R)=hash(FQDNB) >A then searches for a context with ID(R) >If one context with ID(R) is found, A verifies ID(I), >if ID(I) = hash(FQDNA) then it creates a new context with ID(R) and >ID(I)=random >if ID(I) =! hash(FQDNA) then it just uses this context > >This way, you implicetly discover who has created the context. > >Do you think this may work? > > > Yes! I think that is a good idea and I will put that into the WIMP draft. I have to still analyze Pekka Nikander's ideas that he sent to me about the same issue. (As a result of this discussion we take the second alternative as a working assumption, and leave the DNS check out of the scope) Thanks, Jukka >regards, marcelo > > > > > > From owner-multi6@ops.ietf.org Thu Feb 5 11:19: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 LAA21895 for ; Thu, 5 Feb 2004 11:19:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aom9u-0006O9-A3 for multi6-data@psg.com; Thu, 05 Feb 2004 16:15:18 +0000 Received: from [194.78.143.102] (helo=hrtades9.atea.be) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aom9V-0006Iz-5q for multi6@ops.ietf.org; Thu, 05 Feb 2004 16:14:53 +0000 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D5YYAW37; Thu, 5 Feb 2004 17:14:50 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Thu, 5 Feb 2004 17:14:52 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4A8@hrtades7.atea.be> From: Coene Lode To: "'mbagnulo@ing.uc3m.es'" , Coene Lode , john.loughney@nokia.com Cc: multi6@ops.ietf.org Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Thu, 5 Feb 2004 17:14:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk >-----Original Message----- >From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es] >Sent: dinsdag 3 februari 2004 11:12 >To: lode.coene@siemens.com; john.loughney@nokia.com >Cc: multi6@ops.ietf.org >Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt > > >Hi, > >Just a couple of comments, IMHO one of the important benefits of using a >transport layer mechanism to preserve established communications is that the >security is simpler than the mechanisms at 3.5 layer. The reason for this is >that only a connection is at stake, and not the complete identity of the >host. This allows to build simple return routability checks which may be >acceptable, while they are probably not acceptable for lower layer >solutions. Perhaps a comment about this would fit in section 2.3.2 or in the >section 3? > We'll try to come up with something.... > >Another comment is about how does an sctp solution deals with ingress >filtering? > A section in the draft on SCTP multihoming issues deals with that: - if the host is able to fill in the IP address of the interface on which the msg is send out, then the return msg will arrive back on that same interface, not on the others. That mean that for the initial outgoing message, the source address will belong to the network to which the host is sending it, thus any ingress filtering within that network should let it pass(it is after all the address given out by that network(via DHCP, fixed...)) - if the host allows to fill in the IP address of ANY interface as the source addres of the msg(example : source = IP1, addres of interface on which msg was actually send out was IP3) then ingress filter should drop the message(as should be expected) This is basically implementation dependant in the host. > >thanks, marcelo > Hopes this answers the questions... Yours sincerely, Lode From owner-multi6@ops.ietf.org Thu Feb 5 12:57: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 MAA25949 for ; Thu, 5 Feb 2004 12:57:01 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AongR-000LeD-B6 for multi6-data@psg.com; Thu, 05 Feb 2004 17:52:59 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AongE-000Lcu-TK for multi6@ops.ietf.org; Thu, 05 Feb 2004 17:52:47 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D91A68B21; Thu, 5 Feb 2004 18:52:45 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id C3DF58B1A; Thu, 5 Feb 2004 18:52:45 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Coene Lode" , Cc: Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Thu, 5 Feb 2004 18:51:17 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4A8@hrtades7.atea.be> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Coene, > A section in the draft on SCTP multihoming issues deals with that: > - if the host is able to fill in the IP address of the interface on which > the msg is send out, then the return msg will arrive back on that same > interface, not on the others. That mean that for the initial outgoing > message, the source address will belong to the network to which > the host is > sending it, thus any ingress filtering within that network should let it > pass(it is after all the address given out by that network(via DHCP, > fixed...)) > - if the host allows to fill in the IP address of ANY interface as the > source addres of the msg(example : source = IP1, addres of interface on > which msg was actually send out was IP3) then ingress filter > should drop the > message(as should be expected) > This is basically implementation dependant in the host. What happens when there are multiple addresses (with different prefixes) assigned to the same interface? Regards, marcelo From owner-multi6@ops.ietf.org Thu Feb 5 13:22: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 NAA27071 for ; Thu, 5 Feb 2004 13:22:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aoo75-0000OQ-CC for multi6-data@psg.com; Thu, 05 Feb 2004 18:20:31 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aoo6s-0000M9-9C for multi6@ops.ietf.org; Thu, 05 Feb 2004 18:20:18 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7FF068CDE for ; Thu, 5 Feb 2004 19:20:17 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 6C2418CC1 for ; Thu, 5 Feb 2004 19:20:17 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: Subject: a question about tunnels Date: Thu, 5 Feb 2004 19:18:49 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.61 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a very simple question about tunnels, but i am a bit confused by what i have found in the specs, so perhaps someone could help me. The question is: what is the behaviour of a host, that doesn't have any configured tunnel, when it receives a tunneled packet addressed to him (both destination addresses, inner and outer, are assigned to the host)? Suppose that you have a host A with a single IP address IPA The host receives a IP in IP encapsulated packet The inner IP header contains destiantion address IPA and source address IPB The outer IP header contains destiantion address IPA and source address IPC The Host A has no configured tunnel With IPC What does the host does with this packet? I would expect that the packet is discarded. This IMHO would be the behaviour coherent with the proposed processing of the HoA option of MIPv6. However, in RFC 2003 (security considerations), it is stated that: Host implementations that are capable of receiving encapsulated IP datagrams SHOULD admit only those datagrams fitting into one or more of the following categories: [...] - The encapsulated (inner) datagram is addressed to a network interface belonging to the decapsulator So, RFC 2003 recomends that nodes should accept these packets... Is this correct? I mean, if this is so, the transport layer survivability problem could be easier, i guess Thanks, marcelo From owner-multi6@ops.ietf.org Mon Feb 9 17:48: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 RAA25593 for ; Mon, 9 Feb 2004 17:48:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqKB9-000GQO-1M for multi6-data@psg.com; Mon, 09 Feb 2004 22:46:59 +0000 Received: from [217.174.67.69] (helo=laptop2.kurtis.pp.se) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqKB1-000GOL-O0 for multi6@ops.ietf.org; Mon, 09 Feb 2004 22:46:55 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 43BA22C7995; Mon, 9 Feb 2004 23:46:28 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <52817B97-5B38-11D8-B31A-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: proposal list Date: Mon, 9 Feb 2004 20:44:06 +0100 To: "Armando L. Caro Jr." X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DATE_IN_PAST_03_06 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (sorry for the late reply) Armando, On 2004-02-02, at 18.54, Armando L. Caro Jr. wrote: > Is anyone maintaining a list of all the proposals and their URLs? I am > trying to get up to speed on this list and want to go through all the > proposals. I have created a list of (some of) the proposals that have gone through multi6 that is linked from the multi6 web-site at http://ops.ietf.org/multi6. The list is not complete (especially with the drafts of the last few weeks) and it contains some drafts that have expired. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCfjCKarNKXTPFCVEQJVFACgtAax9EX+b2oaSBFWGeUt1VAp1tIAoO4b ytT6yqF9J0tNd+EOSHIetaln =i4SI -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 9 17:48: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 RAA25613 for ; Mon, 9 Feb 2004 17:48:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqKAd-000GLc-6l for multi6-data@psg.com; Mon, 09 Feb 2004 22:46:27 +0000 Received: from [217.174.67.69] (helo=laptop2.kurtis.pp.se) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqKAU-000GK3-0D for multi6@ops.ietf.org; Mon, 09 Feb 2004 22:46:21 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id F2A812C7987; Mon, 9 Feb 2004 23:45:32 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <75EAB65D-5B3B-11D8-B31A-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: From: Kurt Erik Lindqvist Subject: Re: a question about tunnels Date: Mon, 9 Feb 2004 21:06:34 +0100 To: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-05, at 19.18, marcelo bagnulo wrote: > Suppose that you have a host A with a single IP address IPA > The host receives a IP in IP encapsulated packet > The inner IP header contains destiantion address IPA and source > address IPB > The outer IP header contains destiantion address IPA and source > address IPC > The Host A has no configured tunnel With IPC > > What does the host does with this packet? > > I would expect that the packet is discarded. This IMHO would be the > behaviour coherent with the proposed processing of the HoA option of > MIPv6. > > However, in RFC 2003 (security considerations), it is stated that: > > Host implementations that are capable of receiving encapsulated IP > datagrams SHOULD admit only those datagrams fitting into one or more > of the following categories: > > [...] > - The encapsulated (inner) datagram is addressed to a network > interface belonging to the decapsulator > > So, RFC 2003 recomends that nodes should accept these packets... > > Is this correct? > I mean, if this is so, the transport layer survivability problem could > be > easier, i guess > I am guessing, but my guess is that the host accepts the packet but what happens then is up to the ULP in question. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCfoTKarNKXTPFCVEQIdpQCdHGdUps0o8Ubzdht7YVA1pRXbl2IAoL1D GqFLpY6FDNPremt1polZJpWA =iXgS -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 9 17:48: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 RAA25631 for ; Mon, 9 Feb 2004 17:48:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqKAk-000GLw-5f for multi6-data@psg.com; Mon, 09 Feb 2004 22:46:34 +0000 Received: from [217.174.67.69] (helo=laptop2.kurtis.pp.se) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqKAb-000GKO-GD for multi6@ops.ietf.org; Mon, 09 Feb 2004 22:46:30 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 93E112C798E; Mon, 9 Feb 2004 23:46:01 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <911B7176-5B3A-11D8-B31A-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: , , From: Kurt Erik Lindqvist Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Mon, 9 Feb 2004 21:00:10 +0100 To: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Secondly, my general feeling is that SCTP is one tool for Multi6 - I am > not sure if it is the entire answer. I think we need to discuss this. Having the proposals outline if they are enough as stand-alone or as complements or needs complements, should be an important part of the self-evaluation. Which of the alternatives are desired should be part of the architectural evaluation. And we need to get there... > Finally, there have been some interesting ideas on how to transition > SCTP > on the ietf.org mailing list, I am not sure if they should/could be > discussed in > this document. If so, I can try to capture some of them when we update > the document. Transition is part of the questions in Eliots draft. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCfmzaarNKXTPFCVEQJIOgCgpruH4TSHxi2oUXrYG7IGTQ7btd8AoPoE iH3uG4hc9IaHGmPHly7xXubF =hIU5 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 9 23: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 XAA16125 for ; Mon, 9 Feb 2004 23:54:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqPtN-00064F-2w for multi6-data@psg.com; Tue, 10 Feb 2004 04:53:01 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqPtC-00062c-9G for multi6@ops.ietf.org; Tue, 10 Feb 2004 04:52:50 +0000 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1A4qmq15346 for ; Tue, 10 Feb 2004 06:52:48 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 10 Feb 2004 06:52:48 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 10 Feb 2004 06:52:48 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Tue, 10 Feb 2004 06:52:47 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-coene-multi6-sctp-00.txt Thread-Index: AcPvXpyZUP566WUaRHq9BkxZIJs3iQAMvR9g From: To: Cc: , , X-OriginalArrivalTime: 10 Feb 2004 04:52:48.0362 (UTC) FILETIME=[BB074CA0:01C3EF91] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Kurt, > Having the proposals outline if they are enough as stand-alone or as=20 > complements or needs complements, should be an important part of the=20 > self-evaluation. Which of the alternatives are desired should be part=20 > of the architectural evaluation. And we need to get there... Sounds good to me. =20 > > Finally, there have been some interesting ideas on how to transition = SCTP > > on the ietf.org mailing list, I am not sure if they should/could be=20 > > discussed in this document. If so, I can try to capture some of them = > > when we update the document. >=20 > Transition is part of the questions in Eliots draft. We have some thoughts, but we can certainly provide more ideas on = transition suggestions when we update the draft. We'll flag this as something to add in the draft. John From owner-multi6@ops.ietf.org Tue Feb 10 00:41: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 AAA17638 for ; Tue, 10 Feb 2004 00:41:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqQdb-000DVD-Ot for multi6-data@psg.com; Tue, 10 Feb 2004 05:40:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqQdU-000DRt-7X for multi6@ops.ietf.org; Tue, 10 Feb 2004 05:40:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1A5ebT08148; Tue, 10 Feb 2004 07:40:37 +0200 Date: Tue, 10 Feb 2004 07:40:37 +0200 (EET) From: Pekka Savola To: marcelo bagnulo cc: multi6@ops.ietf.org Subject: Re: a question about tunnels In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Thu, 5 Feb 2004, marcelo bagnulo wrote: > The question is: what is the behaviour of a host, that doesn't have any > configured tunnel, when it receives a tunneled packet addressed to him (both > destination addresses, inner and outer, are assigned to the host)? IPv6-in-IPv4 configured tunneling spec, draft-ietf-v6ops-mech-v2-02.txt, at least discards them. And IMHO that's what should be done, unless one specifies a specific tunneling speudo-interface which is open to the whole world and accepts specific kind of packets (a bad idea, I think). -- 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 Feb 10 02:31: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 CAA03785 for ; Tue, 10 Feb 2004 02:31:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqSLA-000DV0-BI for multi6-data@psg.com; Tue, 10 Feb 2004 07:29:52 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqSKx-000DQ0-VL for multi6@ops.ietf.org; Tue, 10 Feb 2004 07:29:40 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id BF9552C8629; Tue, 10 Feb 2004 08:29:41 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, marcelo bagnulo From: Kurt Erik Lindqvist Subject: Re: a question about tunnels Date: Tue, 10 Feb 2004 08:29:37 +0100 To: Pekka Savola X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> The question is: what is the behaviour of a host, that doesn't have >> any >> configured tunnel, when it receives a tunneled packet addressed to >> him (both >> destination addresses, inner and outer, are assigned to the host)? > > IPv6-in-IPv4 configured tunneling spec, > draft-ietf-v6ops-mech-v2-02.txt, at least discards them. So, what you are saying is that IPv4-in-IPv4 and IPv6-in-IPv6 and IPv6-in-IPv4 all could behave differently? Wasn't someone to write a v6ops security document? Shouldn't this go in there? And aren't we on the wrong mailinglist then? :-) > And IMHO > that's what should be done, unless one specifies a specific tunneling > speudo-interface which is open to the whole world and accepts specific > kind of packets (a bad idea, I think). Agreed. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCiIZKarNKXTPFCVEQIXMgCggjcfNfwLAjDViybtBfmI1c6rpaAAoOPa LzynID5t24dScL1gAhIn8kX9 =4Yfg -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Feb 10 04:42: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 EAA07853 for ; Tue, 10 Feb 2004 04:42:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqUOI-000CN0-H9 for multi6-data@psg.com; Tue, 10 Feb 2004 09:41:14 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqUO5-000CMV-On for multi6@ops.ietf.org; Tue, 10 Feb 2004 09:41:01 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C27BD72F9; Tue, 10 Feb 2004 10:41:00 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp02.uc3m.es (Postfix) with SMTP id AC0F75E48; Tue, 10 Feb 2004 10:41:00 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Pekka Savola" Cc: Subject: RE: a question about tunnels Date: Tue, 10 Feb 2004 10:39:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-reply-to: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, Kurtis, Thanks for the answers... > > On Thu, 5 Feb 2004, marcelo bagnulo wrote: > > The question is: what is the behaviour of a host, that doesn't have any > > configured tunnel, when it receives a tunneled packet addressed > to him (both > > destination addresses, inner and outer, are assigned to the host)? > > IPv6-in-IPv4 configured tunneling spec, > draft-ietf-v6ops-mech-v2-02.txt, at least discards them. And IMHO > that's what should be done, unless one specifies a specific tunneling > speudo-interface which is open to the whole world and accepts specific > kind of packets (a bad idea, I think). Yes, that what i expected, but i couldn't find it stated as a requirement in any spec Regards, marcelo > > -- > 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 Feb 10 06:49: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 GAA13024 for ; Tue, 10 Feb 2004 06:49:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqWNS-000817-6d for multi6-data@psg.com; Tue, 10 Feb 2004 11:48:30 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqWNH-0007tj-Lz for multi6@ops.ietf.org; Tue, 10 Feb 2004 11:48:19 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id DF03C2CA662 for ; Tue, 10 Feb 2004 12:48:21 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <04DB11FD-5BBF-11D8-B31A-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Draft agenda for Seoul Date: Tue, 10 Feb 2004 12:48:18 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 current agenda : WEDNESDAY, March 3, 2004 0900-1130 Morning Sessions =========================== 1. Agenda bashing 5 2. Charter review 15 3. Short intros to NEW drafts 20 draft-ohta-multi6-threats-00.txt draft-ohta-multi6-8plus8-00.txt 20 minutes draft-ohira-multi6-multilink-auto-prefix-assign-00.txt 4. draft-lear-multi6-things-to-think-about-00.txt 30 5. Architectural analysis, Geoff Houston, 20 mins. Note that I will split the 20 minutes between all _NEW_ drafts that want a slot. This means your allocated time per draft will get less and less. Expect it to be around 2-3 minutes. This means that on the contrary to earlier WG meetings, see these slots as an opportunity for clarifying questions, not for presenting the solution. That should be in the draft...:-) Other authors of -00 drafts, mail me for slot allocations. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCjFBaarNKXTPFCVEQJ9xwCgjFRe1JQQc5Ra6HOkutKQs/QCGbsAoN6t 4opnbNpYPiMRpRWm+r4s8oe/ =K3NO -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Feb 10 07:08:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13441 for ; Tue, 10 Feb 2004 07:08:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqWgC-000CAN-C0 for multi6-data@psg.com; Tue, 10 Feb 2004 12:07:52 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqWg1-000C4g-9E for multi6@ops.ietf.org; Tue, 10 Feb 2004 12:07:41 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1AC8Bof016985 for ; Tue, 10 Feb 2004 13:08:12 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: Iljitsch van Beijnum Subject: Streaming Date: Tue, 10 Feb 2004 13:07:38 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit As I'm not going to be in Seoul and multi6 isn't traditionally one of the two sessions that is multicast (not that I have multicast access anyway), I was wondering if it would be possible to set up some ad-hoc audio streaming. If someone at the meeting can send a 40 kbps or so audio stream, I'll be happy to reflect this stream to about a dozen others. This is unbelievably simple to do if you have a Mac with Apple's free Quicktime Broadcaster and the built-in microphone (if sitting somewhere in the neighborhood of a PA loud speaker). This will produce an MPEG-4 (AAC) audio stream which can be played with Quicktime and VLC and possibly the Real viewer. From owner-multi6@ops.ietf.org Tue Feb 10 08:38: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 IAA17898 for ; Tue, 10 Feb 2004 08:38:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqY4h-000Oe1-26 for multi6-data@psg.com; Tue, 10 Feb 2004 13:37:15 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqY4g-000Odl-5R for multi6@ops.ietf.org; Tue, 10 Feb 2004 13:37:14 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 6791B2CB315 for ; Tue, 10 Feb 2004 14:37:16 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) In-Reply-To: <04DB11FD-5BBF-11D8-B31A-000A95928574@kurtis.pp.se> References: <04DB11FD-5BBF-11D8-B31A-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <3B746C1E-5BCE-11D8-A88A-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: Draft agenda for Seoul Date: Tue, 10 Feb 2004 14:37:12 +0100 To: Multi6 List X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Updated agenda to fix a typo and add a draft I had forgotten... WEDNESDAY, March 3, 2004 0900-1130 Morning Sessions =========================== 1. Agenda bashing 5 2. Charter review 15 3. Short intros to NEW drafts 20 min draft-ohta-multi6-threats-00.txt draft-ohta-multi6-8plus8-00.txt draft-ohira-multi6-multilink-auto-prefix-assign-00.txt draft-ylitalo-multi6-wimp-00.txt 4. draft-lear-multi6-things-to-think-about-00.txt 30 5. Architectural analysis, Geoff Houston, 20 mins. - - kurtis - On 2004-02-10, at 12.48, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > current agenda : > > WEDNESDAY, March 3, 2004 > 0900-1130 Morning Sessions > =========================== > > 1. Agenda bashing 5 > 2. Charter review 15 > 3. Short intros to NEW drafts 20 > draft-ohta-multi6-threats-00.txt > draft-ohta-multi6-8plus8-00.txt 20 minutes > draft-ohira-multi6-multilink-auto-prefix-assign-00.txt > > 4. draft-lear-multi6-things-to-think-about-00.txt 30 > 5. Architectural analysis, Geoff Houston, 20 mins. > > > Note that I will split the 20 minutes between all _NEW_ drafts that > want a slot. This means your allocated time per draft will get less and > less. Expect it to be around 2-3 minutes. This means that on the > contrary to earlier WG meetings, see these slots as an opportunity for > clarifying questions, not for presenting the solution. That should be > in the draft...:-) > > Other authors of -00 drafts, mail me for slot allocations. > > Best regards, > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQCjFBaarNKXTPFCVEQJ9xwCgjFRe1JQQc5Ra6HOkutKQs/QCGbsAoN6t > 4opnbNpYPiMRpRWm+r4s8oe/ > =K3NO > -----END PGP SIGNATURE----- > > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCjei6arNKXTPFCVEQK7jACgsIKNS8D52Hnlo56Nqqgb/KhWPiMAoLSC nF9CJKrNcE0ambtccRl7DaH/ =yjLg -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Feb 10 08:38:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17916 for ; Tue, 10 Feb 2004 08:38:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AqY5T-000OiH-17 for multi6-data@psg.com; Tue, 10 Feb 2004 13:38:03 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.psg.com with esmtp (Exim 4.30; FreeBSD) id 1AqY5M-000Ohw-Sa for multi6@ops.ietf.org; Tue, 10 Feb 2004 13:37:57 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 1DF762CB322; Tue, 10 Feb 2004 14:37:59 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <55D3D78B-5BCE-11D8-A88A-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Streaming Date: Tue, 10 Feb 2004 14:37:56 +0100 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hmm. Let's see what we can arrange. I will discuss this with you off-line. - - kurtis - On 2004-02-10, at 13.07, Iljitsch van Beijnum wrote: > As I'm not going to be in Seoul and multi6 isn't traditionally one of > the two sessions that is multicast (not that I have multicast access > anyway), I was wondering if it would be possible to set up some ad-hoc > audio streaming. > > If someone at the meeting can send a 40 kbps or so audio stream, I'll > be happy to reflect this stream to about a dozen others. > > This is unbelievably simple to do if you have a Mac with Apple's free > Quicktime Broadcaster and the built-in microphone (if sitting > somewhere in the neighborhood of a PA loud speaker). This will produce > an MPEG-4 (AAC) audio stream which can be played with Quicktime and > VLC and possibly the Real viewer. > > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCjetqarNKXTPFCVEQLO7ACgr707MpyvKFDtYhnbxQaxXEsUBgYAoMmN MvNXUYRT2bi69Xod5RgrV8XN =hy7x -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Feb 11 05:36: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 FAA26115 for ; Wed, 11 Feb 2004 05:36:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aqrgk-0009Rc-4M for multi6-data@psg.com; Wed, 11 Feb 2004 10:33:50 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aqrgi-0009RI-Mg for multi6@ops.ietf.org; Wed, 11 Feb 2004 10:33:48 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F371D8FBE for ; Wed, 11 Feb 2004 11:33:47 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id D69B29272 for ; Wed, 11 Feb 2004 11:33:47 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: Subject: draft-huitema-multi6-hosts-03 Date: Wed, 11 Feb 2004 11:32:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We have submited the 03 version of the draft to the wg. You can find it at: http://www.it.uc3m.es/marcelo/draft-huitema-multi6-hosts-03.txt Regards, marcelo From owner-multi6@ops.ietf.org Wed Feb 11 19:07: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 TAA12369 for ; Wed, 11 Feb 2004 19:07:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar4Mz-000N6q-9D for multi6-data@psg.com; Thu, 12 Feb 2004 00:06:17 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ar4Mw-000N5x-Hj for multi6@ops.ietf.org; Thu, 12 Feb 2004 00:06:14 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1C0Ebd05358 for ; Wed, 11 Feb 2004 16:14:37 -0800 Date: Wed, 11 Feb 2004 16:06:12 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1719934176.20040211160612@brandenburg.com> To: Multi6 List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The draft and Avri and I wrote on the SLAP idea is now available: > Title : Framework for Common Endpoint Locator Pools > Author(s) : D. Crocker > Filename : draft-crocker-celp-00.txt > Pages : 10 > Date : 2004-2-11 > > Classic Internet transport protocols use a single source IP Address > and a single destination IP Address, as part of the identification > for an individual transport data flow. This is problematic for > multihomed hosts and for mobile hosts, collectively needing > 'multiaddressing' support. The basic goal, then, is to find a method > for multiaddressing that makes the smallest possible change to the > architecture and to current systems, while maintaining flexibility > for different emerging solutions. This draft proposes a framework > for methods for creating Common Endpoint Locator Pools that can be > used by and among the proposed solutions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-crocker-celp-00.txt d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Feb 12 00:43: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 AAA25913 for ; Thu, 12 Feb 2004 00:43:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ar9c6-00035O-8O for multi6-data@psg.com; Thu, 12 Feb 2004 05:42:14 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Ar9c2-00034y-Sv for multi6@ops.ietf.org; Thu, 12 Feb 2004 05:42:11 +0000 Received: (qmail 38739 invoked from network); 12 Feb 2004 05:58:09 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 12 Feb 2004 05:58:09 -0000 Message-ID: <402B1299.7000204@necom830.hpcl.titech.ac.jp> Date: Thu, 12 Feb 2004 14:43:53 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Multi6 List Subject: Re: Draft agenda for Seoul References: <04DB11FD-5BBF-11D8-B31A-000A95928574@kurtis.pp.se> <3B746C1E-5BCE-11D8-A88A-000A95928574@kurtis.pp.se> In-Reply-To: <3B746C1E-5BCE-11D8-A88A-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; > WEDNESDAY, March 3, 2004 > 0900-1130 Morning Sessions > =========================== > > 1. Agenda bashing 5 > 2. Charter review 15 > 3. Short intros to NEW drafts 20 min > draft-ohta-multi6-threats-00.txt > draft-ohta-multi6-8plus8-00.txt > draft-ohira-multi6-multilink-auto-prefix-assign-00.txt > draft-ylitalo-multi6-wimp-00.txt Can we introduce our drafts by ourselves? > 5. Architectural analysis, Geoff Houston, 20 mins. Where is the draft? Masataka Ohta From owner-multi6@ops.ietf.org Thu Feb 12 02:32: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 CAA12158 for ; Thu, 12 Feb 2004 02:32:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArBJy-000Ou3-6G for multi6-data@psg.com; Thu, 12 Feb 2004 07:31:38 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArBJp-000OpH-5F for multi6@ops.ietf.org; Thu, 12 Feb 2004 07:31:29 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 60ADA2CF7CC; Thu, 12 Feb 2004 08:31:30 +0100 (CET) In-Reply-To: <402B1299.7000204@necom830.hpcl.titech.ac.jp> References: <04DB11FD-5BBF-11D8-B31A-000A95928574@kurtis.pp.se> <3B746C1E-5BCE-11D8-A88A-000A95928574@kurtis.pp.se> <402B1299.7000204@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <773D7023-5D2D-11D8-A88A-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Draft agenda for Seoul Date: Thu, 12 Feb 2004 08:31:26 +0100 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-12, at 06.43, Masataka Ohta wrote: > Kurt; > >> WEDNESDAY, March 3, 2004 >> 0900-1130 Morning Sessions >> =========================== >> 1. Agenda bashing 5 >> 2. Charter review 15 >> 3. Short intros to NEW drafts 20 min >> draft-ohta-multi6-threats-00.txt >> draft-ohta-multi6-8plus8-00.txt >> draft-ohira-multi6-multilink-auto-prefix-assign-00.txt >> draft-ylitalo-multi6-wimp-00.txt > > Can we introduce our drafts by ourselves? That is the intention. I can add the names of the presenters. > >> 5. Architectural analysis, Geoff Houston, 20 mins. > > Where is the draft? It doesn't say this is a draft presentation. It says it's an analysis. There is an RFC and there is Eliots draft. Both are aimed and providing some guidelines. Me and Brian have asked Geoff among others to review a long list of drafts that have been published over the years and make a first rough analysis. And before this starts out as a new thread - let's see the presentation first, let's discuss AFTER that. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCsr0KarNKXTPFCVEQIeQwCgit9mOO46DfSOZmElk+1tbWIf4sgAoIek GK5k52gXM9EjZGqxle4MAwKw =ysEk -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Feb 12 03:40: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 DAA14351 for ; Thu, 12 Feb 2004 03:40:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArCNC-0007LS-3J for multi6-data@psg.com; Thu, 12 Feb 2004 08:39:02 +0000 Received: from [194.78.143.102] (helo=hrtades9.atea.be) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArCMz-0007KR-EO for multi6@ops.ietf.org; Thu, 12 Feb 2004 08:38:51 +0000 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D5YYB7WP; Thu, 12 Feb 2004 09:38:41 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Feb 2004 09:38:42 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4B8@hrtades7.atea.be> From: Coene Lode To: "'mbagnulo@ing.uc3m.es'" , Coene Lode , john.loughney@nokia.com Cc: multi6@ops.ietf.org Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Thu, 12 Feb 2004 09:38:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk -----Original Message----- From: marcelo bagnulo [mailto:mbagnulo@ing.uc3m.es] Sent: donderdag 5 februari 2004 18:51 To: Coene Lode; john.loughney@nokia.com Cc: multi6@ops.ietf.org Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Hi Coene, > A section in the draft on SCTP multihoming issues deals with that: > - if the host is able to fill in the IP address of the interface on which > the msg is send out, then the return msg will arrive back on that same > interface, not on the others. That mean that for the initial outgoing > message, the source address will belong to the network to which > the host is > sending it, thus any ingress filtering within that network should let it > pass(it is after all the address given out by that network(via DHCP, > fixed...)) > - if the host allows to fill in the IP address of ANY interface as the > source addres of the msg(example : source = IP1, addres of interface on > which msg was actually send out was IP3) then ingress filter > should drop the > message(as should be expected) > This is basically implementation dependant in the host. >What happens when there are multiple addresses (with different prefixes) >assigned to the same interface? Then the IP layers can take a pick of each of the source addresses assigned to the interface. The problem for selecting the "correct" link is then move to the first router which has 2 different links toward the destination. That router has then to route the packet towards the link where the packet won't be dropped by the ingress filtering. Thus the router would be doing its routing based on the source address. If ISP1 gave out IP1(or the prefix for IP1), then if a packet shows up with source address = IP1 it must route the packet onto the link to ISP1. If on the other hand IP3 was the source of the packet, then the packet must be routed through the ISP which supplied the IP address/prefix for IP3. Once again, that is something that SCTP cannot do, it is routing which has to do this. It is maybe a rule that needs to be described more in detail. Yours sincerely, Lode From owner-multi6@ops.ietf.org Thu Feb 12 04:52: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 EAA16936 for ; Thu, 12 Feb 2004 04:52:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArDUv-000JT0-LA for multi6-data@psg.com; Thu, 12 Feb 2004 09:51:05 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1ArDUU-000JMU-Mv for multi6@ops.ietf.org; Thu, 12 Feb 2004 09:50:39 +0000 Received: (qmail 39853 invoked from network); 12 Feb 2004 10:06:40 -0000 Received: from h219-110-032-104.catv01.itscom.jp (HELO necom830.hpcl.titech.ac.jp) (219.110.32.104) by necom830.hpcl.titech.ac.jp with SMTP; 12 Feb 2004 10:06:40 -0000 Message-ID: <402B4CD4.9060805@necom830.hpcl.titech.ac.jp> Date: Thu, 12 Feb 2004 18:52:20 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Multi6 List Subject: Re: Draft agenda for Seoul References: <04DB11FD-5BBF-11D8-B31A-000A95928574@kurtis.pp.se> <3B746C1E-5BCE-11D8-A88A-000A95928574@kurtis.pp.se> <402B1299.7000204@necom830.hpcl.titech.ac.jp> <773D7023-5D2D-11D8-A88A-000A95928574@kurtis.pp.se> In-Reply-To: <773D7023-5D2D-11D8-A88A-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; >>>5. Architectural analysis, Geoff Houston, 20 mins. >>Where is the draft? > It doesn't say this is a draft presentation. It says it's an analysis. > There is an RFC and there is Eliots draft. Both are aimed and providing > some guidelines. Me and Brian have asked Geoff among others to review a > long list of drafts that have been published over the years and make a > first rough analysis. And before this starts out as a new thread - > let's see the presentation first, let's discuss AFTER that. It is a waste of time to here a presentation of someone's analysis on someone else's proposals, when the presenter does not correctly understand the proposals. So, if you ask Geoff make presentation, let him have a chance to let his presentation content reviewed by those who made proposals, IN ADVANCE. Let's have a presentation AFTER that. Otherwise, discussion time is wasted on corrections of the presentation. That is the way to use limited meeting time most efficiently. Masataka Ohta From owner-multi6@ops.ietf.org Thu Feb 12 10:07:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26395 for ; Thu, 12 Feb 2004 10:07:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArIPj-000MgA-Lq for multi6-data@psg.com; Thu, 12 Feb 2004 15:06:03 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArIPi-000Mfv-4L for multi6@ops.ietf.org; Thu, 12 Feb 2004 15:06:02 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 85084727B; Thu, 12 Feb 2004 16:06:01 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp02.uc3m.es (Postfix) with SMTP id 70001726D; Thu, 12 Feb 2004 16:06:01 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Dave Crocker" , "Multi6 List" Subject: CELP (was RE:) Date: Thu, 12 Feb 2004 16:04:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-reply-to: <1719934176.20040211160612@brandenburg.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dave, I am trying to understand this CELP idea, so i have some comments. First, about the Locator Pool concept. The Common Endpoint Locator Pool contains the locators of both endpoints involved in a communication. When a host A is communicating with a host B, the CELP of host A contains both locators from A and locators from B. Additionally, i guess that the CELP has to contain reachability information about each locator (or perhaps about each locator pair, since a destination may be reachable or not depending on the source address used.) Furthermore, some proposals also include information about whether the locator has been verified or not. So the CELP, in a host A, for a communication between A and B, has (at least) the following information: Locator Set of A={LA1,LA2,...,LAn} Locator Set of B={LB1,LB2,...,LBm} Verified Locator Set of B={LVB1,LVB2,...,LVBk} Reachables pairs={(LAi,LVBj) for a certain group of i and j} Do you think that this would be what a LP should contain? Now the idea would be that the CELP is maintained through different means, such as enhanced transport protocols and wedge layer so that if one of them introduces new information in the CELP, this information is available for all the others. In this way, overhead can be reduced since the information is obtained only once and not for every particular mechanism. Now, let's analyze a bit more which information can be provided per each mechanism: Locator Set information: This would be the (unverified) locator set of B There are three types of mechanism that can provide such information: - The enhanced transport layers - The wedge layer - The DNS So the Locator Set of the CELP is feed by these 3 mechanisms, ok. Now, the next relevant information is about address validation. Here is where it starts to get fuzzy for me. Every mechanism can have very different ways to validate a locator. Especially verifications made by transport layers can be weaker because only a connection is at stake, while wedge layer tend to do stronger validations, and even between the different proposals for wedge layer, the strength of the validation varies. Finally, the addresses provided by the DNS have also a different level of validation (which also varies if DNSsec is used) So, i am not so sure that a validated address means the same for the different mechanism, so i see a difficulty in including addresses through different means to be used by all of them. Clearly, the weaker mechanisms can benefit from addresses validated through stronger mechanisms but i doubt that the reverse would be possible. In any way, the first option is possible and it would help to reduce the overhead. Finally, the other relevant information is the reachability information. Reachability means that if you send a packet to a certain destination from a certain source address, a reply is received before a defined timeout. So reachability is related to a destination a source and a timeout. The problem that has already been discussed in the list is that the timeout varies depending on the application. So, a certain source/destination address may be unreachable for some apps but not for others. So we need to include something more specific than an unreachability flag for a source and destination pair. An option could be that the different mechanisms include the timeout value that expired when they decided that a certain source and destination address is unreachable for them. So a SCTP connection is using a certain source and destination address pair and it timeouts after x seconds. It then informs the CELP that this source/dest address pair takes longer than x secs to respond. The next mechanism can see whether this is acceptable and wants to try its luck using it or it is not acceptable. But this is starting to become quite complex, i think. Another option is just to order the potential source/destination address pairs according to the last timeout, so that the one with lower timeout is used first. In any case, i still don't see this very clear. Finally another question is how do identify a CELP is identified. I mean some wedge layer create new id name space, so you can just use the ID pair to identify the CELP, others don't introduce a new id name space, so regular ip addresses are used. Now the new id name space and the IP address space may collide, so a mechanism to uniquely identify a CELP is required. Regards, marcelo > -----Mensaje original----- > De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En > nombre de Dave Crocker > Enviado el: jueves, 12 de febrero de 2004 1:06 > Para: Multi6 List > Asunto: > > > The draft and Avri and I wrote on the SLAP idea is now available: > > > > Title : Framework for Common Endpoint Locator Pools > > Author(s) : D. Crocker > > Filename : draft-crocker-celp-00.txt > > Pages : 10 > > Date : 2004-2-11 > > > > Classic Internet transport protocols use a single source IP Address > > and a single destination IP Address, as part of the identification > > for an individual transport data flow. This is problematic for > > multihomed hosts and for mobile hosts, collectively needing > > 'multiaddressing' support. The basic goal, then, is to find a method > > for multiaddressing that makes the smallest possible change to the > > architecture and to current systems, while maintaining flexibility > > for different emerging solutions. This draft proposes a framework > > for methods for creating Common Endpoint Locator Pools that can be > > used by and among the proposed solutions. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-crocker-celp-00.txt > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > From owner-multi6@ops.ietf.org Thu Feb 12 10:23: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 KAA28142 for ; Thu, 12 Feb 2004 10:23:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArIgA-000P3e-C8 for multi6-data@psg.com; Thu, 12 Feb 2004 15:23:02 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArIfw-000Oyw-6X for multi6@ops.ietf.org; Thu, 12 Feb 2004 15:22:48 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 8EE1F2D084F; Thu, 12 Feb 2004 16:22:51 +0100 (CET) In-Reply-To: <402B4CD4.9060805@necom830.hpcl.titech.ac.jp> References: <04DB11FD-5BBF-11D8-B31A-000A95928574@kurtis.pp.se> <3B746C1E-5BCE-11D8-A88A-000A95928574@kurtis.pp.se> <402B1299.7000204@necom830.hpcl.titech.ac.jp> <773D7023-5D2D-11D8-A88A-000A95928574@kurtis.pp.se> <402B4CD4.9060805@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <5045A1AB-5D6F-11D8-A88A-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Draft agenda for Seoul Date: Thu, 12 Feb 2004 16:22:47 +0100 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-12, at 10.52, Masataka Ohta wrote: > It is a waste of time to here a presentation of someone's analysis > on someone else's proposals, when the presenter does not correctly > understand the proposals. > You are not obliged to listen to that part. :-) Seriously, if Geoff or anybody else can't make out how a proposal is supposed to work from the drafts submitted - then we have other problems. Again, let's have this discussion after Seoul - or off list. Not here. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQCuaSqarNKXTPFCVEQJ8LACg8irN0yrqBGHFYqcyL4lVxxy14TIAn2VM AeB4g+ElpnXh5FHESNOUBR0L =QkBP -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Feb 12 11:24: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 LAA00930 for ; Thu, 12 Feb 2004 11:24:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArJc4-0005VS-Rl for multi6-data@psg.com; Thu, 12 Feb 2004 16:22:52 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArJc1-0005V8-OY for multi6@ops.ietf.org; Thu, 12 Feb 2004 16:22:49 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1CGVBd21701; Thu, 12 Feb 2004 08:31:11 -0800 Date: Thu, 12 Feb 2004 08:22:42 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1092072812.20040212082242@brandenburg.com> To: "marcelo bagnulo" CC: "Multi6 List" Subject: Re: CELP (was RE:) In-Reply-To: References: <1719934176.20040211160612@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo, (my own comments below. of course, avri might feel differently.) mb> The Common Endpoint Locator Pool contains the locators of both endpoints mb> involved in a communication. mb> When a host A is communicating with a host B, the CELP of host A contains mb> both locators from A and locators from B. yes. mb> Additionally, i guess that the CELP has to contain reachability information mb> about each locator (or perhaps about each locator pair, since a destination mb> may be reachable or not depending on the source address used.) Certainly the Internet has examples of pair-wise UNreachability. And certainly there is concern that the Internet is moving towards more and more of this partitioning. So as you note, a full model must account for that reality. However, I believe that early, simple versions of a CELP implementation may choose _not_ to have pair-wise entries. As you note, there is a good reason for maintaining locator pairs. However I would expect the simpler approach to be adequate for many situations. My point is that that simplifying assumptions are probably useful for early adoption, in order to reduce the barrier to that adoption. mb> Furthermore, some proposals also include information about whether the mb> locator has been verified or not. The fully-general version of a CELP implementation certainly can and should maintain an extensive range of routing table classes of information. mb> There are three types of mechanism that can provide such information: mb> - The enhanced transport layers mb> - The wedge layer mb> - The DNS The 'DNS' reference probably should be something like "external lookup services", with sub-entries, because mobility probably requires a more dynamic Presence-like service. mb> So, i am not so sure that a validated address means the same for the mb> different mechanism, so i see a difficulty in including addresses through mb> different means to be used by all of them. Here, again, I see your point as being entirely correct for the long-term theory of this approach, but I believe a much simpler model can be used initially. Where reality turns out to differ from this simpler model, a conservative choice can be made, such as declaring unreachability. This would be acceptable because the resulting, limited service is still much better than what we have today. mb> Clearly, the weaker mechanisms can benefit from addresses validated through mb> stronger mechanisms but i doubt that the reverse would be possible. In any mb> way, the first option is possible and it would help to reduce the overhead. I think this depends on being able to characterise the different types of validation, so that the practical meaning of "weaker" and "stronger" validation have clear, operational definition and measurement. Only then can we discuss the impact of the differences. mb> The problem that has already been discussed in the list is that the timeout mb> varies depending on the application. This is a good example of the reason this topic is part IP-level and part Transport-level. I've come to believe that it should be modeled as a new, full-fledged architectural layer, taking some from IP and some from IP and adding some new stuff. At any rate, here again I think we can win with a simplied model initially, for easier early adoption. Then it can be enhanced. (By the way, I hope it is clear that I'm not disagreeing with your points. I think it is clear that all of them are correct. I'm only suggesting a divide-and-conquor approach towards dealing with this domain, where we defer whatever complexities we can, to gain early utility. Then we can feed that experience into a later round of enhancement.) mb> Finally another question is how do identify a CELP is identified. I mean mb> some wedge layer create new id name space, so you can just use the ID pair mb> to identify the CELP, others don't introduce a new id name space, so regular mb> ip addresses are used. Well, the CELP discussion on granularity shows different sets of parameters being used to identify different sets of locators. The examples use IP Address as the first level of discrimination. I suppose the different identifiers are necessary for correlation during maintenance activities. I'm not sure they actually affect _use_ of the entries. mb> Now the new id name space and the IP address space may collide, so a mb> mechanism to uniquely identify a CELP is required. collide? huh? d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Feb 12 12:09: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 MAA02741 for ; Thu, 12 Feb 2004 12:09:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArKKR-000AeW-72 for multi6-data@psg.com; Thu, 12 Feb 2004 17:08:43 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArKKP-000AdB-OA for multi6@ops.ietf.org; Thu, 12 Feb 2004 17:08:41 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CC6879707; Thu, 12 Feb 2004 18:08:40 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id B8C659661; Thu, 12 Feb 2004 18:08:40 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Dave Crocker" Cc: "Multi6 List" Subject: RE: CELP (was RE:) Date: Thu, 12 Feb 2004 18:07:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-reply-to: <1092072812.20040212082242@brandenburg.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave, i agree with your divide and conquer approach and providing simple mechanisms initially as a mechanism to facilitate adoption. Moreover, it has to be considered that initially neither applications nor transport (multiaddress capable or not) will be able to fully benefit from CELP since some explicit communication between CELP and transport/wedge layer are required for this i guess. The point then i guess would be to agree on which points can be delayed and which points are required even for a simplified initial version. I will try to comment on this below.... > > mb> Additionally, i guess that the CELP has to contain > reachability information > mb> about each locator (or perhaps about each locator pair, since > a destination > mb> may be reachable or not depending on the source address used.) > > Certainly the Internet has examples of pair-wise UNreachability. And > certainly there is concern that the Internet is moving towards more and > more of this partitioning. So as you note, a full model must account for > that reality. > > However, I believe that early, simple versions of a CELP implementation > may choose _not_ to have pair-wise entries. As you note, there is a good > reason for maintaining locator pairs. However I would expect the simpler > approach to be adequate for many situations. I am not sure that this would be good enough. I mean, the source address used by multihomed sites implies at least the return path and in many scenarios also the forward path (because of the ingress filtering) So, if you don't consider the source address when determining whether a destination address is reachable, you are basically omitting the fault tolerance capabilities of multihoming. Suppose a multihomed site with two ISPs, ISPA and ISPB. Each of the providers has delegated a prefix to the multihomed site, PA and PB. A host H1 within the multihomed site is communicating with a host H2 outside the multihomed site, H1 is using PA:H1 address and H2 has only one address H2. Now the link between the multihomed site and the ISPA fails. Then H2 is reachable using PB:H2 but H2 is not reachable using PA:H1 Bottom line is that if the source address is not considered, fault tolerance capabilities of multihomed are not present, i think. > > mb> Furthermore, some proposals also include information about whether the > mb> locator has been verified or not. > I think i didn't explain myself very properly in the previous posting, sorry for the unclear statement. When i said verified, i was talking about the security verification. My understanding is that first the host learns a set of locators. Then it verifies them using some security mechanism, in order to avoid impersonation, flooding etc. Finally it verifies the reachability of the locators. In this part i was talking about the security verifications, that's why the stronger and weaker language. Some wedge approaches use pretty strong security mechanism, such a public key crypto. Some transport solutions just use a cookie, which may be acceptable because only a connection is at stake Then, what i meant is that i don't think that a locator verified by the transport mechanism will be acceptable for the wedge layer. However, it may be acceptable in the other case around, i.e. a locator verified with PK crypto can be accepted by a solution that relies on cookies. I hope i have explain my concern in a better way this time. About the simplified initial approach, i am not sure if this would be possible here either. > > mb> The problem that has already been discussed in the list is > that the timeout > mb> varies depending on the application. > > This is a good example of the reason this topic is part IP-level and > part Transport-level. I've come to believe that it should be modeled as > a new, full-fledged architectural layer, taking some from IP and some > from IP and adding some new stuff. > > At any rate, here again I think we can win with a simplied model > initially, for easier early adoption. Then it can be enhanced. This is the point where i think that an initial simplified model could be more possible. If one app marks an address pair as unreachable, no matter what unreachble means to the app, may be a simple initial start point. > > (By the way, I hope it is clear that I'm not disagreeing with your > points. I think it is clear that all of them are correct. I'm only > suggesting a divide-and-conquor approach towards dealing with this > domain, where we defer whatever complexities we can, to gain early > utility. Then we can feed that experience into a later round of > enhancement.) > I agree with your approach [...] > mb> Now the new id name space and the IP address space may collide, so a > mb> mechanism to uniquely identify a CELP is required. > > collide? huh? This is just an implementation detail, i guess. But if a wedge layer uses the Hash of the FQDN as the permanent identifier (just to take a random example :-) and the transport layer uses the regular IP address to identify the other endpoint, you have to make sure that these two don't have the same value for different hosts, because if this happens you will have the same identifier for two different hosts when accessing the CELP, but i may be missing something... In any case, i don't think this is unsolvable Regards, marcelo > > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > From owner-multi6@ops.ietf.org Thu Feb 12 14: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 OAA07354 for ; Thu, 12 Feb 2004 14:02:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArM58-0006mv-7h for multi6-data@psg.com; Thu, 12 Feb 2004 19:01:02 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1ArM4r-0006lv-BU for multi6@ops.ietf.org; Thu, 12 Feb 2004 19:00:45 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1CJ96d32220; Thu, 12 Feb 2004 11:09:06 -0800 Date: Thu, 12 Feb 2004 11:00:37 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <3410563986.20040212110037@brandenburg.com> To: "marcelo bagnulo" CC: "Dave Crocker" , "Multi6 List" Subject: Re: CELP (was RE:) In-Reply-To: References: <1092072812.20040212082242@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Marcelo, mb> i agree with your divide and conquer approach and providing simple mb> mechanisms initially as a mechanism to facilitate adoption. ok. however this suggests that the document should have an appendix that contains a discussion of the longer-term issues. that way, any near-term, "expedient" choices will be distinguished. >> However, I believe that early, simple versions of a CELP implementation >> may choose _not_ to have pair-wise entries. As you note, there is a good >> reason for maintaining locator pairs. However I would expect the simpler >> approach to be adequate for many situations. mb> I mean, the source address used by multihomed sites implies at least the mb> return path and in many scenarios also the forward path (because of the mb> ingress filtering) Do other folks also view this as a significant issue _today_? I still operate under the possibly-false view of an Internet that is mostly reachable. Perhaps partitioning is already too much of a problem, for us to ignore this type of fine-grained mechanism? >> mb> Furthermore, some proposals also include information about whether the >> mb> locator has been verified or not. mb> In this part i was talking about the security verifications, that's why the mb> stronger and weaker language. ahh. ok. certainly this is a major point of difference among the different proposals. However I think that it still permits a question about practical importance, for early celp. it is entirely possible that folks will view any reasonable authentication scheme as sufficient, and that it is not important to make distinctions in the strength -- beyond a minimal threshhold, of course. Admittedly, I am biased on this point. I think anything at the level of purpose-built keys is fine, to ensure that later packets are from the same source as the original packet. But not going beyond that type of "weak" authentication. (And, by the way, I personally dislike the use of the word 'weak' for labeling this scheme. the authentication mechanism can be strong. and the contextual assurances can be strong. it is the _global_ _identification_ that is weak or rather, non-existent...) mb> About the simplified initial approach, i am not sure if this would be mb> possible here either. Excellent. We have something to debate, because I want to disagree... (That's a cue for others to contribute.) d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Feb 12 20:51: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 UAA01588 for ; Thu, 12 Feb 2004 20:51:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1ArSRt-000NR7-1l for multi6-data@psg.com; Fri, 13 Feb 2004 01:48:57 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1ArSRp-000NQp-Bj for multi6@ops.ietf.org; Fri, 13 Feb 2004 01:48:53 +0000 Received: (qmail 43888 invoked from network); 13 Feb 2004 02:05:08 -0000 Received: from vaio.hpcl.titech.ac.jp (HELO necom830.hpcl.titech.ac.jp) (131.112.32.134) by necom830.hpcl.titech.ac.jp with SMTP; 13 Feb 2004 02:05:08 -0000 Message-ID: <402C2D6D.1070800@necom830.hpcl.titech.ac.jp> Date: Fri, 13 Feb 2004 10:50:37 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Multi6 List Subject: Re: Draft agenda for Seoul References: <04DB11FD-5BBF-11D8-B31A-000A95928574@kurtis.pp.se> <3B746C1E-5BCE-11D8-A88A-000A95928574@kurtis.pp.se> <402B1299.7000204@necom830.hpcl.titech.ac.jp> <773D7023-5D2D-11D8-A88A-000A95928574@kurtis.pp.se> <402B4CD4.9060805@necom830.hpcl.titech.ac.jp> <5045A1AB-5D6F-11D8-A88A-000A95928574@kurtis.pp.se> In-Reply-To: <5045A1AB-5D6F-11D8-A88A-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt; > You are not obliged to listen to that part. :-) Given that the mailing list is the working gruop, I, like other people who will not attend the meeting, do not have to, which is why draft is required. > Seriously, if Geoff or anybody else can't make out how a proposal is > supposed to work from the drafts submitted - then we have other > problems. We always have that problem, which is why advance draft is required. If you are so sure that Geoff can perfectly understand and evaluate proposals, we, the WG, don't need any discussion on his evaluation. So, let him post presentationmaterial and make his slot 0 minutes long. > Again, let's have this discussion after Seoul - or off list. Not here. There is no point to have presentation, which some of us can not see, then. The mailing list is the working group. Here, the mailing list, is the place for presentation and discussion. Masataka Ohta From owner-multi6@ops.ietf.org Fri Feb 13 09:24: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 JAA10292 for ; Fri, 13 Feb 2004 09:24:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AreDQ-000MIY-Ep for multi6-data@psg.com; Fri, 13 Feb 2004 14:22:48 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AreDP-000MIM-Ba for multi6@ops.ietf.org; Fri, 13 Feb 2004 14:22:47 +0000 Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 8950C1C; Fri, 13 Feb 2004 16:35:32 +0200 (EET) In-Reply-To: <1092072812.20040212082242@brandenburg.com> References: <1719934176.20040211160612@brandenburg.com> <1092072812.20040212082242@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <18CAB1E5-5E30-11D8-A37D-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Pekka Nikander Subject: Re: CELP (was RE:) Date: Fri, 13 Feb 2004 16:22:47 +0200 To: Dave Crocker X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave, > mb> The problem that has already been discussed in the list is that > the timeout > mb> varies depending on the application. > > This is a good example of the reason this topic is part IP-level and > part Transport-level. I've come to believe that it should be modeled as > a new, full-fledged architectural layer, taking some from IP and some > from IP and adding some new stuff. I fully agree with you here. As you wrote, this also means that we will need quite a lot of interaction between various areas at the IETF. And probably lots of experimentation as well. > At any rate, here again I think we can win with a simplied model > initially, for easier early adoption. Then it can be enhanced. > > (... I'm only > suggesting a divide-and-conquor approach towards dealing with this > domain, where we defer whatever complexities we can, to gain early > utility. Then we can feed that experience into a later round of > enhancement.) This is a good approach, IMHO. (I am sorry but I really can't disagree with you at this level. However, I do see a number of potential problem areas as soon as one tries to dive into the details...) --Pekka From owner-multi6@ops.ietf.org Fri Feb 13 20:39: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 UAA19079 for ; Fri, 13 Feb 2004 20:39:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Arok3-000HJx-16 for multi6-data@psg.com; Sat, 14 Feb 2004 01:37:11 +0000 Received: from [134.193.143.155] (helo=kc-msxproto2.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Arok1-000HJk-V1 for multi6@ops.ietf.org; Sat, 14 Feb 2004 01:37:10 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Feb 2004 19:37:09 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.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: celp Date: Fri, 13 Feb 2004 19:37:09 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B029857B2@KC-MAIL4.kc.umkc.edu> Thread-Topic: celp Thread-Index: AcPymw+BUSpVF/jDSSKGocVjzTTn8g== From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: X-OriginalArrivalTime: 14 Feb 2004 01:37:09.0569 (UTC) FILETIME=[0FD0A310:01C3F29B] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable A new signaling protocol for negotiating the LP seems=20 to me like a overhead. Actually, DCCP is exactly=20 designed for that purpose ( negotiate cc schemes for=20 unreliable transfer, security measures and MA support.)=20 So, DCCP is just like celp but includes cc algorithm=20 negotiations. I would rather convince DCCP folks to=20 include a mechanism for sharing LP state (extend MA=20 support for advanced features like sync, granularity,=20 fairness problems) than create a brand new signaling=20 protocol.=20 Also, the draft states something about end point=20 congestion management. The last time, I heard about ecm=20 is sharing congestion related information between flows=20 originated by a single interface (not even a single=20 host.) The existing work on ecm like CM, ensemble TCP=20 and TCP control block interdependence has its own=20 limitations(refer RFC 2140.) The MA support at transport level is not an architectural problem rather a cc related problem. It has effect on retransmission and other things( please check out UD folks=20 research on difficulties in doing simultaneous transfer.) As we expect network level solutions to not have negative impact on aggregation and RT size, it is necessary that=20 transport solutions should show its effect on cc=20 algorithms (particularly RFC 2914.) anyway, both SCTP and DCCP supports MA. TCP needs a better MA support than the options approach. So, if we=20 just fix the TCP issue, i don't see any need for new=20 signaling protocol. Even if so, I can piggyback on DCCP or MIDCOM or NSIS or HIP. From owner-multi6@ops.ietf.org Sat Feb 14 17:56: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 RAA03931 for ; Sat, 14 Feb 2004 17:56:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1As8gO-0007IR-Sy for multi6-data@psg.com; Sat, 14 Feb 2004 22:54:44 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1As8gN-0007I3-F0 for multi6@ops.ietf.org; Sat, 14 Feb 2004 22:54:43 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1EMsjof002688; Sat, 14 Feb 2004 23:54:46 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4017DBF3.1070704@nomadiclab.com> References: <4017DBF3.1070704@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Erik Nordmark , multi6@ops.ietf.org, jari.arkko@ericsson.com, "Vesa Torvinen (JO/LMF)" , Pekka Nikander From: Iljitsch van Beijnum Subject: Re: New multi6 draft: WIMP Date: Sat, 14 Feb 2004 23:54:14 +0100 To: Jukka Ylitalo X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 28-jan-04, at 16:57, Jukka Ylitalo wrote: > We have submitted a new multi6 draft to I-D directory. The draft > defines a Weak Identifier Multihoming Protocol (WIMP), and we wrote it > in order to see how opportunistic/weak authentication methods could be > used to sove the multi6 problem. Ok. This is basically a secure negotiation mechanism. All other aspects of multihoming are only addressed fleetingly, if at all. When a host wants to negotiate new addresses, some info is split into n pieces and sent to n addresses. What happens if less than the full set of n addresses is reachable? I believe there is a problem with the gradual release of secret information (such as hash chains) when a man in the middle can trick both sides to become desynchronized such that side A has two messages in transit, messages M+1 and M+2, with an ealier message being M. M, M+1 and M+2 are protected using hashes X, X+1 and X+2, respectively. Side B can check whether message M+1 is authentic by taking X+1, performing a function over it and determining whether the result is equal to X. However, a man in the middle that already has X+2 could create X+1 and then use this value to create an authentic-looking message M+1. Or am I missing something? From owner-multi6@ops.ietf.org Sat Feb 14 20:46: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 UAA08570 for ; Sat, 14 Feb 2004 20:46:44 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsBKc-0001Kd-Uy for multi6-data@psg.com; Sun, 15 Feb 2004 01:44:26 +0000 Received: from [134.193.143.155] (helo=kc-msxproto2.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsBKb-0001KL-Hp for multi6@ops.ietf.org; Sun, 15 Feb 2004 01:44:25 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sat, 14 Feb 2004 19:44:24 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.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: New multi6 draft: WIMP Date: Sat, 14 Feb 2004 19:44:24 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> Thread-Topic: New multi6 draft: WIMP Thread-Index: AcPzT68jvmUeNQAlTDKZRKpcO/mQwQAEL2mw From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Iljitsch van Beijnum" , "Jukka Ylitalo" Cc: "Erik Nordmark" , , , "Vesa Torvinen \(JO/LMF\)" , "Pekka Nikander" X-OriginalArrivalTime: 15 Feb 2004 01:44:24.0801 (UTC) FILETIME=[3DA58510:01C3F365] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >> We have submitted a new multi6 draft to I-D directory. The draft=20 >> defines a Weak Identifier Multihoming Protocol (WIMP), and=20 >we wrote it=20 >> in order to see how opportunistic/weak authentication=20 >methods could be=20 >> used to sove the multi6 problem. > >Ok. This is basically a secure negotiation mechanism. This is basically a _weak_ secure negotiation mechanism. It would=20 be better if the authors state explicitly the environments it will be used. If I am running an enterprise internet service which is=20 site-MHed for reliability, I won't prefer HIP or WIMP or PBK for=20 secure negotiation. They are useful but only for certain limited=20 scenarios.=20 while HIP depends on a trusted model like DNSSEC, why it does extra=20 work (crypto puzzles) to avoid third party infrastructure? what is=20 the incentive to use such schemes? Although, crypto puzzles work=20 against intruders, are we not penalizing a legitimate user by asking him to waste his CPU cycle? btw, is their any standardized RFC supporting weak authentication=20 methods? RFC 1984 states explicitly that IETF won't knowingly make the protocol weaker. But, it was wrote for a different purpose.=20 anyway, I wish that authors of HIP/WIMP explicitly state the=20 environment in which weak authentication is ok. From owner-multi6@ops.ietf.org Sun Feb 15 04:12: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 EAA02525 for ; Sun, 15 Feb 2004 04:12:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsIIw-0002UC-HW for multi6-data@psg.com; Sun, 15 Feb 2004 09:11:10 +0000 Received: from [134.193.143.155] (helo=kc-msxproto2.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsIIl-0002SY-Pm for multi6@ops.ietf.org; Sun, 15 Feb 2004 09:10:59 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Sun, 15 Feb 2004 03:10:59 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.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: draft-huitema-multi6-hosts-03 Date: Sun, 15 Feb 2004 03:10:58 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B029857B7@KC-MAIL4.kc.umkc.edu> Thread-Topic: Problems with existing provider rooted scheme Thread-Index: AcPsssRUYYl03qrORQ+G3Rfvyo4CngAK3b6DAavCQjA= From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: X-OriginalArrivalTime: 15 Feb 2004 09:10:59.0161 (UTC) FILETIME=[A0546490:01C3F3A3] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > 3.2 Source address selection > [...]=20 > Choosing the source address will affect the reverse path of the > connection, as the source address of the message will become the > destination address of the responses. +-- ISPA --+ S --+ +-- ISPC +-- ISPB --+ S is MH to A&B; A, B and C are inter-connected and engage in private = peering.=20 remember C is not a transit between A and B (although, it is fairly = common to=20 have C accidentally misconfigured as a transit.) The site S lacks a PI = space. S picks a prefix allocated by A, as it gives better performance. In this case, A's aggregation is not broken and hence, it just announces = its prefix to both B and C. B's aggregation is broken and it announces both its own prefix & S's prefix Sa to A&C (assuming we avoided the ingress=20 filtering problem by the magic stuff mentioned in the draft.) ISP C, on = the other hand, will choose a route to S through B and not A (due to longest prefix match.) So, the traffic route can disagree with the AS path = advertised=20 by BGP. It may be due to routine removal of routing information at ISP = level=20 in the name of aggregation, filtering and local policy setting. hence, = it is=20 not possible to predict the reverse path based on the source address = (unless,=20 if we depend on an external measurement system.) As for dest address selection, trying every other prefix is the only = current option. Alternatively, one can think in terms of router level feedback = to end systems about path coditions ( sally floyd's Quickstart proposal can = be=20 easily extended to support such a feature.) But, I presume, we don't = have=20 enough machinery to predict path reliability at router level. If we observe closely, it is hard to do address selection at user level (although, it has more incentive.) else, an external measurement system = (in the form of overlay) can routinely measure the Internet space and can = provide path reliability details. but, it is still hard due to provider centric=20 routing policy control. So, how about this? Lets relegate the address=20 selection problem to providers and just work on multi addressing at = transport level ( for it can act as a hint to provider based selection.) It will = also allow a limited form of user control. =20 From owner-multi6@ops.ietf.org Mon Feb 16 01:53: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 BAA16721 for ; Mon, 16 Feb 2004 01:53:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ascaj-000Fjz-Rp for multi6-data@psg.com; Mon, 16 Feb 2004 06:50:53 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AscaZ-000FgZ-83 for multi6@ops.ietf.org; Mon, 16 Feb 2004 06:50:43 +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 i1G6oL0J028066; Sun, 15 Feb 2004 22:50:22 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i1G6oHQ16059; Mon, 16 Feb 2004 07:50:18 +0100 (MET) Date: Sun, 15 Feb 2004 22:50:19 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: New multi6 draft: WIMP To: Iljitsch van Beijnum Cc: Jukka Ylitalo , Erik Nordmark , multi6@ops.ietf.org, jari.arkko@ericsson.com, "Vesa Torvinen (JO/LMF)" , Pekka Nikander In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > I believe there is a problem with the gradual release of secret > information (such as hash chains) when a man in the middle can trick > both sides to become desynchronized such that side A has two messages > in transit, messages M+1 and M+2, with an ealier message being M. M, > M+1 and M+2 are protected using hashes X, X+1 and X+2, respectively. > Side B can check whether message M+1 is authentic by taking X+1, > performing a function over it and determining whether the result is > equal to X. However, a man in the middle that already has X+2 could > create X+1 and then use this value to create an authentic-looking > message M+1. Or am I missing something? I don't see why this is a problem when 1) the signalling protocol (which advances the hash element to use/reveal) has at most one outstanding operation 2) the signalling protocol never gives up on an operation - keeps on retransmitting until the host-pair context is abandoned 3) when a new host-pair context is created the initiator picks a new ephemeral ID I that case, the MiTM that appears after the initial exchange can't force either end to reveal an "extra" hash element as you suggest. Erik From owner-multi6@ops.ietf.org Mon Feb 16 03:20: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 DAA04414 for ; Mon, 16 Feb 2004 03:20:23 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsdyL-0000NI-Le for multi6-data@psg.com; Mon, 16 Feb 2004 08:19:21 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsdyK-0000N6-Fe for multi6@ops.ietf.org; Mon, 16 Feb 2004 08:19:20 +0000 Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 2F7991C; Mon, 16 Feb 2004 10:32:05 +0200 (EET) In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List , hipsec@honor.trusecure.com From: Pekka Nikander Subject: About the HIP security model (was Re: New multi6 draft: WIMP) Date: Mon, 16 Feb 2004 10:19:17 +0200 To: "Ayyasamy, Senthilkumar (UMKC-Student)" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Senthil, > while HIP depends on a trusted model like DNSSEC, why it does extra > work (crypto puzzles) to avoid third party infrastructure? The Security Considerations section in the HIP architecture document (currently draft-moskowitz-hip-arch-05.txt) tries to explain this. If it fails, I'd like to get feedback; there is still time to fix that before the draft goes to RFC. Hence, I please read and comment that section. In particular, HIP does not include the crypto puzzle in order to *avoid* third party infrastructure. It does that in order to block a DoS attack where an attacker makes the Responder to make expensive crypto operations (D-H shared key generation and DSA verification) just by sending garbage keys to the Responder. > the incentive to use such schemes? Although, crypto puzzles work > against intruders, are we not penalizing a legitimate user by asking > him to waste his CPU cycle? Unfortunately you cannot avoid such "pay-first-something" schemes in an open network. You don't know whether the Initiator is a legitimate user or a DoS attacker before you check the signature. Unfortunately, checking the signature costs CPU, and therefore it makes sense to ask the user to "pay", or show that it is sincere, by burning some CPU *first*. In other words, you raise the bar for DoS attackers, by slightly penalizing legitimate users. Furthermore, in HIP you can adjust how hard the puzzle is. Hence, as long as you work under normal conditions, you can make the puzzle very easy to solve. As soon as you start to see load, you can change over to a scheme where solving the puzzle requires more CPU. See, e.g., the following paper, for more information. Tuomas Aura, Pekka Nikander, and Jussipekka Leiwo, "DOS-resistant Authentication with Client Puzzles," in Christianson, Malcolm, Crispo, and Roe (Eds.) Security Protocols, 8th International Workshop, Cambridge, UK, April 3-5, 2000; revised papers, LNCS 2133, pp. 170-177, Springer 2001. > btw, is their any standardized RFC supporting weak authentication > methods? My understanding of "weak" authentication is that the whole area is pretty new. In fact, it looks like that we launched the term in our paper a couple of years ago: Jari Arkko and Pekka Nikander, "How to Authenticate Unknown Principals without Trusted Parties," to appear in Proceedings of Security Protocols Workshop 2002, Cambridge, UK, April 16-19, 2002. Mobile IPv6 RO depends on a "weak authentication" method, RR. Other than that, I don't know, but I may be just ignorant. > anyway, I wish that authors of HIP/WIMP explicitly state the > environment in which weak authentication is ok. draft-moskowitz-hip-arch-05.txt tries to discuss this form the HIP point of view. Again, if you find that discussion lacking or confusing, please let me know in which ways. If you could suggest improvements, that would be even better. --Pekka N. From owner-multi6@ops.ietf.org Mon Feb 16 03:40: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 DAA05745 for ; Mon, 16 Feb 2004 03:40:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AseIY-0002HK-Az for multi6-data@psg.com; Mon, 16 Feb 2004 08:40:14 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AseIW-0002Gx-Pa for multi6@ops.ietf.org; Mon, 16 Feb 2004 08:40:13 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1G8eeof029652; Mon, 16 Feb 2004 09:40:40 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: New multi6 draft: WIMP Date: Mon, 16 Feb 2004 09:40:10 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 16-feb-04, at 7:50, Erik Nordmark wrote: > I don't see why this is a problem when > 1) the signalling protocol (which advances the hash element to > use/reveal) > has at most one outstanding operation I think this is harder than it would at first glance seem. For instance, if a MitM can trigger both ends to start an exchange at approximately the same time. This is why I chose to exchange a key in cleartext in my ODT draft in the absense of strong authentication. From owner-multi6@ops.ietf.org Mon Feb 16 03:53: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 DAA06136 for ; Mon, 16 Feb 2004 03:53:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AseUo-0003lE-9b for multi6-data@psg.com; Mon, 16 Feb 2004 08:52:54 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AseUm-0003ky-S1 for multi6@ops.ietf.org; Mon, 16 Feb 2004 08:52:53 +0000 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id B14566A909; Mon, 16 Feb 2004 10:52:51 +0200 (EET) Message-ID: <40308471.5030307@piuha.net> Date: Mon, 16 Feb 2004 10:50:57 +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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ayyasamy, Senthilkumar (UMKC-Student)" Cc: Iljitsch van Beijnum , multi6@ops.ietf.org Subject: Re: About the HIP security model (was Re: New multi6 draft: WIMP) References: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ayyasamy, Senthilkumar (UMKC-Student) wrote: > btw, is their any standardized RFC supporting weak authentication > methods? RFC 1984 states explicitly that IETF won't knowingly make > the protocol weaker. But, it was wrote for a different purpose. > anyway, I wish that authors of HIP/WIMP explicitly state the > environment in which weak authentication is ok. Pekka already pointed to an paper myself and him. But I'd like to add that while we perhaps introduced the term, there are in fact some schemes like that in existing protocols. For instance: o SIP (RFC 3261) uses a leap-of-faith scheme where two callers can learn their public keys on the fly and register them for secure communications for later. o SIP also offers a null authentication challenge-response scheme, which can be used to assure that the peer at least has a valid address. o Mobile IPv6 (in RFC ed queue) uses a weak authentication technique in its "RR" mechanism that protects route optimization binding updates. o SSH uses leap-of-faith when contacting the server for the first time. o ... Anyway, maybe the term "weak authentication" is a bit misleading. We originally used it a little provocatively. But really, the question is not about strength as much it is about the type of authentication. It has been demonstrated in many contexts that "strong" authentication based on some credentials may not actually match at all the requirements of a specific application, and may in fact be less secure than other types of authentication better suited for the application at hand. In HIP, its about the ability to bind all communications to the host identity. This is different, but not at all weaker than authenticating all nodes to some security infrastructure. For instance, I might be able to prove that I am jari.arkko@ericsson.com, but does that entitle me to grab all communications destined to at IP layer? --Jari From owner-multi6@ops.ietf.org Mon Feb 16 05:09: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 FAA09322 for ; Mon, 16 Feb 2004 05:09:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsffQ-000BjG-As for multi6-data@psg.com; Mon, 16 Feb 2004 10:07:56 +0000 Received: from [134.193.143.167] (helo=kc-msxproto1.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsffP-000BiE-AP for multi6@ops.ietf.org; Mon, 16 Feb 2004 10:07:55 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto1.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 04:07:54 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.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: About the HIP security model (was Re: New multi6 draft: WIMP) Date: Mon, 16 Feb 2004 04:07:53 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011082BB@KC-MAIL4.kc.umkc.edu> Thread-Topic: About the HIP security model (was Re: New multi6 draft: WIMP) Thread-Index: AcP0ZZUlmYeQXcB2QUmJDHB9pfpvygACP+xg From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Pekka Nikander" Cc: "Multi6 List" , X-OriginalArrivalTime: 16 Feb 2004 10:07:54.0482 (UTC) FILETIME=[BE6EC520:01C3F474] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >> the incentive to use such schemes? Although, crypto puzzles work >> against intruders, are we not penalizing a legitimate user by asking >> him to waste his CPU cycle? > > In other words, you raise the bar for DoS attackers, by slightly=20 > penalizing legitimate users. =20 =20 IMO, HIP is a great choice for mobility/wireless scenarios( otoh, it has to depend on something else for providing reliability.) But, one cannot=20 expect a PDA/mobile device to burn cycles for solving the puzzle. In a=20 wired-cum-wireless case, wired nodes are better placed than wireless=20 nodes ( wrt CPU cycles.) Also, imagine a scenario where an attacker has high CPU power and a legitimate user on a low end system. So, I would expect the puzzle to vary depending on the CPU power (i.e. if high CPU=20 power...it should solve fast.) I did see a work by MSR Penny Black folks = addressing this aspect. =20 >> btw, is their any standardized RFC supporting weak authentication >> methods? >=20 > My understanding of "weak" authentication is that the whole > area is pretty new. In fact, it looks like that we launched > the term in our paper a couple of years ago: =20 The term is introduced by your paper. But, it is pretty common to see research works in ad-hoc networks using weak authentication scheme.=20 e.g., Ross Anderson's Resurrecting Duckling model. But, i agree, the=20 security protocol 2002 survey paper is the widely cited one. I was=20 just curious to know about IETF related works using weak authentication. = thanks to both you and jari for the detailed replies.=20 =20 I would respond for the remaining parts of the mail after reading the=20 HIP arch draft. =20 =20 From owner-multi6@ops.ietf.org Mon Feb 16 05:25: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 FAA09876 for ; Mon, 16 Feb 2004 05:25:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsfwE-000Dmv-UG for multi6-data@psg.com; Mon, 16 Feb 2004 10:25:18 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsfwD-000DkQ-HX for multi6@ops.ietf.org; Mon, 16 Feb 2004 10:25:17 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 535EF2D9904; Mon, 16 Feb 2004 11:25:18 +0100 (CET) In-Reply-To: <3410563986.20040212110037@brandenburg.com> References: <1092072812.20040212082242@brandenburg.com> <3410563986.20040212110037@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <68864437-606A-11D8-A0B4-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: "marcelo bagnulo" , "Multi6 List" , "Dave Crocker" From: Kurt Erik Lindqvist Subject: Re: CELP (was RE:) Date: Mon, 16 Feb 2004 11:25:14 +0100 To: Dave Crocker X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> However, I believe that early, simple versions of a CELP >>> implementation >>> may choose _not_ to have pair-wise entries. As you note, there is a >>> good >>> reason for maintaining locator pairs. However I would expect the >>> simpler >>> approach to be adequate for many situations. > > mb> I mean, the source address used by multihomed sites implies at > least the > mb> return path and in many scenarios also the forward path (because > of the > mb> ingress filtering) > > Do other folks also view this as a significant issue _today_? > > I still operate under the possibly-false view of an Internet that is > mostly reachable. Perhaps partitioning is already too much of a > problem, > for us to ignore this type of fine-grained mechanism? This is very much the world of *today*. And I think we will have to assume that for layer9+ reasons the world of tomorrow will have to look similar, unless the concerns can be met in other ways. > mb> About the simplified initial approach, i am not sure if this would > be > mb> possible here either. > > Excellent. We have something to debate, because I want to disagree... I am not sure I follow what you are arguing here. Are you saying that just proving the identity of the other end from connection establishment until session termination is enough? I.e no global verification, just "continuity" verification? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDCajKarNKXTPFCVEQLyggCg6sTRF9rGlddIeflNmVVP6izKMUkAoPqW IkNasMhgKJ4Ey9cBG5QlVVS8 =5rlM -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 16 05:26: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 FAA09930 for ; Mon, 16 Feb 2004 05:26:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asfx5-000Dtm-RY for multi6-data@psg.com; Mon, 16 Feb 2004 10:26:11 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asfx4-000DtQ-UV for multi6@ops.ietf.org; Mon, 16 Feb 2004 10:26:11 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id CC89E2D991A; Mon, 16 Feb 2004 11:26:11 +0100 (CET) In-Reply-To: <402C2D6D.1070800@necom830.hpcl.titech.ac.jp> References: <04DB11FD-5BBF-11D8-B31A-000A95928574@kurtis.pp.se> <3B746C1E-5BCE-11D8-A88A-000A95928574@kurtis.pp.se> <402B1299.7000204@necom830.hpcl.titech.ac.jp> <773D7023-5D2D-11D8-A88A-000A95928574@kurtis.pp.se> <402B4CD4.9060805@necom830.hpcl.titech.ac.jp> <5045A1AB-5D6F-11D8-A88A-000A95928574@kurtis.pp.se> <402C2D6D.1070800@necom830.hpcl.titech.ac.jp> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <87E63B09-606A-11D8-A0B4-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Draft agenda for Seoul Date: Mon, 16 Feb 2004 11:26:07 +0100 To: Masataka Ohta X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-13, at 02.50, Masataka Ohta wrote: > >> You are not obliged to listen to that part. :-) > > Given that the mailing list is the working gruop, I, like other > people who will not attend the meeting, do not have to, which > is why draft is required. > I am sure we will see the presentation as well as all other material sent here as well. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDCawqarNKXTPFCVEQJKLgCgxZiUF1XKu9u5iwXXp0WeN82dNuwAn3zz FGWpi1p4KbGwD5BYTk3YHk1f =0HL8 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 16 05:27: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 FAA09987 for ; Mon, 16 Feb 2004 05:27:00 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asfxn-000Dyt-Nt for multi6-data@psg.com; Mon, 16 Feb 2004 10:26:55 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asfxk-000Dy8-7G for multi6@ops.ietf.org; Mon, 16 Feb 2004 10:26:52 +0000 Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 5EE051C; Mon, 16 Feb 2004 12:39:37 +0200 (EET) In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B011082BB@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B011082BB@KC-MAIL4.kc.umkc.edu> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Multi6 List" , From: Pekka Nikander Subject: Re: About the HIP security model (was Re: New multi6 draft: WIMP) Date: Mon, 16 Feb 2004 12:26:49 +0200 To: "Ayyasamy, Senthilkumar (UMKC-Student)" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > ... So, I would > expect the puzzle to vary depending on the CPU power (i.e. if high CPU > power...it should solve fast.) I did see a work by MSR Penny Black > folks > addressing this aspect. We did consider Mike Burrow's memory bound functions about a year ago, after their publication at NDSS. However, the general feeling was that they were too new (too little analysis) and too unclear from IPR point of view. Hence, the decision back then was to use SHA-1 for now. Of course, the decision can be reversed if it becomes clear that the memory bound functions (or some other form of puzzles) works better, and is sufficiently IPR free. --Pekka N. From owner-multi6@ops.ietf.org Mon Feb 16 05:41: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 FAA10232 for ; Mon, 16 Feb 2004 05:41:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsgBw-000Gp3-Ry for multi6-data@psg.com; Mon, 16 Feb 2004 10:41:32 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsgBt-000Gob-U1 for multi6@ops.ietf.org; Mon, 16 Feb 2004 10:41:30 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id 2B4C4212C92; Mon, 16 Feb 2004 12:41:29 +0200 (EET) Message-ID: <40309CF5.2040809@nomadiclab.com> Date: Mon, 16 Feb 2004 12:35:33 +0200 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20040114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ayyasamy, Senthilkumar (UMKC-Student)" Cc: Iljitsch van Beijnum , Erik Nordmark , multi6@ops.ietf.org, jari.arkko@ericsson.com, "Vesa Torvinen (JO/LMF)" , Pekka Nikander Subject: Re: New multi6 draft: WIMP References: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B029857B6@KC-MAIL4.kc.umkc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Ayyasamy, Senthilkumar (UMKC-Student) wrote: >This is basically a _weak_ secure negotiation mechanism. It would >be better if the authors state explicitly the environments it will >be used. If I am running an enterprise internet service which is >site-MHed for reliability, I won't prefer HIP or WIMP or PBK for >secure negotiation. They are useful but only for certain limited >scenarios. > > > Using WIMP and HIP, it is possible that routers rewrite source locators. However, either of the drafts does not explicitly mention that. Basically, we have several promising protocol proposals, each of them emphasizing different issues in the protocol design. Basically, the multi6 proposals can be divided into two dimensions. The best solution migth be somewhere in the middle of the axis. In the first axis, there are protocols that do not directly co-operate with the routing protocols, or middle-boxes. The protocols are implemented at the end-hosts. On the other end of that axis, there are protocols having "build-in" public key based security, including encryption and integrity protection, like HIP does. The opposite end of the axis contains protocols, like MAST, that basis their security finally on, e.g., IKE. WIMP lies in the middle, offering so called weak "build-in" security properties. The second axis of coordinates consists of protocols that co-operate with the routing protocols. The protocols require changes in the site-routers, and optionally in the global routing tables. From the WIMP point of view, an attractive combination would consist features of MAST, NOID, SLAP, HIP and WIMP. >while HIP depends on a trusted model like DNSSEC, why it does extra >work (crypto puzzles) to avoid third party infrastructure? what is >the incentive to use such schemes? Although, crypto puzzles work >against intruders, are we not penalizing a legitimate user by asking >him to waste his CPU cycle? > > > Pekka N. already answered these questions. >btw, is their any standardized RFC supporting weak authentication >methods? RFC 1984 states explicitly that IETF won't knowingly make >the protocol weaker. But, it was wrote for a different purpose. >anyway, I wish that authors of HIP/WIMP explicitly state the >environment in which weak authentication is ok. > > > > Weak authentication gives protection against several re-direction attacks. At the same time it does not consume much CPU time. WIMP does not offer encryption, but a limited integrity protection against MitM attacks. When a server does not require public key or pre-shared secret based authentication, but is worried about re-direction attacks, WIMP is a good candidate. Br, Jukka From owner-multi6@ops.ietf.org Mon Feb 16 06:12: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 GAA11565 for ; Mon, 16 Feb 2004 06:12:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsgeW-000Ksa-0B for multi6-data@psg.com; Mon, 16 Feb 2004 11:11:04 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsgeT-000Krz-Cb for multi6@ops.ietf.org; Mon, 16 Feb 2004 11:11:01 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id 4C273212C92; Mon, 16 Feb 2004 13:11:00 +0200 (EET) Message-ID: <4030A3E0.7010306@nomadiclab.com> Date: Mon, 16 Feb 2004 13:05:04 +0200 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20040114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: Erik Nordmark , multi6@ops.ietf.org, jari.arkko@ericsson.com, "Vesa Torvinen (JO/LMF)" , Pekka Nikander Subject: Re: New multi6 draft: WIMP References: <4017DBF3.1070704@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > > Ok. This is basically a secure negotiation mechanism. All other > aspects of multihoming are only addressed fleetingly, if at all. Hi Iljitsch, The same phrase applies to several multi-homing I-Ds conversely. "Ok. This is a multi-homing mechanism. All aspects of security are only addresses fleetingly, if at all" :-) The main purpose of the WIMP is to present a way to protect hosts from re-direction attacks. I don't believe that using IKE nor IPSec are the best ways to solve the re-direction problem. WIMP offers a weak, but sufficient security model for multi-homing. We are willing to combine the presented WIMP exchange with other multi6 ideas. Multi-homing architecture is a puzzle. Our purpose is to bring a couple of new pieces to the puzzle that might complete the final solution. I believe that the final solution contains features of several proposals. > > When a host wants to negotiate new addresses, some info is split into > n pieces and sent to n addresses. What happens if less than the full > set of n addresses is reachable? > WIMP works fine also in that case. Let's say that the responder receives a set of new IP addresses, IP1, IP2, and IP3. It sends a challenge to each of them. However, IP2 is not reachable. The initiator reveices only messages with IP1 and IP3. It constructs a combined key using the received key pieces in the challenge messages and sends a response to the responder. The responder finds out which of the challenge messages the initiator received, using the key mask. The responder is able to verify the answer to the challenge using the combined key. That part of the draft requires clarification. Thanks! -- Jukka From owner-multi6@ops.ietf.org Mon Feb 16 06:14:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11617 for ; Mon, 16 Feb 2004 06:14:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asgi0-000LKS-SP for multi6-data@psg.com; Mon, 16 Feb 2004 11:14:40 +0000 Received: from [134.193.143.155] (helo=kc-msxproto2.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asghz-000LK9-5d for multi6@ops.ietf.org; Mon, 16 Feb 2004 11:14:39 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 05:14:38 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.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: CELP (was RE:) Date: Mon, 16 Feb 2004 05:14:36 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011082BC@KC-MAIL4.kc.umkc.edu> Thread-Topic: CELP (was RE:) Thread-Index: AcP0eFLu+d+zvujYT9qg7eXIIwemgQAAR5HA From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Kurt Erik Lindqvist" , "Dave Crocker" Cc: "marcelo bagnulo" , "Multi6 List" , "Dave Crocker" X-OriginalArrivalTime: 16 Feb 2004 11:14:38.0593 (UTC) FILETIME=[11119F10:01C3F47E] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >> I still operate under the possibly-false view of an Internet that is >> mostly reachable. Perhaps partitioning is already too much of a >> problem, >> for us to ignore this type of fine-grained mechanism? > > This is very much the world of *today*.=20 =20 If by "partition" dave meant "topology parition", it is very minimal. The so-called dark or murky address space are well studied by arbor network group (labovitz et all.) Dark address space is reachable through one provider, but not accessible through some other providers. It is due to broad band customers. The murky address space is due to misconfiguration or use of 1918 address space or reserved ones. I did some measurements last year and found it to be very minimal(which=20 you can find in caida ISMA 02 workshop.)=20 =20 anyway, i am still puzzled by the whole partition argument. In 9/11 case, operators did reroute traffic although many outages were observed in the NY area ( verio's junction got busted?) But, overall reachability = was fine. OTOH, new sites had flash crowd problem. Hence, it is very=20 essential for enterprise services to multihome and load balance/fail=20 over across geographically distributed data centers.=20 =20 content distribution networks presents a legitimate partition case=20 where certain prefix can be reached by a subset of nodes and not by=20 others.=20 =20 or, you mean black holes, port blocking etc contribute to partitions? =20 As a side note, how is HIP going to allow port blocking? Will it avoid worm attacks by its puzzle mechanism. I don't think it is possible (but it can reduce its spawning speed.) =20 From owner-multi6@ops.ietf.org Mon Feb 16 06:24: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 GAA11786 for ; Mon, 16 Feb 2004 06:24:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsgqX-000MSa-Fo for multi6-data@psg.com; Mon, 16 Feb 2004 11:23:29 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsgqR-000MS8-Qe for multi6@ops.ietf.org; Mon, 16 Feb 2004 11:23:24 +0000 Received: from nomadiclab.com (n45.nomadiclab.com [131.160.193.45]) by n2.nomadiclab.com (Postfix) with ESMTP id 2E0D4212C93; Mon, 16 Feb 2004 13:23:23 +0200 (EET) Message-ID: <4030A6C7.7030909@nomadiclab.com> Date: Mon, 16 Feb 2004 13:17:27 +0200 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20040114 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 List Subject: Re: New multi6 draft: WIMP References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Iljitsch van Beijnum wrote: > On 16-feb-04, at 7:50, Erik Nordmark wrote: > >> I don't see why this is a problem when >> 1) the signalling protocol (which advances the hash element to >> use/reveal) >> has at most one outstanding operation > > > I think this is harder than it would at first glance seem. For > instance, if a MitM can trigger both ends to start an exchange at > approximately the same time. > > This is why I chose to exchange a key in cleartext in my ODT draft in > the absense of strong authentication. > > > > Hi Iljitsch, The ephemeral IDs of the initiators protect the hosts in the case they start the exchange at the same time. In other words, it is not possible that two initiator's have identical hash chains and common context in both end-points. If I didn't give an answer to the problem, could you elaborate the scenario. (I am currently reading your ODT draft.) Thanks, Jukka From owner-multi6@ops.ietf.org Mon Feb 16 06:28: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 GAA11942 for ; Mon, 16 Feb 2004 06:28:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asgv9-000N28-Bh for multi6-data@psg.com; Mon, 16 Feb 2004 11:28:15 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asgv8-000N1p-H2 for multi6@ops.ietf.org; Mon, 16 Feb 2004 11:28:14 +0000 Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 88A431C; Mon, 16 Feb 2004 13:40:59 +0200 (EET) In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B011082BC@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B011082BC@KC-MAIL4.kc.umkc.edu> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <341E9474-6073-11D8-A37D-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List , hipsec@honor.trusecure.com From: Pekka Nikander Subject: HIP firewalling Date: Mon, 16 Feb 2004 13:28:11 +0200 To: "Ayyasamy, Senthilkumar (UMKC-Student)" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Senthil, > As a side note, how is HIP going to allow port blocking? Will it avoid > worm attacks by its puzzle mechanism. I don't think it is possible (but > it can reduce its spawning speed.) You can build a HIP firewall that uses HIs as the level of granularity. Beyond that, on the port level, you have to do locally at the host. But that's the right way to do it anyway, IMHO. The current worms and other internet fauna are a problem that SHOULD NOT be handled at the network level but by the operating system. Do you expect to run HIP in your Win98 box? --Pekka N. From owner-multi6@ops.ietf.org Mon Feb 16 06:30: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 GAA12047 for ; Mon, 16 Feb 2004 06:30:14 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asgwx-000NQ7-AE for multi6-data@psg.com; Mon, 16 Feb 2004 11:30:07 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asgwv-000NPg-Ky for multi6@ops.ietf.org; Mon, 16 Feb 2004 11:30:05 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C1D218CF4; Mon, 16 Feb 2004 12:30:04 +0100 (CET) Received: from lolo (unknown [163.117.139.223]) by smtp03.uc3m.es (Postfix) with SMTP id A5B178CE9; Mon, 16 Feb 2004 12:30:04 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Ayyasamy, Senthilkumar (UMKC-Student)" , Subject: RE: draft-huitema-multi6-hosts-03 Date: Mon, 16 Feb 2004 12:28:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B029857B7@KC-MAIL4.kc.umkc.edu> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Senthilkumar, thanks for reading and commenting the draft. below... > > > 3.2 Source address selection > > [...] > > Choosing the source address will affect the reverse path of the > > connection, as the source address of the message will become the > > destination address of the responses. > > > +-- ISPA --+ > S --+ +-- ISPC > +-- ISPB --+ > > S is MH to A&B; A, B and C are inter-connected and engage in > private peering. > remember C is not a transit between A and B (although, it is > fairly common to > have C accidentally misconfigured as a transit.) The site S lacks > a PI space. > S picks a prefix allocated by A, as it gives better performance. Well, this is what mh sites do in IPv6, but this has the problem of adding routes to the global routing table, so Host Centric multihoming for IPv6 proposes otherwise. In this case, the mh site will have TWO prefixes one per ISP and will have to select which one to use. Each ISP only announces its own aggregate (no additional more specific routes to describe mh sites) So none of the ISP aggregation is broken This implies that each prefix is only routed through a single ISP and not any of them as in IPv4 This is why the source address selected determines the return path. > > In this case, A's aggregation is not broken and hence, it just > announces its > prefix to both B and C. B's aggregation is broken and it announces both > its own prefix & S's prefix Sa to A&C (assuming we avoided the ingress > filtering problem by the magic stuff mentioned in the draft.) > ISP C, on the > other hand, will choose a route to S through B and not A (due to longest > prefix match.) So, the traffic route can disagree with the AS > path advertised > by BGP. It may be due to routine removal of routing information > at ISP level > in the name of aggregation, filtering and local policy setting. > hence, it is > not possible to predict the reverse path based on the source > address (unless, > if we depend on an external measurement system.) see above. Note that when i mention the return path, i am really only considering which one of the ISPs of the multihomed site will be used by return packets. Other parts of the the return path are out of the reach of the multihomed site. > > As for dest address selection, trying every other prefix is the > only current > option. Alternatively, one can think in terms of router level feedback to > end systems about path coditions ( sally floyd's Quickstart > proposal can be > easily extended to support such a feature.) But, I presume, we don't have > enough machinery to predict path reliability at router level. > > If we observe closely, it is hard to do address selection at user level > (although, it has more incentive.) else, an external measurement > system (in > the form of overlay) can routinely measure the Internet space and > can provide > path reliability details. but, it is still hard due to provider centric > routing policy control. So, how about this? Lets relegate the address > selection problem to providers and just work on multi addressing > at transport > level ( for it can act as a hint to provider based selection.) It > will also > allow a limited form of user control. > Well, there are two different scenarios to consider IMHO. In one case, you have the upgraded transport layers or even applications that are aware that multiple prefixes are available and know how to manage them. This type of transport and apps will be able to really benefit from multiple paths. Host centric proposal does not preclude that. If the transport or app selects a single source and destination address, the IP layer of a host implementing host centric multihoming will honor this selection. So, no problem with your approach and host centric multihoming, i guess. The other case is when neither the app nor the transport is capable of handling multiple locators, just imaging most of the current apps and transport. In this case the app or the transport is only capable of sending packets to a given destination and it may retry when the selected destination is unreachable. Host centric multihoming goal is to provide multihoming benefits in this scenarios, without requiring modifications to transport, nor apps nor external hosts. Regards, marcelo > > > From owner-multi6@ops.ietf.org Mon Feb 16 06:37: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 GAA12258 for ; Mon, 16 Feb 2004 06:37:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ash3X-000OoL-TF for multi6-data@psg.com; Mon, 16 Feb 2004 11:36:55 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ash3X-000Oo3-1w for multi6@ops.ietf.org; Mon, 16 Feb 2004 11:36:55 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 588EE8E41; Mon, 16 Feb 2004 12:36:54 +0100 (CET) Received: from lolo (unknown [163.117.139.223]) by smtp03.uc3m.es (Postfix) with SMTP id 440248DE9; Mon, 16 Feb 2004 12:36:54 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Dave Crocker" Cc: "Multi6 List" Subject: RE: CELP (was RE:) Date: Mon, 16 Feb 2004 12:35:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3410563986.20040212110037@brandenburg.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I still operate under the possibly-false view of an Internet that is > mostly reachable. Perhaps partitioning is already too much of a problem, > for us to ignore this type of fine-grained mechanism? Well, the point here is what part of the internet is reachable trough each one of the IPS that serve the multihomed site So, I agree that a partition of the Internet is not likely, but this is not my concern. A site becomes multihomed becuase it wants to improve its fault tolerance. This means that if the site were single homed, some parts of the Internet would be unreachable for him, so he wants to overcome this problem by multihoming So, i think i don't agree with the assumption that the internet is mostly reachable, because if this were so, why would sites multihome in the first place? But i am probably missing something here.... Reagrds, marcelo From owner-multi6@ops.ietf.org Mon Feb 16 06:39: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 GAA12318 for ; Mon, 16 Feb 2004 06:39:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ash6B-000Pd3-Gj for multi6-data@psg.com; Mon, 16 Feb 2004 11:39:39 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ash6A-000Pcp-Fm for multi6@ops.ietf.org; Mon, 16 Feb 2004 11:39:38 +0000 Received: from localhost (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with SMTP id CCCCA9E5E; Mon, 16 Feb 2004 12:39:37 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id A8BFC9DF1; Mon, 16 Feb 2004 12:39:31 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: , "Ayyasamy, Senthilkumar (UMKC-Student)" , Subject: RE: draft-huitema-multi6-hosts-03 Date: Mon, 16 Feb 2004 12:37:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I made a typo here: > Well, this is what mh sites do in IPv6, but this has the problem of adding ^^ I meant IPv4. Sorry, regards, marcelo From owner-multi6@ops.ietf.org Mon Feb 16 06:48: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 GAA12621 for ; Mon, 16 Feb 2004 06:48:11 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AshE3-0000wK-RC for multi6-data@psg.com; Mon, 16 Feb 2004 11:47:47 +0000 Received: from [134.193.143.155] (helo=kc-msxproto2.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AshE2-0000w3-MT for multi6@ops.ietf.org; Mon, 16 Feb 2004 11:47:46 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211]) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 05:47:46 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.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: HIP firewalling Date: Mon, 16 Feb 2004 05:47:45 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011082BD@KC-MAIL4.kc.umkc.edu> Thread-Topic: HIP firewalling Thread-Index: AcP0f/gtUE5CZQ06QEW7AuzNTT0hFAAAD3Jn From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Pekka Nikander" Cc: "Multi6 List" , X-OriginalArrivalTime: 16 Feb 2004 11:47:46.0175 (UTC) FILETIME=[B1C290F0:01C3F482] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable >> As a side note, how is HIP going to allow port blocking? Will it = avoid >> worm attacks by its puzzle mechanism. I don't think it is possible = (but >> it can reduce its spawning speed.) > > You can build a HIP firewall that uses HIs as the level of > granularity. Beyond that, on the port level, you have to > do locally at the host. But that's the right way to do it > anyway, IMHO. The current worms and other internet fauna > are a problem that SHOULD NOT be handled at the network level > but by the operating system. =20 The patch solution has its limitations. If i am a network admin, i have to track the infected hosts, wake up the user, convince them that it is really a problem, then ask him to patch his OS, and then allow the user to play with his machine. It is not a day's work but sometimes goes in the order of months. port blocking will fix the problem quickly, OTOH. So, IAB's recent port blocking concerns did not consider the total=20 picture. > Do you expect to run HIP in your Win98 box? of course. my school just provides windoze machine(and run linux through = emulation,VMware etc.) Is IETF just support non-windoze platforms? ;-) From owner-multi6@ops.ietf.org Mon Feb 16 07:35:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14095 for ; Mon, 16 Feb 2004 07:35:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AshxF-0006kM-Lb for multi6-data@psg.com; Mon, 16 Feb 2004 12:34:29 +0000 Received: from [134.193.143.160] (helo=kc-msxproto3.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AshxC-0006k4-Nr for multi6@ops.ietf.org; Mon, 16 Feb 2004 12:34:26 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 06:34:25 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.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: draft-huitema-multi6-hosts-03 Date: Mon, 16 Feb 2004 06:34:24 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011082BF@KC-MAIL4.kc.umkc.edu> Thread-Topic: draft-huitema-multi6-hosts-03 Thread-Index: AcP0gDr3RaTLnhwXQvCEbOt47vlfAQAB89pj From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: , X-OriginalArrivalTime: 16 Feb 2004 12:34:25.0448 (UTC) FILETIME=[3641BA80:01C3F489] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > Well, this is what mh sites do in IPv6, but this has the problem of = adding > routes to the global routing table, so Host Centric multihoming for = IPv6 > proposes otherwise. > > In this case, the mh site will have TWO prefixes one per ISP and will = have > to select which one to use. =20 I missed this basic concept. I think, this is the easiest of all mh6 = solutions (if we address the ingress filtering problem.) =20 =20 From owner-multi6@ops.ietf.org Mon Feb 16 08:07: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 IAA15287 for ; Mon, 16 Feb 2004 08:07:47 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AsiT7-000Btt-6t for multi6-data@psg.com; Mon, 16 Feb 2004 13:07:25 +0000 Received: from [134.193.143.160] (helo=kc-msxproto3.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AsiT6-000BrO-2H for multi6@ops.ietf.org; Mon, 16 Feb 2004 13:07:24 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 07:07:23 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.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: CELP (was RE:) Date: Mon, 16 Feb 2004 07:07:22 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011082C0@KC-MAIL4.kc.umkc.edu> Thread-Topic: CELP (was RE:) Thread-Index: AcP0gvJdGyiQW3OVTo2LLcTX/kWQswABkvo2 From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: , "Dave Crocker" Cc: "Multi6 List" X-OriginalArrivalTime: 16 Feb 2004 13:07:23.0294 (UTC) FILETIME=[D12513E0:01C3F48D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > A site becomes multihomed becuase it wants to improve its fault = tolerance. > This means that if the site were single homed, some parts of the = Internet > would be unreachable for him, so he wants to overcome this problem by > multihoming >=20 > So, i think i don't agree with the assumption that the internet is = mostly > reachable, because if this were so, why would sites multihome in the = first > place? =20 I agree with you. From a network perspective, Internet is mostly = reachable (although, with associated route churns, convergence delays etc.) But, = from user perspective, failures are common even if you multi home. We should=20 work to cope up with failures, rather than try to avoid them 100% (which = is not at all possible.) In the current Internet, performance was never a=20 bottleneck( reason for lack of incentive to use QoS) only reliability is = the issue. Site-multihoming is one of the many tools to increase FT. =20 some numbers about Internet path failures ( ack to hari balakrishnan): =20 1995 - routing churn at the rate of 3.3% - vern paxson = (sigcomm) 1997 - 10% of available route(< 95% of time) - Labovitz et all = (infocom) 1997 - less than 35% of available route(99.99% of time)- Labovitz et all = (sigcomm) 2000 - 40% of path outage takes 30+ min to repair - Labovitz et all = (sigcomm) 2001 - 5% of faults last more than 2 hrs, 45 min - chandra et all = (IEEE ToN) 2001 - 7.7% of "overlay" path hrs experience 30 min - Andersen et all = ( SOSP) 2002 and later - http://bgp.lcs.mit.edu/ =20 posting quota for multi6 over... =20 =20 =20 =20 =20 From owner-multi6@ops.ietf.org Mon Feb 16 11:40: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 LAA03748 for ; Mon, 16 Feb 2004 11:40:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AslmJ-0004wA-1B for multi6-data@psg.com; Mon, 16 Feb 2004 16:39:27 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AslmH-0004vy-M1 for multi6@ops.ietf.org; Mon, 16 Feb 2004 16:39:25 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1GGlqd23623; Mon, 16 Feb 2004 08:47:52 -0800 Date: Mon, 16 Feb 2004 08:39:13 -0800 From: Dave Crocker Reply-To: dcrocker@brandenburg.com Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <48240229.20040216083913@brandenburg.com> To: "marcelo bagnulo" CC: "Multi6 List" Subject: Re: CELP (was RE:) In-Reply-To: References: <3410563986.20040212110037@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable marcelo, mb> A site becomes multihomed becuase it wants to improve its fault toleran= ce. mb> This means that if the site were single homed, some parts of the Intern= et mb> would be unreachable for him, so he wants to overcome this problem by mb> multihoming In fact, this reason had not occurred to me! I have always assumed that the reliability reason for multihoming was to continue operation when their own interface goes down. That's quite different from a concern over network partitioning, elsewhere. (Geographically distributed multihoming for large organizations is a different matter.) In any event, let me again stress that I am pursuing this kind of issue in order to distinguish near-term, narrow concerns, versus longer-term, general concerns. The hope is that this distinction can allow initial solutions to be simpler. From=20my own sense of the net and from the responses so far, I believe that a host can maintain an address pool based solely on a simple list of the destination's addresses. That is, for the near term, the combinatorial complexities of considering local/remote address pairs can be deferred. Of course, the implications (that is, the limitations) of this simplifying assumption need to be stated. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Feb 16 13:03: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 NAA09168 for ; Mon, 16 Feb 2004 13:03:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asn48-00008x-4H for multi6-data@psg.com; Mon, 16 Feb 2004 18:01:56 +0000 Received: from [66.92.66.146] (helo=alva.home) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asn46-00008l-68 for multi6@ops.ietf.org; Mon, 16 Feb 2004 18:01:54 +0000 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1Asn3z-000079-00; Mon, 16 Feb 2004 13:01:47 -0500 From: Tim Shepard To: "Ayyasamy, Senthilkumar \(UMKC-Student\)" cc: "Multi6 List" Subject: port blocking (was Re: CELP (was RE:) ) In-reply-to: Your message of Mon, 16 Feb 2004 05:14:36 -0600. <5EF7D95E17BDAD4A968C812E5ABC390B011082BC@KC-MAIL4.kc.umkc.edu> Date: Mon, 16 Feb 2004 13:01:47 -0500 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > As a side note, how is HIP going to allow port blocking? Will it avoid > worm attacks by its puzzle mechanism. I don't think it is possible (but > it can reduce its spawning speed.) This is a very interesting question, and I expect there will never be a good answer for this. (The puzzle mechanism does not fundamentally help with worm attacks, though it may help to defend against a DOS attack against a specific server's CPU resources launched by a worm.) How does IPSEC allow port blocking? As far as I know, it does not. After the IKE exchange establishes a SA, ESP hides the TCP port numbers. HIP has no better answer to this question than IPSEC, or any other protocol that provides for encryption between strangers. "Having an encrypted conversation with a stranger may be like meeting that person in a dark alley. Whatever happens, there are no witnesses." (quote is from Blumenthal and Clark, _Rethinking the Design of the Internet: The End-to-End Arguments vs. the Brave New World, August 2001) -Tim Shepard shep@alum.mit.edu From owner-multi6@ops.ietf.org Mon Feb 16 17:10: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 RAA01172 for ; Mon, 16 Feb 2004 17:10:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Asqum-000A3P-MQ for multi6-data@psg.com; Mon, 16 Feb 2004 22:08:32 +0000 Received: from [134.193.143.160] (helo=kc-msxproto3.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Asquh-000A2u-B7 for multi6@ops.ietf.org; Mon, 16 Feb 2004 22:08:27 +0000 Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Feb 2004 16:08:21 -0600 x-mimeole: Produced By Microsoft Exchange V6.5.6944.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: port blocking (was Re: CELP (was RE:) ) Date: Mon, 16 Feb 2004 16:08:03 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B011082C1@KC-MAIL4.kc.umkc.edu> Thread-Topic: port blocking (was Re: CELP (was RE:) ) Thread-Index: AcP0tvX/OG89Q+aoQIeN880M7P3N5QAGmiZg From: "Ayyasamy, Senthilkumar \(UMKC-Student\)" To: "Tim Shepard" Cc: "Multi6 List" X-OriginalArrivalTime: 16 Feb 2004 22:08:21.0728 (UTC) FILETIME=[63E10E00:01C3F4D9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > "Having an encrypted conversation with a stranger may be like meeting = that > person in a dark alley. Whatever happens, there are no witnesses." = (quote > is from Blumenthal and Clark, _Rethinking the Design of the Internet: = The > End-to-End Arguments vs. the Brave New World, August 2001) =20 If you need an architectural principle that allows port blocking but = still encrypt your communication, Dave Clark gave better answers in his follow = up works (not an engineering solution.) He called that as *controlled=20 transparency* - in terms of shared trust among multiple untrusted = parties. =20 The SIGCOMM 02 position paper made an argument for controlled=20 transparency. But, the details are present in his recent FDNA work (section 2.2, 3.2 and 4.1): =20 http://www.isi.edu/newarch/DOCUMENTS/Principles.FDNA03.pdf Clark, D., Sollins, K., Wroclawski, J., and Faber, T.,=20 "Addressing Reality: An Architectural Response to Real-World=20 Demands on the Evolving Internet."=20 ACM SIGCOMM 2003 FDNA Workshop, August 2003.=20 =20 technically, Dave Clark's idea is not deployable unless we support = multiple=20 security levels in the form of layers ( as a first step, provide access=20 control to trusted intermediate routers to read selected portions=20 of the pkt headers in a secure and controlled manner. If so, you need a secure enrollment service between the end system and the trusted = routers.) I am not sure, but the soon-to-be-WG ALIAS should take up these issues. =20 Phil Karn,OTOH, claims that network should just move his happy packets = with control at end user ( check out his recent nanog talk.) =20 =20 =20 From owner-multi6@ops.ietf.org Tue Feb 17 16:17: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 QAA06469 for ; Tue, 17 Feb 2004 16:17:46 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtCZ5-000JO5-UK for multi6-data@psg.com; Tue, 17 Feb 2004 21:15:35 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtCZ2-000JNs-CM for multi6@ops.ietf.org; Tue, 17 Feb 2004 21:15:32 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1HLNld03669; Tue, 17 Feb 2004 13:23:48 -0800 Date: Tue, 17 Feb 2004 13:15:11 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1289992244.20040217131511@brandenburg.com> To: Jukka Ylitalo CC: Iljitsch van Beijnum , Erik Nordmark , , , "Vesa Torvinen (JO/LMF)" , Pekka Nikander Subject: Re: New multi6 draft: WIMP In-Reply-To: <4030A3E0.7010306@nomadiclab.com> References: <4017DBF3.1070704@nomadiclab.com> <4030A3E0.7010306@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Folks, JY> We are willing to combine the presented WIMP exchange with other multi6 JY> ideas. Multi-homing architecture is a puzzle. Our purpose is to bring a JY> couple Some proposals differ from each other at the level of "paradigm". They quite simply approach the solution in a fundamentally different way. However others are variations on the same paradigmatic theme. It seems entirely reasonable to look for the commonality and select from among the proposals. Although the paradigmatic differences probably affect one's list of issues or "modules", my own view is: - Association establishment - Endpoint-pair context identification - Authentication of the control exchange - Updates to the pool of locators for the context - Rendezvous (for mobile targets) - Control exchange transport For those of a like mind, trying to first agree on a common set of such functions would be helpful. It would then let us look for pieces of solution that we can share. (I think this sort of exercise at least will help refine our understanding of the differences.) By way of example, MAST has a very large hand-wave with respect to the details of control exchange authentication. It takes the approach that something of the weak authentication/purpose-built keys approach is sufficient, but leaves the details unstated. It would be great to have a solution that we could simply plug in to that part of the specification. The choice is essential for viable use, of course, but it does not affect the MAST paradigm. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Wed Feb 18 02:27:28 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26727 for ; Wed, 18 Feb 2004 02:27:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtM4K-000CD7-VP for multi6-data@psg.com; Wed, 18 Feb 2004 07:24:28 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtM4I-000CCv-RQ for multi6@ops.ietf.org; Wed, 18 Feb 2004 07:24:27 +0000 Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 0B4BA1C; Wed, 18 Feb 2004 09:37:11 +0200 (EET) In-Reply-To: <1289992244.20040217131511@brandenburg.com> References: <4017DBF3.1070704@nomadiclab.com> <4030A3E0.7010306@nomadiclab.com> <1289992244.20040217131511@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7A90FCAE-61E3-11D8-8D19-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: , , Erik Nordmark , "Vesa Torvinen (JO/LMF)" , Jukka Ylitalo , Iljitsch van Beijnum From: Pekka Nikander Subject: Re: New multi6 draft: WIMP Date: Wed, 18 Feb 2004 09:24:24 +0200 To: Dave Crocker X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dave, > Although the paradigmatic differences probably affect one's list of > issues or "modules", my own view is: As we apparently share the same paradigm, your list looks good to me. Some further thoughts: > - Association establishment An interesting aspect here is the idea of a "staged" association establishment. That is, maybe you could initially just exchange a couple of identifiers and/or hash anchors and check the reachability of the primary address as a side effect. All further checks, i.e. reachability of other addresses, establishing strong identity via public key crypto, etc, could be "delayed" and performed only if needed. > - Endpoint-pair context identification To me, it looks like that we have to look at this on two or perhaps three levels. One is how to identify the context initially, before the end-points have exchanged any messages. The second one is the way the context is identified in the control protocol, and the third one how the context is identified in the actual payload packets. Apparently, some of these may overlap, depending on the details. > - Authentication of the control exchange Here the minimal requirements seem to be covered by Erik's draft (I know that some WG members disagree, but that is at least party due to different paradigm, IMHO.) However, especially if the "staged" association establishment idea is used, it may be possible to introduce more secure ("strong" or "semi-strong" instead of "weak") authentication on demand. > - Updates to the pool of locators for the context > - Rendezvous (for mobile targets) I think that we have to make a distinction between initial rendezvous, or finding a mobile target before there is any association, and rendezvous while there is an active association. And then we have the "third party rendezvous", which I would like to call referral. That is, handing over an identifier (IP address or other) to a third host, so that it can create an association with the identified end-point. > - Control exchange transport > > By way of example, MAST has a very large hand-wave with respect to the > details of control exchange authentication. ... HIP, on the other hand, has very well defined control exchange authentication, but many people consider it too heavy. The "staged" idea might be able to help there. It looks like that HIP is weakest in its handling of the address pool and in some aspects of rendezvous. --Pekka From owner-multi6@ops.ietf.org Wed Feb 18 05:56:54 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05771 for ; Wed, 18 Feb 2004 05:56:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtPMR-0007Qh-UW for multi6-data@psg.com; Wed, 18 Feb 2004 10:55:23 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtPMQ-0007QU-Fe for multi6@ops.ietf.org; Wed, 18 Feb 2004 10:55:22 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 95CD48446; Wed, 18 Feb 2004 11:55:21 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp02.uc3m.es (Postfix) with SMTP id 80BFE8442; Wed, 18 Feb 2004 11:55:21 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Dave Crocker" Cc: Subject: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Wed, 18 Feb 2004 11:53:36 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <1289992244.20040217131511@brandenburg.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Dave, [trim the destination list] > Some proposals differ from each other at the level of "paradigm". They > quite simply approach the solution in a fundamentally different way. > However others are variations on the same paradigmatic theme. It seems > entirely reasonable to look for the commonality and select from among > the proposals. Well, i would also say that different views also are dealing with different problems related with multihoming and the basically focus on different issues. For instance, most of the modules that you describe below are basically focused in preserving established communication through outages in multihomed environments. This is only *one* issue about multihoming. While most of proposals focus on this point (i would say because it is the mist challenging one) this is not the complete multihoming problem. There are many other issues that have to be addressed in order to provide a multihoming solution and which solution it is probably simpler and easier to deploy. Moreover, solving the other simpler issues is likely to be what most of users really need right now. I mean, I would say that there is a significant amount of potential IPv6 multihoming users that don't really have many critical established communications that have to survive a outage that occurred in one of their non directly connected link. (moreover, probably currently IPv4 multihoming solution fails to provide this for many apps in some scenarios where BGP reconvergence takes a while) Please, note that i am not saying that the preservation of established communications is not important, i am just saying that there are other multihoming issues that are also important and that are easier to deploy and that would provide many of the multihoming benefits. Now, returning to the preservation of established communications, i think that there is another module that i would include: locator selection mechanisms. This has at least three issues related: Locator selection for initial contact: you have to discover which locator is available Locator selection during the communication: you have to decide when a locator has become unreachable (at least) Policing: locator selection mechanisms have to provide the means to implement policing Regards, marcelo > > Although the paradigmatic differences probably affect one's list of > issues or "modules", my own view is: > > - Association establishment > - Endpoint-pair context identification > - Authentication of the control exchange > - Updates to the pool of locators for the context > - Rendezvous (for mobile targets) > - Control exchange transport > > For those of a like mind, trying to first agree on a common set of such > functions would be helpful. It would then let us look for pieces of > solution that we can share. (I think this sort of exercise at least > will help refine our understanding of the differences.) > > By way of example, MAST has a very large hand-wave with respect to the > details of control exchange authentication. It takes the approach that > something of the weak authentication/purpose-built keys approach is > sufficient, but leaves the details unstated. > > It would be great to have a solution that we could simply plug in to > that part of the specification. The choice is essential for viable use, > of course, but it does not affect the MAST paradigm. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > > From owner-multi6@ops.ietf.org Wed Feb 18 07:52:58 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08756 for ; Wed, 18 Feb 2004 07:52:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtRAs-000KwV-C5 for multi6-data@psg.com; Wed, 18 Feb 2004 12:51:34 +0000 Received: from [134.193.143.160] (helo=kc-msxproto3.kc.umkc.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtRAl-000KwI-38 for multi6@ops.ietf.org; Wed, 18 Feb 2004 12:51:27 +0000 Received: from your-fn86qv5dxz.umkc.edu ([134.193.24.40] RDNS failed) by kc-msxproto3.kc.umkc.edu with Microsoft SMTPSVC(6.0.3790.0); Wed, 18 Feb 2004 06:51:24 -0600 Message-Id: <6.0.3.0.0.20040218062509.01e31400@imap4.roos.umkc.edu> X-Sender: saq66@imap4.roos.umkc.edu X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 18 Feb 2004 06:46:49 -0600 To: , "Dave Crocker" From: senthil ayyasamy Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) Cc: In-Reply-To: References: <1289992244.20040217131511@brandenburg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 18 Feb 2004 12:51:25.0556 (UTC) FILETIME=[EB1D5B40:01C3F61D] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.9 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk At 11:53 AM 2/18/2004 +0100, marcelo bagnulo wrote: >For instance, most of the modules that you describe below are basically >focused in preserving established communication through outages in >multihomed environments. ... >I mean, I would say that there is a significant amount of potential IPv6 >multihoming users that don't really have many critical established >communications that have to survive a outage that occurred in one of their >non directly connected link. (moreover, probably currently IPv4 multihoming >solution fails to provide this for many apps in some scenarios where BGP >reconvergence takes a while) For now, connection preservation (fail over etc) should be the only goal. LB/multi paths is a difficult problem (both at transport and routing.) It has to be done after multi6 standardization. If we support MA, concurrent multi transfer has to be standardized within tsv. If we support routing based solutions(locator rewriting or BGP related,) load balancing needs an algorithm approach (which should be done within routing area.) OTOH, host centric solutions can depend on DNS for LB etc (which is not a multi6 issue.) or you meant something else? From owner-multi6@ops.ietf.org Wed Feb 18 09:01:13 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11344 for ; Wed, 18 Feb 2004 09:01:12 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtSEw-0003Zn-FG for multi6-data@psg.com; Wed, 18 Feb 2004 13:59:50 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtSEv-0003Zb-2Q for multi6@ops.ietf.org; Wed, 18 Feb 2004 13:59:49 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4228AA978; Wed, 18 Feb 2004 14:59:48 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 15EE7A971; Wed, 18 Feb 2004 14:59:48 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "senthil ayyasamy" , "Dave Crocker" Cc: Subject: RE: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Wed, 18 Feb 2004 14:58:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <6.0.3.0.0.20040218062509.01e31400@imap4.roos.umkc.edu> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > -----Mensaje original----- > De: senthil ayyasamy [mailto:saq66@umkc.edu] > Enviado el: miercoles, 18 de febrero de 2004 13:47 > Para: mbagnulo@ing.uc3m.es; Dave Crocker > CC: multi6@ops.ietf.org > Asunto: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) > > > At 11:53 AM 2/18/2004 +0100, marcelo bagnulo wrote: > >For instance, most of the modules that you describe below are basically > >focused in preserving established communication through outages in > >multihomed environments. > ... > >I mean, I would say that there is a significant amount of potential IPv6 > >multihoming users that don't really have many critical established > >communications that have to survive a outage that occurred in > one of their > >non directly connected link. (moreover, probably currently IPv4 > multihoming > >solution fails to provide this for many apps in some scenarios where BGP > >reconvergence takes a while) > > For now, connection preservation (fail over etc) should be the only goal. > LB/multi paths is a difficult problem (both at transport and routing.) It > has to be done after multi6 standardization. If we support MA, concurrent > multi transfer has to be standardized within tsv. If we support routing > based solutions(locator rewriting or BGP related,) load balancing needs > an algorithm approach (which should be done within routing area.) OTOH, > host centric solutions can depend on DNS for LB etc (which is not a > multi6 issue.) > > or you meant something else? Yes, definitely i meant something else, sorry for being so unclear. Actually i was pointing that there are some simpler problems that can be solved locally at the multihomed site that are also part of the multihoming solution and that would provide important benefits without too much cost. The first issue that has to be addressed is ingress filtering compatibility. If you are using multiple addresses per host and the ISP are implementing ingress filtering, problems appear when a single homed host becomes multihomed. This problems occur even when there is no outage, and may affect communications even when both links are working fine. This implies that a single homed site that becomes multihomed will obtain a degraded performance because of multihoming. so the first step IMHO is that when a site becomes multihomed, it should obtain at least the same benefits as when it was single homed. Then, some mechanisms can provide some benefits of multihoming. For instance, when a outage occurs, hosts within the multihomed site should not use the source address associated with the path that has suffered the outage. Note that this is not related with the preservation of the communication, it is just that when an ISP is down, new communication shouldn't use the associated address. In this case, a certain level of fault tolerance is provided, even if the established communications are not preserved Additionally, selecting the source and destination properly some levels of policing can be provided. IMHO all this is much more simpler than mechanisms to preserve established communications but they provide important benefits. I say that these mechanisms are simpler because they require only modification within the multihomed site and they don't require modification of external hosts. Moreover, some of these mechanisms work fine with non upgraded hosts within the multihomed site. I hope i explain myself more properly this time, sorry for the confusion. Regards, marcelo > From owner-multi6@ops.ietf.org Wed Feb 18 09:57:57 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15425 for ; Wed, 18 Feb 2004 09:57:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtT8o-000Abd-6Q for multi6-data@psg.com; Wed, 18 Feb 2004 14:57:34 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtT8n-000AbQ-1J for multi6@ops.ietf.org; Wed, 18 Feb 2004 14:57:33 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1IF5vd02511; Wed, 18 Feb 2004 07:05:57 -0800 Date: Wed, 18 Feb 2004 06:57:23 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <186354433.20040218065723@brandenburg.com> To: Pekka Nikander CC: multi6@ops.ietf.org, jari.arkko@ericsson.com, Erik Nordmark , "Vesa Torvinen (JO/LMF)" , Jukka Ylitalo , Iljitsch van Beijnum Subject: Re: New multi6 draft: WIMP In-Reply-To: <7A90FCAE-61E3-11D8-8D19-000393CE1E8C@nomadiclab.com> References: <4017DBF3.1070704@nomadiclab.com> <4030A3E0.7010306@nomadiclab.com> <1289992244.20040217131511@brandenburg.com> <7A90FCAE-61E3-11D8-8D19-000393CE1E8C@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka, >> - Association establishment PN> An interesting aspect here is the idea of a "staged" PN> association establishment. ... I like this idea quite a lot. It reduces the initial cost of creating and using multiaddressing, while planning for evolution to better capabilities. >> - Endpoint-pair context identification PN> To me, it looks like that we have to look at this on two or PN> perhaps three levels. ... Right. (The MAST "fill-in values" for your list of 3 is: 1) Initial - no change to existing procedures, 2) Control ID - none/hash/purpose-built-key/etc., 3) Per-packet - no per-packet identifier.) >> - Authentication of the control exchange PN> Here the minimal requirements seem to be covered by PN> Erik's draft (I know that some WG members disagree, but ... This, again, highlights the need for us to be very careful about the difference between "all relevant issues" versus "issues to be resolve for an initial service". >> - Updates to the pool of locators for the context >> - Rendezvous (for mobile targets) PN> I think that we have to make a distinction between initial PN> rendezvous, or finding a mobile target before there is any PN> association, and rendezvous while there is an active PN> association. Yes! PN> And then we have the "third party rendezvous", which I PN> would like to call referral. I think the term is fine, and I like to refer the issue to an independent effort. (Ie, not deal with it for this work...) >> - Control exchange transport >> >> By way of example, MAST has a very large hand-wave with respect to the >> details of control exchange authentication. ... PN> HIP, on the other hand, has very well defined control exchange PN> authentication, but many people consider it too heavy. yup... d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Wed Feb 18 12:27:18 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00827 for ; Wed, 18 Feb 2004 12:27:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtVRZ-0004QR-4J for multi6-data@psg.com; Wed, 18 Feb 2004 17:25:05 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtVRW-0004Py-Lz for multi6@ops.ietf.org; Wed, 18 Feb 2004 17:25:02 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1IHXWd17023; Wed, 18 Feb 2004 09:33:32 -0800 Date: Wed, 18 Feb 2004 09:24:58 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1888861665.20040218092458@brandenburg.com> To: "marcelo bagnulo" CC: multi6@ops.ietf.org Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) In-Reply-To: References: <1289992244.20040217131511@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo, mb> There are many other issues that have to mb> be addressed in order to provide a multihoming solution and which solution mb> it is probably simpler and easier to deploy. First, I certainly agree that we need to be clear what problem(s) a proposal solves and equally clear about what (related and interesting) problems it does not. And we need to be clear about relative priorities. So it's good you are raising this point it and will be even better if folks discuss it. mb> Moreover, solving the other mb> simpler issues is likely to be what most of users really need right now. There is certainly some feeling that this is true, but I am not so certain. I think that the current reason for multihoming is reliability, rather than performance. As you note, connection preservation is only one aspect of reliability. I think there is an orthogonal issue to connection preservation. A host needs to discover the set of addresses available to it. And it needs to have a basis for choosing one. It would be nice for host to have a discovery mechanism that did not involve manual configuration or running a routing protocol listener. What other, near-term uses for multihoming are you suggesting that are a) important, and b) easier than any of the current proposals? I'll comment that I think the discussion of multihoming gets distorted by treated mobility as an entirely separate topic. Portions of each are entirely separate from the other. However some portions do overlap. By pursuing them independently, we do not take advantage of the overlap. (Now, quite a few multi6 participants are also attending to mobility, in their proposals. However the conceptual discussions on the list are nearly always and only about multihoming.) A final demure: merging two areas of interest can serve to dissipate the effort to solve either. However I think this is not one of those cases. mb> Now, returning to the preservation of established communications, i think mb> that there is another module that i would include: locator selection mb> mechanisms. yes. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Wed Feb 18 13:16:57 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06255 for ; Wed, 18 Feb 2004 13:16:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtWFI-000Bgy-7k for multi6-data@psg.com; Wed, 18 Feb 2004 18:16:28 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtWFF-000BgR-1B for multi6@ops.ietf.org; Wed, 18 Feb 2004 18:16:25 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4AD81AA48; Wed, 18 Feb 2004 19:16:24 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 34DABAA43; Wed, 18 Feb 2004 19:16:24 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Dave Crocker" Cc: Subject: RE: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Wed, 18 Feb 2004 19:14:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <1888861665.20040218092458@brandenburg.com> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I think there is an orthogonal issue to connection preservation. Locator discovery for *initial* contact is orthogonal IMHO Determinig which locator to use during the lifetime of a communication has additional timing constraints that will probably require different mechanisms than just the ones using for the initial contact, i guess > A host > needs to discover the set of addresses available to it. And it needs to > have a basis for choosing one. It would be nice for host to have a > discovery mechanism that did not involve manual configuration or running > a routing protocol listener. fully agree. do you have in mind something different than just plain trial and error? becuase i wouldn't want to modify external hosts, right? > > What other, near-term uses for multihoming are you suggesting that are > a) important, and b) easier than any of the current proposals? ingress filtering? (supposing that by current proposals you mean proposals for preserving established communications...) > > I'll comment that I think the discussion of multihoming gets distorted > by treated mobility as an entirely separate topic. Portions of each are > entirely separate from the other. However some portions do overlap. By > pursuing them independently, we do not take advantage of the overlap. Well, i guess that some mh solutions can be used to provide mobility support but not all of them. For instance, i don't think that a solution like NOID would address the mobility problem, since the dynamic of the locator set changes is very slow because it is conditionated by the DNS timing I mean, in multihoming the locator set is pretty fixed and changes rather slowly, and probably a solution that doesn't not support changes in the address set once that the asosciation has been established would be acceptable, i guess. this type of solution wouldn't be suitable to provide mobility support. Regards, marcelo > > (Now, quite a few multi6 participants are also attending to mobility, in > their proposals. However the conceptual discussions on the list are > nearly always and only about multihoming.) > > A final demure: merging two areas of interest can serve to dissipate the > effort to solve either. However I think this is not one of those cases. > > > mb> Now, returning to the preservation of established > communications, i think > mb> that there is another module that i would include: locator selection > mb> mechanisms. > > yes. > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > From owner-multi6@ops.ietf.org Thu Feb 19 04:34:23 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10910 for ; Thu, 19 Feb 2004 04:34:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtkWz-0006Qq-Rm for multi6-data@psg.com; Thu, 19 Feb 2004 09:31:41 +0000 Received: from [195.66.241.37] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtkWz-0006QY-1s for multi6@ops.ietf.org; Thu, 19 Feb 2004 09:31:41 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id E4C822E1863 for ; Thu, 19 Feb 2004 10:31:44 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Scribe and jabber scribe Date: Wed, 18 Feb 2004 19:25:13 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24, UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As we are approaching the magic week fast, I would like to ask for volunteers for writing the minutes, as well as volunteers reporting on the jabber server. If you would like to volunteer for any of the positions, please email me. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDOuDKarNKXTPFCVEQL2FACg9i4IX1RTbi8w3PCENtG1u5Y2wxgAoJZZ FM1rUz/pjDu3tVHsp9eYO9sH =fTJG -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Feb 19 04:34:39 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10928 for ; Thu, 19 Feb 2004 04:34:38 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtkWy-0006Qb-SB for multi6-data@psg.com; Thu, 19 Feb 2004 09:31:40 +0000 Received: from [195.66.241.37] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtkWo-0006P5-0d for multi6@ops.ietf.org; Thu, 19 Feb 2004 09:31:30 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id B065B2E185C for ; Thu, 19 Feb 2004 10:31:33 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <915CF9D9-6239-11D8-804F-000A95928574@kurtis.pp.se> Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Current agenda Date: Wed, 18 Feb 2004 18:40:39 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=BAYES_00,DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Current agenda for the multi6 WG in Seoul. WEDNESDAY, March 3, 2004 0900-1130 Morning Sessions =========================== 1. Agenda bashing, 5 mins, Chairs 2. Charter review, 15 mins, Chairs 3. Short intros to NEW drafts 80 min draft-ohta-multi6-threats-00.txt, Masataka Ohta draft-ohta-multi6-8plus8-00.txt , Masataka Ohta draft-ohira-multi6-multilink-auto-prefix-assign-00.txt draft-arifumi-multi6-tlc-fm-00.txt, Arifumi Matsumoto draft-ylitalo-multi6-wimp-00.txt, Jukka Ylitalo draft-nikander-multi6-hip-00.txt, Pekka Nikander draft-coene-multi6-sctp-00.txt, Lode Coene draft-crocker-celp-00.txt, Dave Crocker 4. draft-lear-multi6-things-to-think-about-00.txt, 30 mins, Eliot Lear 5. Architectural analysis, Geoff Huston, 20 mins. 6. Other issues, 5 mins If I have forgotten you or you want to add a presentation. Email me. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDOjmqarNKXTPFCVEQJFZgCgvxe9XJ69zPYeLMQPei/cebMEJFkAoOSd JghgLaRdU/t1ROSiScLab2y6 =ZF4J -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Feb 19 11:12:08 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25395 for ; Thu, 19 Feb 2004 11:12:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtqlI-000Fh1-R3 for multi6-data@psg.com; Thu, 19 Feb 2004 16:10:52 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtqlH-000Fgm-Kp for multi6@ops.ietf.org; Thu, 19 Feb 2004 16:10:51 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1JGJMd04196; Thu, 19 Feb 2004 08:19:22 -0800 Date: Thu, 19 Feb 2004 08:10:45 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <691756715.20040219081045@brandenburg.com> To: "marcelo bagnulo" CC: multi6@ops.ietf.org Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) In-Reply-To: References: <1888861665.20040218092458@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo, >> I think there is an orthogonal issue to connection preservation. mb> Locator discovery for *initial* contact is orthogonal IMHO ok. >> A host >> needs to discover the set of addresses available to it. And it needs to >> have a basis for choosing one. It would be nice for host to have a >> discovery mechanism that did not involve manual configuration or running >> a routing protocol listener. mb> fully agree. mb> do you have in mind something different than just plain trial and error? mb> becuase i wouldn't want to modify external hosts, right? I have a suspicion that you do not mean "trial and error for discovering one's own list of addresses" but rather mean "trial and error as a basis for choosing one"... I think there need to be mechanisms for both learning of one's own addresses and for helping decide which one to use. The former is essential in the near-term, I believe. Without it, we cannot scale any approach that makes the hosts aware of their multiple addresses. Something akin to routing table information, to help a host choose among the list of its own addresses, is important, but can be deferred. >> I'll comment that I think the discussion of multihoming gets distorted >> by treated mobility as an entirely separate topic. Portions of each are >> entirely separate from the other. However some portions do overlap. By >> pursuing them independently, we do not take advantage of the overlap. mb> Well, i guess that some mh solutions can be used to provide mobility support mb> but not all of them. That is my point. If we have two proposal that are roughly equal in their complexity, utility, and the like, then the fact that one can also be used to satisfy some mobility requirements ought to bias us in its favor. At the least, this wider range of utility ought to be a significant part of our evaluation among the proposals. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Feb 19 11:23:04 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25824 for ; Thu, 19 Feb 2004 11:23:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atqwn-000H3K-6o for multi6-data@psg.com; Thu, 19 Feb 2004 16:22:45 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atqwg-000Gz9-Rk for multi6@ops.ietf.org; Thu, 19 Feb 2004 16:22:39 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F2C0CA27D; Thu, 19 Feb 2004 17:22:37 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id DDE95A27B; Thu, 19 Feb 2004 17:22:37 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Dave Crocker" Cc: Subject: RE: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Thu, 19 Feb 2004 17:20:47 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <691756715.20040219081045@brandenburg.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I have a suspicion that you do not mean "trial and error for discovering > one's own list of addresses" but rather mean "trial and error as a basis > for choosing one"... Yes. > > I think there need to be mechanisms for both learning of one's own > addresses and for helping decide which one to use. The former is > essential in the near-term, I believe. Without it, we cannot scale any > approach that makes the hosts aware of their multiple addresses. I agree that the mechanism to learn one's own addresses is fundamental, but i thought that the mechanism to do that would be stateless (or statefull) address autoconfiguration... Do you think that we may need something else? > > Something akin to routing table information, to help a host choose among > the list of its own addresses, is important, but can be deferred. > I would say that you will need a mechanism to selects the destination address the moment you want to be able to obtain fault tolerance by using the available path. If not you may end up using a path that is not available, i guess. Regards, marcelo From owner-multi6@ops.ietf.org Thu Feb 19 11:34:44 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26242 for ; Thu, 19 Feb 2004 11:34:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atr88-000Igd-Kk for multi6-data@psg.com; Thu, 19 Feb 2004 16:34:28 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atr85-000Ibo-Fr for multi6@ops.ietf.org; Thu, 19 Feb 2004 16:34:25 +0000 Received: from bbprime (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1JGgud05683; Thu, 19 Feb 2004 08:42:56 -0800 Date: Thu, 19 Feb 2004 08:34:19 -0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1802106614.20040219083419@brandenburg.com> To: "marcelo bagnulo" CC: multi6@ops.ietf.org Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) In-Reply-To: References: <691756715.20040219081045@brandenburg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit marcelo, mb> I agree that the mechanism to learn one's own addresses is fundamental, but mb> i thought that the mechanism to do that would be stateless (or statefull) mb> address autoconfiguration... mb> Do you think that we may need something else? I don't have any particular thoughts about the solution for this. As long as it scales at least as well as DHCP it is fine with me. The one thing that makes this more challenging than DHCP is the problem of timing and initiative. DHCP is triggered by the client with an obvious example being system boot. For multiaddressing, the easy question is how to supply information about multiple addresses at system boot. The harder question is how to get information about the availability of new addresses to the client system? Offhand, I think this requires a "push" mechanism from the network, rather than a pull mechanism from the client, in order to make sure the client learns of the changes in a timely fashion. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Thu Feb 19 12:04:53 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27150 for ; Thu, 19 Feb 2004 12:04:52 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Atram-000NVu-7W for multi6-data@psg.com; Thu, 19 Feb 2004 17:04:04 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Atrad-000NSe-GA for multi6@ops.ietf.org; Thu, 19 Feb 2004 17:03:55 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9C141A28E; Thu, 19 Feb 2004 18:03:54 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 7A8E5A281; Thu, 19 Feb 2004 18:03:54 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Dave Crocker" Cc: Subject: RE: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Thu, 19 Feb 2004 18:02:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <1802106614.20040219083419@brandenburg.com> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I don't have any particular thoughts about the solution for this. As > long as it scales at least as well as DHCP it is fine with me. > > The one thing that makes this more challenging than DHCP is the problem > of timing and initiative. DHCP is triggered by the client with an > obvious example being system boot. DHCP for IPv6 supports server initiated configuration i.e. a push from the server AFAIK (the reconfigure message from the server) So what we need now is a mechanism to inform the server on real time about which prefixes are to be configured in the clients. Using stateless autoconfiguration, you can use the Router Advertisement in the same way, so you can inform the hosts which prefixes they have to use at every moment. The problem again is how does the router knows about which prefixes to use. In this case there is an additional problem related to the fact that Router Advertisement are link scoped, so you need to inform the routers through other means. A possible option for this would be Router Renumbering protocol. The problem with this is that AFAIK the router renumbering protocol is not very supported in available equipment, so i am not sure that this would be a real option. the other option for this would be to use DHCP prefix delegation, so you can delegate a prefix to every router, so that they can announce it through dhcp to the hosts. In both cases , stateless and statefull autoconfiguration, the resulting situation is that you have a central server that manages the prefixes. The point now is how does this server knows which prefixes are to be announced. IMHO, the only case that a prefix has to be removed is when the direct link between the multihomed site and the isp that delegated the prefix is down. In other failures modes, a prefix should be used to reach a set of destinations and not to reach others. For instance a multihomed site with ISPA and ISPB The link between ISPA and the internet fails. One may think that PrefixA should be removed and not used anymore. However, if you do that, you will not be able to reach the other customers of ISPA So in this case both prefixes has to be preserved in the site, only that PrefA should be included in the source address when communicating with other ISPA customers and PrefB should be used when communicating with all the rest of the Internet. That is why IMHO it is so important a mechanism to discover the proper source address to be used in order to reach a certain destination address. So according to this, the problem of discovering one's own prefixes would be simple, you just have to remove the prefix when the direct link with the provider that delegated the prefix is down. This could be as simple as a ping or bdf (draft-katz-ward-bfd-01.txt) The problem is then moved to the source address selection :-) Regards, marcelo > > For multiaddressing, the easy question is how to supply information > about multiple addresses at system boot. > > The harder question is how to get information about the availability of > new addresses to the client system? Offhand, I think this requires a > "push" mechanism from the network, rather than a pull mechanism from the > client, in order to make sure the client learns of the changes in a > timely fashion. > > > d/ > -- > Dave Crocker > Brandenburg InternetWorking > Sunnyvale, CA USA > From owner-multi6@ops.ietf.org Thu Feb 19 19:06:22 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05295 for ; Thu, 19 Feb 2004 19:06:22 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AtyAL-000IQs-0Y for multi6-data@psg.com; Fri, 20 Feb 2004 00:05:13 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AtyAG-000IQB-SU for multi6@ops.ietf.org; Fri, 20 Feb 2004 00:05:09 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1K05Xrq000626 for ; Fri, 20 Feb 2004 01:05:34 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <7053270A-6338-11D8-BD64-000A95CD987A@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: Iljitsch van Beijnum Subject: host-centric draft Date: Fri, 20 Feb 2004 01:05:06 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I've been catching up on drafts, reaching draft-huitema-multi6-hosts-03 just now. A few questions: "A strong assumption of the IPv6 architecture is that all prefixes of a site will have the same length; it is thus possible to derive a prefix from the source address of a "misdirected" packet, by combining this prefix with a conventional suffix." This is very unclear as the reason to have such an anycast address in the first place is only given 30 or so pages later. About ICMP/ingress filtering: if it is actual ingress filtering we're talking about (ie, an ISP filters packets it receives from a customer) ICMP error messages aren't likely to be forthcoming when an improper source address was used by the customer, as the ISP in question doesn't know that the addresses which are filtered out should go back to the customer in question. So in order for this to work reliably customers must install filters that perform the same function, but then for egress, as the customer border router has a good return path for the ICMP message. A general problem that I have with this draft is that it explores some very specific mechanisms, but at the same time doesn't explore some other mechanisms that could lead to similar results. (For instance, a situation where two distinct layer 3 networks exist in parallel isn't explored. For source address rewriting using a special "rewrite this" prefix would be a possibility.) It would be better to either be brief or complete. The problem that rerouting could invalidate an earlier source address choice isn't mentioned. I'm unsure why we would want to inject BGP information into hosts. Reachability yes/no isn't very useful as the actual reachability status of the other side is in almost all cases hidden by aggregation. So basically this only indicates whether the ISP in question is available. Determining preference based on BGP information is also a relatively futile endeavor as path lengths are very often the same and relevant differences in topology typically don't show up in BGP. (Many large networks use a single AS for an entire continent or even the world, while obviously small networks don't.) The 6 level deep heading numbering is somewhat excessive. 9.1.4.19 What new information should applications be aware of? None I don't really agree. Applications need to try all addresses for a correspondent. Some do this today, most don't. And this needs to be done in a smart way, a four minute timout between trying successive addresses isn't acceptable. From owner-multi6@ops.ietf.org Fri Feb 20 09:51:45 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24440 for ; Fri, 20 Feb 2004 09:51:45 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuBxD-000FSB-Nm for multi6-data@psg.com; Fri, 20 Feb 2004 14:48:35 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuBxC-000FRy-9n for multi6@ops.ietf.org; Fri, 20 Feb 2004 14:48:34 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1KEmxrq012428; Fri, 20 Feb 2004 15:48:59 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) 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: draft-savola-multi6-asn-pi-01.txt Date: Fri, 20 Feb 2004 15:48:31 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 31 jan 2004, at 8:35, Pekka Savola wrote: > I've sent it to be published to the I-D secretariat, and in the > meantime is available at: > http://www.netcore.fi/pekkas/ietf/draft-savola-multi6-asn-pi-01.txt While limiting this to 15 bits worth of AS numbers solves some problems, it also immediately removes much of the potential use from this proposal, as this way there is still no solution for people who want/need to multihome in IPv6 but don't have an AS number today. I think if we want to do _something_ like this, there are probably better ways to do it. From owner-multi6@ops.ietf.org Fri Feb 20 11:23:50 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00549 for ; Fri, 20 Feb 2004 11:23:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuDPU-000BIY-Pk for multi6-data@psg.com; Fri, 20 Feb 2004 16:21:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuDPS-000BGy-Vt for multi6@ops.ietf.org; Fri, 20 Feb 2004 16:21:51 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1KGLgl05902; Fri, 20 Feb 2004 18:21:42 +0200 Date: Fri, 20 Feb 2004 18:21:42 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: draft-savola-multi6-asn-pi-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Fri, 20 Feb 2004, Iljitsch van Beijnum wrote: > On 31 jan 2004, at 8:35, Pekka Savola wrote: > > > I've sent it to be published to the I-D secretariat, and in the > > meantime is available at: > > > http://www.netcore.fi/pekkas/ietf/draft-savola-multi6-asn-pi-01.txt > > While limiting this to 15 bits worth of AS numbers solves some > problems, it also immediately removes much of the potential use from > this proposal, as this way there is still no solution for people who > want/need to multihome in IPv6 but don't have an AS number today. > > I think if we want to do _something_ like this, there are probably > better ways to do it. I've targeted this solution for the biggest corporations, for which (IMHO) multiple addresses are a non-starter. Such corporations have AS numbers. Such corporations don't crop up from nowhere. But if folks feel we should just allow everyone, one could just as well allow full 16 bits or even 32 bits. That would just lead to the exhaustion of AS numbers, though -- and folks would be worse off than before, as also small enterprises would get AS numbers for the "easy multihoming ticket". -- 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 Feb 20 12:01:07 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01837 for ; Fri, 20 Feb 2004 12:01:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuDzs-000Llp-Hb for multi6-data@psg.com; Fri, 20 Feb 2004 16:59:28 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuDzo-000LlD-Vs for multi6@ops.ietf.org; Fri, 20 Feb 2004 16:59:25 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E1B4DA83C; Fri, 20 Feb 2004 17:59:23 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id CB689A83B; Fri, 20 Feb 2004 17:59:23 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Pekka Savola" , "Iljitsch van Beijnum" Cc: Subject: RE: draft-savola-multi6-asn-pi-01.txt Date: Fri, 20 Feb 2004 17:57:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I've targeted this solution for the biggest corporations, for which > (IMHO) multiple addresses are a non-starter. I also think that big institutions will be reluctant to use multiaddressing, for the comments that i've heard on different lists. > Such corporations have AS numbers. Such corporations don't crop up from nowhere. Yes, but many other who are not big sites also have AS numbers. I even know people who have an AS number at their home network. So, automatically giving all people who have a AS number today an PI address block may not be appropriate. I guess that first we should agree that really big sites won't use multiaddressing and that they should obtain their own PI block. Then we need to define the criteria to identify big sites A finally then decide which addresses we should give them IMHO, the first decision concerns the IETF I am not so sure about the second and the third point, perhaps this should concern the rirs, more than the ietf? Regards, marcelo > > But if folks feel we should just allow everyone, one could just as > well allow full 16 bits or even 32 bits. That would just lead to the > exhaustion of AS numbers, though -- and folks would be worse off than > before, as also small enterprises would get AS numbers for the "easy > multihoming ticket". > > -- > 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 Feb 20 12:41:38 2004 Received: from psg.com (psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03127 for ; Fri, 20 Feb 2004 12:41:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuEck-0005ZK-FT for multi6-data@psg.com; Fri, 20 Feb 2004 17:39:38 +0000 Received: from [163.117.136.122] (helo=smtp02.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuEci-0005Z6-EM for multi6@ops.ietf.org; Fri, 20 Feb 2004 17:39:36 +0000 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CCD5A804B; Fri, 20 Feb 2004 18:39:35 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp02.uc3m.es (Postfix) with SMTP id B70518044; Fri, 20 Feb 2004 18:39:35 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" , "Multi6 List" Subject: RE: host-centric draft Date: Fri, 20 Feb 2004 18:37:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <7053270A-6338-11D8-BD64-000A95CD987A@muada.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Iljitsch, thanks for commenting the draft I include my own answers to your comments, Christian and Richard perhaps think different > I've been catching up on drafts, reaching draft-huitema-multi6-hosts-03 > just now. A few questions: > > "A strong assumption of the IPv6 architecture is that all prefixes of > a site will have the same length; it is thus possible to derive a > prefix from the source address of a "misdirected" packet, by > combining this prefix with a conventional suffix." > > This is very unclear as the reason to have such an anycast address in > the first place is only given 30 or so pages later. Ok. We could add a pointer to the explanation 30 pages later, or even we could remove some unclear details at this point and leave all the explanation for later. Just mentioning that it would be good if the prefix can be derived automatically and leave for later the explanation on how to do this. > > About ICMP/ingress filtering: if it is actual ingress filtering we're > talking about (ie, an ISP filters packets it receives from a customer) > ICMP error messages aren't likely to be forthcoming when an improper > source address was used by the customer, as the ISP in question doesn't > know that the addresses which are filtered out should go back to the > customer in question. So in order for this to work reliably customers > must install filters that perform the same function, but then for > egress, as the customer border router has a good return path for the > ICMP message. Yes, this is what i think is described in the draft... I mean, we assume that the isp is performing ingress filtering, so the idea is not to send packets with a incompatible source address. We then explore different forms to do this, one of them involves sending an ICMP error back to the host, indicating the correct source address. Now, this ICMP error message is not generated by the ISP border routers but it is generated by the site exit routers, since it is the site itself that is interested in providing feedback to the hosts. All this is an intrasite mechanism. So, i think that i agree with you and the draft states what you are saying... > > A general problem that I have with this draft is that it explores some > very specific mechanisms, but at the same time doesn't explore some > other mechanisms that could lead to similar results. (For instance, a > situation where two distinct layer 3 networks exist in parallel isn't > explored. For source address rewriting using a special "rewrite this" > prefix would be a possibility.) It would be better to either be brief > or complete. Well, i think that the idea of the draft is to analyze all the options that seemed reasonable to us. The problem may be that we didn't came up with all the possible solutions, so we didn't include them in the draft. The draft starts with an analysis of all the options that we had identified (not so much detail in this part) and then selects and describes the preferred solution (much more detail in this part) IMHO, the analysis is as important as the solution proposed since it is aimed to discuss different approaches. So if there are some points missing in the analysis, the selected solution may well change I would be glad to try to include another options in the analysis. for instance, the options that you were mentioning that is missing, could you expand on this? The two layer 3 network that you mention, would this be like a multihomed host? > > The problem that rerouting could invalidate an earlier source address > choice isn't mentioned. Could expand this too? perhaps an example? > > I'm unsure why we would want to inject BGP information into hosts. I don't think that injecting BGP routing table has been considered in the draft (but i may be forgetting something) > Reachability yes/no isn't very useful as the actual reachability status > of the other side is in almost all cases hidden by aggregation. So > basically this only indicates whether the ISP in question is available. > Determining preference based on BGP information is also a relatively > futile endeavor as path lengths are very often the same and relevant > differences in topology typically don't show up in BGP. (Many large > networks use a single AS for an entire continent or even the world, > while obviously small networks don't.) Well, as i see it, there are two systems that can be aware of reachability: the routing system or the end host itself The end host can discover reachability by itself, simply trying to send packets to the other end. This is more reliable way to discover reachability, since the host is actually reaching the target. The other option is to use the routing system. As you mention, the information provided by the routing system is aggregated, so it hides some information. However, the routing system has the information in advance, while the host has to discover it when it needs it. So the host obtained by the host is more accurate, but the routing system provides it faster, i guess. both options are explored in the draft and some of the drawbacks are analyzed, perhaps this particular pov in really included, though The other problem with bgp is that it seems unsuitable for small sites, where the is not likely to be bgp expertise available, so the host option is considered more suitable for this scenario Large sites that have networks manager are likely to be capable of running bgp. Additionally, it seems that the bgp option provides more centralized policy management, so perhaps it would be preferred by large sites. But one of the goal of the draft is to foster discussion on this topics... > > The 6 level deep heading numbering is somewhat excessive. Yes, but i guess that merging sections would render the draft even more unreadable > > 9.1.4.19 What new information should applications be aware of? > > None > > I don't really agree. Applications need to try all addresses for a > correspondent. Some do this today, most don't. And this needs to be > done in a smart way, a four minute timout between trying successive > addresses isn't acceptable. Well, rfc 3484 already states that "Well-behaved applications SHOULD iterate through the list of addresses returned from getaddrinfo() until they find a working address." But i agree with you, something about this can be included here. The other point about this is when considering retrying with different source addresses. If you do this sequentially, i think that it would be up to the app to retry. However if you do it in parallel, i think that the ip layer could simply generate multiple packets and send them in parallel, so no need to change the apps. Reagrds, marcelo > > From owner-multi6@ops.ietf.org Sat Feb 21 13:32: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 NAA09894 for ; Sat, 21 Feb 2004 13:32:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aubrq-000JAS-9q for multi6-data@psg.com; Sat, 21 Feb 2004 18:28:46 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aubrp-000JAB-4j for multi6@ops.ietf.org; Sat, 21 Feb 2004 18:28:45 +0000 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1LISgvf012227 for ; Sat, 21 Feb 2004 10:28:42 -0800 (PST) Received: from naexfe02.na.qualcomm.com (naexfe02.qualcomm.com [129.46.51.214]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1LISevw012210 for ; Sat, 21 Feb 2004 10:28:40 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by naexfe02.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 21 Feb 2004 10:28:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Sat, 21 Feb 2004 10:28:40 -0800 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327D43@NAEX01.na.qualcomm.com> Thread-Topic: I-D ACTION:draft-coene-multi6-sctp-00.txt Thread-Index: AcPp0shiG2YlwkwRSwaaBmHod4pwFgO1U4yw From: "Barany, Pete" To: X-OriginalArrivalTime: 21 Feb 2004 18:28:40.0149 (UTC) FILETIME=[871C7850:01C3F8A8] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable In the SCTP sockets API Internet draft (draft-ietf-tsvwg-sctpsocket-07.txt), there is a sendmsg() flag (MSG_ADDR_OVER) for the one-to-many style that allows the application to request that the SCTP stack override the primary destination address. Do implementations honor (mandatory) this request, or can the SCTP stack override it? Thanks. Pete -----Original Message----- From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, February 02, 2004 1:03 PM Cc: multi6@ops.ietf.org Subject: I-D ACTION:draft-coene-multi6-sctp-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Multihoming: the SCTP solution Author(s) : L. Coene Filename : draft-coene-multi6-sctp-00.txt Pages : 14 Date : 2004-2-2 =09 This document describes the multhoming solution used in SCTP. It tries to answer the questions posed in 'Things MULTI6 developers should think about' [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-coene-multi6-sctp-00.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the message. 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-coene-multi6-sctp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-coene-multi6-sctp-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-multi6@ops.ietf.org Sun Feb 22 04:26: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 EAA21443 for ; Sun, 22 Feb 2004 04:26:15 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AuppN-0008Pk-Fo for multi6-data@psg.com; Sun, 22 Feb 2004 09:23:09 +0000 Received: from [212.152.24.65] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AuppM-0008PK-2o for multi6@ops.ietf.org; Sun, 22 Feb 2004 09:23:08 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 382F52E6D76; Sun, 22 Feb 2004 10:23:17 +0100 (CET) In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B011082BC@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B011082BC@KC-MAIL4.kc.umkc.edu> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Dave Crocker" , "Dave Crocker" , "Multi6 List" , "marcelo bagnulo" From: Kurt Erik Lindqvist Subject: Re: CELP (was RE:) Date: Fri, 20 Feb 2004 17:42:18 +0100 To: "Ayyasamy, Senthilkumar (UMKC-Student)" X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-16, at 12.14, Ayyasamy, Senthilkumar (UMKC-Student) wrote: >>> I still operate under the possibly-false view of an Internet that is >>> mostly reachable. Perhaps partitioning is already too much of a >>> problem, >>> for us to ignore this type of fine-grained mechanism? >> >> This is very much the world of *today*. > > If by "partition" dave meant "topology parition", it is very minimal. [snip] > > or, you mean black holes, port blocking etc contribute to partitions? Well, I was sort of referring to both or the phenomenon of partioning in general. Either by design or policy. But Marcelo also addressed this. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDY47aarNKXTPFCVEQKu2ACgntBzrQeGreygQ2QVmbe4RgFh5SEAoJQi XTgGTS0HdkCQ+bZlPG/7tB4i =OheW -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 23 01:47: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 BAA27090 for ; Mon, 23 Feb 2004 01:47:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Av9pA-000IzU-CO for multi6-data@psg.com; Mon, 23 Feb 2004 06:44:16 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Av9p9-000IzG-F7 for multi6@ops.ietf.org; Mon, 23 Feb 2004 06:44:15 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id AEB1A2E8E93; Mon, 23 Feb 2004 07:44:26 +0100 (CET) In-Reply-To: <691756715.20040219081045@brandenburg.com> References: <1888861665.20040218092458@brandenburg.com> <691756715.20040219081045@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, "marcelo bagnulo" From: Kurt Erik Lindqvist Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Sun, 22 Feb 2004 16:49:54 +0100 To: Dave Crocker X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave, A host >>> needs to discover the set of addresses available to it. And it needs >>> to >>> have a basis for choosing one. It would be nice for host to have a >>> discovery mechanism that did not involve manual configuration or >>> running >>> a routing protocol listener. > mb> fully agree. > mb> do you have in mind something different than just plain trial and > error? > mb> becuase i wouldn't want to modify external hosts, right? > > I have a suspicion that you do not mean "trial and error for > discovering > one's own list of addresses" but rather mean "trial and error as a > basis > for choosing one"... > > I think there need to be mechanisms for both learning of one's own > addresses and for helping decide which one to use. The former is > essential in the near-term, I believe. Without it, we cannot scale any > approach that makes the hosts aware of their multiple addresses. > > Something akin to routing table information, to help a host choose > among > the list of its own addresses, is important, but can be deferred. are you arguing that as part of any solution, we should either include a address selection / pairing algorithm or we should make that an "external" requirement to be solved by a separate protocol or by someone else? >>> I'll comment that I think the discussion of multihoming gets >>> distorted >>> by treated mobility as an entirely separate topic. Portions of each >>> are >>> entirely separate from the other. However some portions do overlap. >>> By >>> pursuing them independently, we do not take advantage of the overlap. > mb> Well, i guess that some mh solutions can be used to provide > mobility support > mb> but not all of them. > > That is my point. > > If we have two proposal that are roughly equal in their complexity, > utility, and the like, then the fact that one can also be used to > satisfy some mobility requirements ought to bias us in its favor. > > At the least, this wider range of utility ought to be a significant > part > of our evaluation among the proposals. It should. And this IMHO is covered by "2.1.2 Uniqueness" and "2.1.2.1 Does your solution address mobility" in Eliot's draft. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDjPpaarNKXTPFCVEQK5LACgoN4VLjnvN7qrX+AXaQ/jAMg0ejIAn1hE lzh8moRmQUadkXusK0FMV4+/ =1gK3 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 23 01:47: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 BAA27108 for ; Mon, 23 Feb 2004 01:47:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Av9p3-000Iyr-71 for multi6-data@psg.com; Mon, 23 Feb 2004 06:44:09 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Av9p2-000IyZ-0G for multi6@ops.ietf.org; Mon, 23 Feb 2004 06:44:08 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 18F5B2E8E8E; Mon, 23 Feb 2004 07:44:16 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <9DB8E308-654D-11D8-B86A-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: , "Dave Crocker" From: Kurt Erik Lindqvist Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Sun, 22 Feb 2004 16:41:44 +0100 To: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-18, at 19.14, marcelo bagnulo wrote: >> >> I'll comment that I think the discussion of multihoming gets distorted >> by treated mobility as an entirely separate topic. Portions of each >> are >> entirely separate from the other. However some portions do overlap. >> By >> pursuing them independently, we do not take advantage of the overlap. > > Well, i guess that some mh solutions can be used to provide mobility > support > but not all of them. For instance, i don't think that a solution like > NOID > would address the mobility problem, since the dynamic of the locator > set > changes is very slow because it is conditionated by the DNS timing > > I mean, in multihoming the locator set is pretty fixed and changes > rather > slowly, and probably a solution that doesn't not support changes in the > address set once that the asosciation has been established would be > acceptable, i guess. > this type of solution wouldn't be suitable to provide mobility support. We also had this discussed sometime during the autumn and from what I remember, most seemed to think that mobility and mutli6 required solutions with different paramters - to the point where the solutions would be different solutions. Best regards, - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDjNvaarNKXTPFCVEQJNAgCg2u30pTNNGqwsXqLN5dBRE3RyvecAn3f5 QW687JxGMMmxnNAV6oux2hTg =AM4m -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 23 01:47: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 BAA27126 for ; Mon, 23 Feb 2004 01:47:35 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Av9pK-000J4F-2M for multi6-data@psg.com; Mon, 23 Feb 2004 06:44:26 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Av9pJ-000J42-8C for multi6@ops.ietf.org; Mon, 23 Feb 2004 06:44:25 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 47A412E8E9C; Mon, 23 Feb 2004 07:44:36 +0100 (CET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <4F15D4D2-6551-11D8-B86A-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: , "Pekka Savola" , "Iljitsch van Beijnum" From: Kurt Erik Lindqvist Subject: Re: draft-savola-multi6-asn-pi-01.txt Date: Sun, 22 Feb 2004 17:08:10 +0100 To: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-20, at 17.57, marcelo bagnulo wrote: > I guess that first we should agree that really big sites won't use > multiaddressing and that they should obtain their own PI block. > Then we need to define the criteria to identify big sites > A finally then decide which addresses we should give them > > IMHO, the first decision concerns the IETF > I am not so sure about the second and the third point, perhaps this > should > concern the rirs, more than the ietf? Agreed. We could make our lives very easy and just say that the current filtering policy is up to the RIRs to handle. By that giving them also one of the other keys to the multihoming problem - just break aggregation. IMHO this is where we are today. But as most sites actually do filter on allocation boundaries, we don't have an issue. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDjT7aarNKXTPFCVEQLUFQCdF73pxE7Hhq8DnQkLPRCzCEUA/sEAoJwP 7GxHJaJ/7PG8fAmDbVfL4zsd =koQv -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 23 01:47: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 BAA27144 for ; Mon, 23 Feb 2004 01:47:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Av9pH-000J3x-Iv for multi6-data@psg.com; Mon, 23 Feb 2004 06:44:23 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Av9pG-000J30-HC for multi6@ops.ietf.org; Mon, 23 Feb 2004 06:44:22 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 6CDDC2E8E97; Mon, 23 Feb 2004 07:44:33 +0100 (CET) In-Reply-To: <1802106614.20040219083419@brandenburg.com> References: <691756715.20040219081045@brandenburg.com> <1802106614.20040219083419@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <66347CF0-654F-11D8-B86A-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, "marcelo bagnulo" From: Kurt Erik Lindqvist Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Sun, 22 Feb 2004 16:54:29 +0100 To: Dave Crocker X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-02-19, at 17.34, Dave Crocker wrote: > marcelo, > > mb> I agree that the mechanism to learn one's own addresses is > fundamental, but > mb> i thought that the mechanism to do that would be stateless (or > statefull) > mb> address autoconfiguration... > > mb> Do you think that we may need something else? > > I don't have any particular thoughts about the solution for this. As > long as it scales at least as well as DHCP it is fine with me. > > The one thing that makes this more challenging than DHCP is the problem > of timing and initiative. DHCP is triggered by the client with an > obvious example being system boot. > > For multiaddressing, the easy question is how to supply information > about multiple addresses at system boot. > > The harder question is how to get information about the availability of > new addresses to the client system? Offhand, I think this requires a > "push" mechanism from the network, rather than a pull mechanism from > the > client, in order to make sure the client learns of the changes in a > timely fashion. Following my question in the other mail, do you also see that this mechanism in some way needs to help with the actual address selection? So, my concern is that we actually have a problem split in (at least) two pieces - making the end system aware of what addresses with what properties are available to it; and from the set of addresses/locators make the selection of which one to use. You can further complicate the above if we think that selecting a address for initial communication is one thing, selecting a address for established communication is something else. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDjQuKarNKXTPFCVEQILXgCgyicjJWpe9jRTA4t9C9bp7It1QxQAmwfY m1zkKKjHoeTmuVrYG9StwXIZ =AtMi -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 23 05:27: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 FAA17842 for ; Mon, 23 Feb 2004 05:27:48 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvDHh-000H7C-Nv for multi6-data@psg.com; Mon, 23 Feb 2004 10:25:57 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvDHg-000H70-A4 for multi6@ops.ietf.org; Mon, 23 Feb 2004 10:25:56 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5EBD0AE1E; Mon, 23 Feb 2004 11:25:55 +0100 (CET) Received: from lolo (unknown [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 47CAAAE12; Mon, 23 Feb 2004 11:25:55 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Kurt Erik Lindqvist" , "Dave Crocker" Cc: Subject: RE: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Mon, 23 Feb 2004 11:24:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <66347CF0-654F-11D8-B86A-000A95928574@kurtis.pp.se> Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kurtis, I know you were asking Dave, but i include my opinion also... > Following my question in the other mail, do you also see that this > mechanism in some way needs to help with the actual address selection? IMHO yes, I think we will need to modify the address selection mechanism, but I think we can limit the changes to the hosts within the multihomed site. > So, my concern is that we actually have a problem split in (at least) > two pieces - making the end system aware of what addresses with what > properties are available to it; and from the set of addresses/locators > make the selection of which one to use. Yes > > You can further complicate the above if we think that selecting a > address for initial communication is one thing, selecting a address for > established communication is something else. Yes Regards, marcelo > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQDjQuKarNKXTPFCVEQILXgCgyicjJWpe9jRTA4t9C9bp7It1QxQAmwfY > m1zkKKjHoeTmuVrYG9StwXIZ > =AtMi > -----END PGP SIGNATURE----- > > From owner-multi6@ops.ietf.org Mon Feb 23 05:31: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 FAA18031 for ; Mon, 23 Feb 2004 05:31:04 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvDMY-000Hh2-PC for multi6-data@psg.com; Mon, 23 Feb 2004 10:30:58 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvDMX-000Hgn-Cf for multi6@ops.ietf.org; Mon, 23 Feb 2004 10:30:57 +0000 Received: from [IPv6:::1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1NAU3rq066188; Mon, 23 Feb 2004 11:30:03 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4F15D4D2-6551-11D8-B86A-000A95928574@kurtis.pp.se> References: <4F15D4D2-6551-11D8-B86A-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2DD216A4-65EB-11D8-A884-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: draft-savola-multi6-asn-pi-01.txt Date: Mon, 23 Feb 2004 11:29:36 +0100 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 22-feb-04, at 17:08, Kurt Erik Lindqvist wrote: >> I guess that first we should agree that really big sites won't use >> multiaddressing and that they should obtain their own PI block. >> Then we need to define the criteria to identify big sites >> A finally then decide which addresses we should give them >> IMHO, the first decision concerns the IETF >> I am not so sure about the second and the third point, perhaps this >> should concern the rirs, more than the ietf? > Agreed. We could make our lives very easy and just say that the current > filtering policy is up to the RIRs to handle. By that giving them also > one of the other keys to the multihoming problem - just break > aggregation. IMHO this is where we are today. But as most sites > actually do filter on allocation boundaries, we don't have an issue. I am profoundly unsatisfied with the way the RIRs operate in this regard. For instance, they set a policy and then don't stick to it (see my rant at http://www.ipv4.bgpexpert.com/archive2003q4.php never mind the "ipv4" in the URL, I'm on the road and for some reason contacting my site using a hostname that has an IPv6 address doesn't work too well). Also, since anyone can participate in the policy decision making process, they're pretty much a special interest group in this regard and if there is enough pressure to make something happen, it will happen, regardless of whether it's a good idea. If we want to break aggregation in a way that doesn't break scalability then I think we need to put out an RFC that tells people how to do it, so that it's actually usable (no point in doing this if network operators filter) and scalable. I think it can be done but Pekka's draft isn't the way. Iljitsch From owner-multi6@ops.ietf.org Mon Feb 23 05:37: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 FAA18306 for ; Mon, 23 Feb 2004 05:37:13 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvDSP-000IEL-So for multi6-data@psg.com; Mon, 23 Feb 2004 10:37:01 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvDSO-000IE3-SA for multi6@ops.ietf.org; Mon, 23 Feb 2004 10:37:01 +0000 Received: from [IPv6:::1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1NAa9rq066287; Mon, 23 Feb 2004 11:36:09 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <9DB8E308-654D-11D8-B86A-000A95928574@kurtis.pp.se> References: <9DB8E308-654D-11D8-B86A-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0861C0C4-65EC-11D8-A884-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Mon, 23 Feb 2004 11:35:43 +0100 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 22-feb-04, at 16:41, Kurt Erik Lindqvist wrote: > We also had this discussed sometime during the autumn and from what I > remember, most seemed to think that mobility and mutli6 required > solutions with different paramters - to the point where the solutions > would be different solutions. The differences are that mobility needs to be able to change addresses on short notice, unlike multihoming. With multihoming, there is the whole selection/failover issue, which is a no-brainer in mobility. What they could/should share is a way to make transport sessions survive address changes, and preferably also the security mechanisms. The problem is that current MIPv6 doesn't do much that is usable for multihoming, especially not if we rule out the extra "this is the real address" header because it adds too much overhead. From owner-multi6@ops.ietf.org Mon Feb 23 06:11: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 GAA19388 for ; Mon, 23 Feb 2004 06:11:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvDzR-000M72-W6 for multi6-data@psg.com; Mon, 23 Feb 2004 11:11:09 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvDzQ-000M6k-TB for multi6@ops.ietf.org; Mon, 23 Feb 2004 11:11:09 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id B87E22EA7A8; Mon, 23 Feb 2004 12:11:19 +0100 (CET) In-Reply-To: <2DD216A4-65EB-11D8-A884-000A95CD987A@muada.com> References: <4F15D4D2-6551-11D8-B86A-000A95928574@kurtis.pp.se> <2DD216A4-65EB-11D8-A884-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: draft-savola-multi6-asn-pi-01.txt Date: Mon, 23 Feb 2004 12:11:16 +0100 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> I guess that first we should agree that really big sites won't use >>> multiaddressing and that they should obtain their own PI block. >>> Then we need to define the criteria to identify big sites >>> A finally then decide which addresses we should give them > >>> IMHO, the first decision concerns the IETF >>> I am not so sure about the second and the third point, perhaps this >>> should concern the rirs, more than the ietf? > >> Agreed. We could make our lives very easy and just say that the >> current >> filtering policy is up to the RIRs to handle. By that giving them also >> one of the other keys to the multihoming problem - just break >> aggregation. IMHO this is where we are today. But as most sites >> actually do filter on allocation boundaries, we don't have an issue. > > I am profoundly unsatisfied with the way the RIRs operate in this > regard. For instance, they set a policy and then don't stick to it > (see my rant at http://www.ipv4.bgpexpert.com/archive2003q4.php never > mind the "ipv4" in the URL, I'm on the road and for some reason > contacting my site using a hostname that has an IPv6 address doesn't > work too well). Also, since anyone can participate in the policy > decision making process, they're pretty much a special interest group > in this regard and if there is enough pressure to make something > happen, it will happen, regardless of whether it's a good idea. Well, there are a lot of things you can say about the RIR policies, but let's take that to some other mailinglist :) > > If we want to break aggregation in a way that doesn't break > scalability then I think we need to put out an RFC that tells people > how to do it, so that it's actually usable (no point in doing this if > network operators filter) and scalable. I think it can be done but > Pekka's draft isn't the way. I think that the issue of breaking aggregation will have to be part of the general architectural discussion. Just like any other proposal. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDnf1qarNKXTPFCVEQLSIACfX7eIIUgFFIFdDsWCXMXQOPyJ5HYAoMDm fMkIfUBcQSqP2wQ90WNjQ/bX =X8EU -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 23 07:40: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 HAA21924 for ; Mon, 23 Feb 2004 07:40:20 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvFMu-0004eH-2K for multi6-data@psg.com; Mon, 23 Feb 2004 12:39:28 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvFBD-0003Qw-MA for multi6@ops.ietf.org; Mon, 23 Feb 2004 12:27:23 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id D2DEC2EAB73 for ; Mon, 23 Feb 2004 13:27:34 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Unsubscribed listmembers Date: Mon, 23 Feb 2004 13:27:31 +0100 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,UPPERCASE_25_50 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the archives... I have unsubscribed the following list-members as their addresses either are not valid, or their servers refuse to accept mail (and have so for a long period of time) : bskeenes@arin.net PRoberts@MEGISTO.com andy@advsys.com ikkim@cclab.chungnam.ac.kr yhchoi@cclab.chungnam.ac.kr kikim@cclab.chungnam.ac.kr input@ietfwatch.kgbinternet.com - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDnxtqarNKXTPFCVEQKgCQCg/vwvf7NFJNCUqMqNwSXXe7K/ZEAAnAgS 16UBD2o/fOA9zb4MY0RLjxFH =oNxW -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Feb 23 12:18: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 MAA06988 for ; Mon, 23 Feb 2004 12:18:55 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvJi1-000Acs-OT for multi6-data@psg.com; Mon, 23 Feb 2004 17:17:33 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvJi0-000AcY-Is for multi6@ops.ietf.org; Mon, 23 Feb 2004 17:17:32 +0000 Received: from [IPv6:::1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1NHGarq071619; Mon, 23 Feb 2004 18:16:40 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <4F15D4D2-6551-11D8-B86A-000A95928574@kurtis.pp.se> <2DD216A4-65EB-11D8-A884-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: draft-savola-multi6-asn-pi-01.txt Date: Mon, 23 Feb 2004 18:16:11 +0100 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-feb-04, at 12:11, Kurt Erik Lindqvist wrote: > Well, there are a lot of things you can say about the RIR policies, but > let's take that to some other mailinglist :) Too many mailinglists, too little time... Also, the fact that the RIRs don't stick to the policy they themselves (+ IANA) published is a very bad thing. I think the IETF has to set stricter boundaries on what the RIRs can and can't do in their policies. But it's no use discussing this in general, we'll talk about it when it gets more concrete. >> If we want to break aggregation in a way that doesn't break >> scalability then I think we need to put out an RFC that tells people >> how to do it, so that it's actually usable (no point in doing this if >> network operators filter) and scalable. I think it can be done but >> Pekka's draft isn't the way. > I think that the issue of breaking aggregation will have to be part of > the general architectural discussion. Just like any other proposal. Sure, no problem. But this draft isn't the right way to go about it. I think the solution is to be found in the area of shooting holes in provider aggregates. But we need to get away from the ad-hoc way this is done today which couples a relatively low level of redundancy with a high number of additional entries in the global routing table. The fact that we have more or less fixed ISP aggregate and end-user assignment sizes allows us to filter more aggressively so if we couple this part with a set of "if you're going to allow your customers to multihome, this is what you need to do" rules that should do the trick. I'll be happy to write something down either before Seoul or after. From owner-multi6@ops.ietf.org Mon Feb 23 13:19: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 NAA09444 for ; Mon, 23 Feb 2004 13:19:21 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvKeh-000HCZ-TA for multi6-data@psg.com; Mon, 23 Feb 2004 18:18:11 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvKee-000HC7-Tk for multi6@ops.ietf.org; Mon, 23 Feb 2004 18:18:08 +0000 Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Feb 2004 10:18:07 -0800 Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Mon, 23 Feb 2004 10:18:04 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 23 Feb 2004 10:18:06 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Feb 2004 10:16:13 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Feb 2004 10:18:07 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 23 Feb 2004 10:18:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7165.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-savola-multi6-asn-pi-01.txt Date: Mon, 23 Feb 2004 10:17:46 -0800 Message-ID: Thread-Topic: draft-savola-multi6-asn-pi-01.txt Thread-Index: AcP6MavYkQWasvynQyuCYkkvslA9zwABg80A From: "Christian Huitema" To: "Iljitsch van Beijnum" , "Kurt Erik Lindqvist" Cc: "Multi6 List" X-OriginalArrivalTime: 23 Feb 2004 18:18:02.0288 (UTC) FILETIME=[5FBE1B00:01C3FA39] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > >> If we want to break aggregation in a way that doesn't break > >> scalability then I think we need to put out an RFC that tells people > >> how to do it, so that it's actually usable (no point in doing this if > >> network operators filter) and scalable. I think it can be done but > >> Pekka's draft isn't the way. >=20 > > I think that the issue of breaking aggregation will have to be part of > > the general architectural discussion. Just like any other proposal. >=20 > Sure, no problem. But this draft isn't the right way to go about it. I > think the solution is to be found in the area of shooting holes in > provider aggregates. But we need to get away from the ad-hoc way this > is done today which couples a relatively low level of redundancy with a > high number of additional entries in the global routing table.=20 What the RIR actually implement today is a negotiation between some customers who want the benefits of "portable addresses" and the provider community that bears the costs associated with large routing tables. There is nothing particularly wrong with this kind of negotiation process. Routing table inflation has a cost, but the cost is not infinite; portable addresses have benefits, but the benefits are finite. You would expect a negotiation process to stabilize at a point where benefits and costs are more or less matched, and you would expect this point to vary over time. Obviously, what we do here has an effect. Essentially, we can develop tools that make portable addresses less attractive, thus moving the "negotiation point" towards a lesser table inflation.=20 I personally believe that multi-addressing has advantages over portable addresses, because it empowers the host. Selection from multiple addresses provides an easy way to affect the routing of data in the network, and thus can provide better reliabilities than the vagaries of BGP. On the other hand, there are associated costs, e.g. managing several prefixes in a leaf network, handling egress filtering, renumbering.=20 The bottom line is that our only real way to affect policy is by lowering the cost and increasing the benefits of multi-addressing. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Feb 23 13:54: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 NAA11290 for ; Mon, 23 Feb 2004 13:54:10 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvLD7-000Kqy-H4 for multi6-data@psg.com; Mon, 23 Feb 2004 18:53:45 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvLD6-000Kqk-5N for multi6@ops.ietf.org; Mon, 23 Feb 2004 18:53:44 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1NIs7rq072943; Mon, 23 Feb 2004 19:54:07 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <993F2C5A-6631-11D8-8CC0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: draft-savola-multi6-asn-pi-01.txt Date: Mon, 23 Feb 2004 19:53:41 +0100 To: "Christian Huitema" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-feb-04, at 19:17, Christian Huitema wrote: > What the RIR actually implement today is a negotiation between some > customers who want the benefits of "portable addresses" and the > provider > community that bears the costs associated with large routing tables. > There is nothing particularly wrong with this kind of negotiation > process. There is one very big thing wrong with it: the negotiation happens in four (soon five) different places in the world, while the effect that is felt is the the results of these different negotiations. In other words: if AFRINIC adopts a policy that leads to deaggregation in Africa, routers around the world must keep these additional routing table entries in their tables. > Routing table inflation has a cost, but the cost is not > infinite; portable addresses have benefits, but the benefits are > finite. > You would expect a negotiation process to stabilize at a point where > benefits and costs are more or less matched, and you would expect this > point to vary over time. The trouble is that the tradeoff isn't universal, but the outcome needs to be in order to guarantee global connectivity. I worry about this. > The bottom line is that our only real way to affect policy is by > lowering the cost and increasing the benefits of multi-addressing. Sounds like a plan. From owner-multi6@ops.ietf.org Mon Feb 23 16:01: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 QAA19663 for ; Mon, 23 Feb 2004 16:01:28 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvNBd-0008ho-TU for multi6-data@psg.com; Mon, 23 Feb 2004 21:00:21 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvNBc-0008hH-PR for multi6@ops.ietf.org; Mon, 23 Feb 2004 21:00:20 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1NL0irq074687 for ; Mon, 23 Feb 2004 22:00:44 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <49BA3359-6643-11D8-8CC0-000A95CD987A@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: Iljitsch van Beijnum Subject: SCTP for multihoming Date: Mon, 23 Feb 2004 22:00:19 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Lode and others, I've been reading the SCTP for multihoming draft. Here's my feedback. First a more general issue that comes up in the SCTP-related drafts: there is no way for two hosts to find out whether the paths that exist between them share any infrastructure. Would it be useful to see if we can come up with something that allows hosts to find out? I'm thinking something in the way of the record route option. I'm worried about the much more complex packet format (compared to TCP) that SCTP has, such as different chunks that can be in a single packet. Are there any figures available about SCTP implementation complexity and performance? I've been opposed to a strict transport layer solution because then all transport protocols need to be changed. Still, SCTP is here today so why not use it for multihoming in the situations where it suits the job at hand. Another problem with SCTP is that moving applications from TCP to SCTP means both protocols will have to run side by side for a long time. Would it make sense to modify SCTP such that it is possible for applications that expect to run TCP to be multihomed without changes, and also to be backward compatible? The latter could be done by exchanging some "I can do SCTP" options in TCP and then (try to) set up an SCTP session if the other also supports it, or even better, switch to SCTP in mid-flight. And I still think the heartbeats are both evil and most of the time unnecessary. BTW, it would be awesome to have HTTP over SCTP where each of the elements that make up a web page is loaded over a different stream so there is no head of line blocking but the session establishment overhead (both in unnecessary repeating data and in round trip times) that exists today is mitigated. Now that we're firmly in science fiction territory (Tony Hain once suggest we form an "Internet Fantasy Task Force", maybe not such a bad idea...) it occurs to me that SCTP could be wrapped around UDP for long-lived UDP associations and subsequently add multihoming to UDP and UDP-based transport protocols such as RTP. At least, if the stream setup mechanism can be changed to support "one packet streams" efficiently. What do you think? From owner-multi6@ops.ietf.org Mon Feb 23 16:07: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 QAA19863 for ; Mon, 23 Feb 2004 16:07:59 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvNIs-0009Zp-V6 for multi6-data@psg.com; Mon, 23 Feb 2004 21:07:50 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvNIr-0009ZV-KS for multi6@ops.ietf.org; Mon, 23 Feb 2004 21:07:49 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1NL87rq074803; Mon, 23 Feb 2004 22:08:09 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <401E34E3.9090503@nomadiclab.com> References: <401E34E3.9090503@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <51DAF45A-6644-11D8-8CC0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: New multi6 draft: WIMP Date: Mon, 23 Feb 2004 22:07:42 +0100 To: Jukka Ylitalo X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 2-feb-04, at 12:30, Jukka Ylitalo wrote: > A short hash chain generation is a quite fast operation compared to > signature calculation. (If I remember correct, e.g., computing SHA1 > five times over a 160bit string takes under 0.5 ms with 2Ghz pentium.) > The operation is efficient and makes it more diffucult for an attacker > to cause a DoS situation. Actually this is pretty poor. I seem to remember that a significantly slower Pentium can do 2000 DSA signature checks per second. Being able to bring down a host with just 2000 packets per second would be a very bad thing, as this is easily accomplished over 10 Mbps ethernet (approx 500 byte packets). From owner-multi6@ops.ietf.org Mon Feb 23 20:18: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 UAA06508 for ; Mon, 23 Feb 2004 20:18:33 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvRBs-000BXL-H7 for multi6-data@psg.com; Tue, 24 Feb 2004 01:16:52 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvRBr-000BX5-1q for multi6@ops.ietf.org; Tue, 24 Feb 2004 01:16:51 +0000 Received: from [169.223.255.161] (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1O1PNd15005; Mon, 23 Feb 2004 17:25:23 -0800 Date: Tue, 24 Feb 2004 09:10:06 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <1678527996.20040224091006@brandenburg.com> To: Kurt Erik Lindqvist CC: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) In-Reply-To: <9DB8E308-654D-11D8-B86A-000A95928574@kurtis.pp.se> References: <9DB8E308-654D-11D8-B86A-000A95928574@kurtis.pp.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt, KEL> We also had this discussed sometime during the autumn and from what I KEL> remember, most seemed to think that mobility and mutli6 required KEL> solutions with different paramters - to the point where the solutions KEL> would be different solutions. This sufficiently at odds with my own sense of the solution space that I really would appreciate any elaboration of the details folks can conjure up. So far, my sense is that there is a very large amount of overlap between the two problem spaces. No, not 100%, but more than enough to justify seeking a single solution for the common set of requirements. Multihoming is about multiple addresses. Mobility is about multiple addresses. The structure, predictability and timing of address management for the two differ. This might mean they need entirely different mechanisms, but so far it looks like they can do fine with just one. KEL> are you arguing that as part of any solution, we should either include KEL> a address selection / pairing algorithm or we should make that an KEL> "external" requirement to be solved by a separate protocol or by KEL> someone else? Any initial specification needs to provide a complete capability. So I am arguing that we distinguish between near-term "simplistic" choices that provide initial utility, versus longer-term, extended choices that can be pursued outside of the initial critical path. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Feb 23 20:41: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 UAA07277 for ; Mon, 23 Feb 2004 20:41:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvRZR-000EKl-5e for multi6-data@psg.com; Tue, 24 Feb 2004 01:41:13 +0000 Received: from [208.184.79.7] (helo=joy.songbird.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvRZQ-000EKN-7Y for multi6@ops.ietf.org; Tue, 24 Feb 2004 01:41:12 +0000 Received: from [169.223.255.161] (jay.songbird.com [208.184.79.253]) by joy.songbird.com (8.11.6/8.11.6) with ESMTP id i1O1nld17281; Mon, 23 Feb 2004 17:49:47 -0800 Date: Tue, 24 Feb 2004 09:41:05 +0800 From: Dave Crocker Reply-To: Dave Crocker Organization: Brandenburg InternetWorking X-Priority: 3 (Normal) Message-ID: <557474951.20040224094105@brandenburg.com> To: Kurt Erik Lindqvist CC: multi6@ops.ietf.org, "marcelo bagnulo" Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) In-Reply-To: <66347CF0-654F-11D8-B86A-000A95928574@kurtis.pp.se> References: <691756715.20040219081045@brandenburg.com> <1802106614.20040219083419@brandenburg.com> <66347CF0-654F-11D8-B86A-000A95928574@kurtis.pp.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,PRIORITY_NO_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Kurt, (meant to tack this on to my reply of a few minutes ago.) >> The harder question is how to get information about the availability of >> new addresses to the client system? Offhand, I think this requires a >> "push" mechanism from the network, rather than a pull mechanism from >> the >> client, in order to make sure the client learns of the changes in a >> timely fashion. KEL> Following my question in the other mail, do you also see that this KEL> mechanism in some way needs to help with the actual address selection? To the extent that the mechanism for notifying of changes in availability also supplies QOS-related parametric information, yes, it is helping selection. But the actual selection is a separate mechanism, and I think we can get quite a bit of benefit out of a qos entry that is nothing more than exists/doesn't-exist. At any rate, the _use_ of the qos-related information is quite different from creating the database of the info. KEL> So, my concern is that we actually have a problem split in (at least) KEL> two pieces - making the end system aware of what addresses with what KEL> properties are available to it; and from the set of addresses/locators KEL> make the selection of which one to use. yes. however this separation is natural. The activities occur at different times (or, I think, they should) and the hard work probably is done by different entities (the supplier of the qos information, versus the user of it). KEL> You can further complicate the above if we think that selecting a KEL> address for initial communication is one thing, selecting a address for KEL> established communication is something else. Yup. In fact there is one approach to this domain that says the initial mechanism is whatever we already have today and that the mechanism for selections with an existing communication is all that we should pursue in the near-term, because it provides a strategic, incremental enhancement. d/ -- Dave Crocker Brandenburg InternetWorking Sunnyvale, CA USA From owner-multi6@ops.ietf.org Mon Feb 23 21:11: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 VAA07965 for ; Mon, 23 Feb 2004 21:11:06 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvS1n-000IMi-Dw for multi6-data@psg.com; Tue, 24 Feb 2004 02:10:31 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvS1m-000IMT-E9 for multi6@ops.ietf.org; Tue, 24 Feb 2004 02:10:30 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i1NMgZdO027651; Mon, 23 Feb 2004 14:42:55 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i1NMgXQ27534; Mon, 23 Feb 2004 23:42:33 +0100 (MET) Date: Mon, 23 Feb 2004 14:42:38 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: New multi6 draft: WIMP To: Iljitsch van Beijnum Cc: Jukka Ylitalo , Multi6 List In-Reply-To: "Your message with ID" <51DAF45A-6644-11D8-8CC0-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > On 2-feb-04, at 12:30, Jukka Ylitalo wrote: > > > A short hash chain generation is a quite fast operation compared to > > signature calculation. (If I remember correct, e.g., computing SHA1 > > five times over a 160bit string takes under 0.5 ms with 2Ghz pentium.) > > The operation is efficient and makes it more diffucult for an attacker > > to cause a DoS situation. > > Actually this is pretty poor. I seem to remember that a significantly > slower Pentium can do 2000 DSA signature checks per second. Being able > to bring down a host with just 2000 packets per second would be a very > bad thing, as this is easily accomplished over 10 Mbps ethernet (approx > 500 byte packets). I would be interesting in seeing some apple-to-apple comparisons between different security algorithms that might apply to multi6 solutions: One is an anonymous DH exchange - basically the purpose-built keys approach - how much CPU to do the modular exponentiation? Another one is a public key signature (and verification?) A third is performing 5 SHA1 hashes of 160 bits. If I had a better feel for the relative CPU cost of those 3 operations it would be easier for me to understand the performance/DoS aspects of these schemes. Erik From owner-multi6@ops.ietf.org Tue Feb 24 02:41: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 CAA05016 for ; Tue, 24 Feb 2004 02:41:16 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvX9j-000PIm-8x for multi6-data@psg.com; Tue, 24 Feb 2004 07:39:03 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvX9f-000PIF-14 for multi6@ops.ietf.org; Tue, 24 Feb 2004 07:38:59 +0000 Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7F0386A902; Tue, 24 Feb 2004 09:38:57 +0200 (EET) Message-ID: <403AFF0F.4030304@piuha.net> Date: Tue, 24 Feb 2004 09:36:47 +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.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: Iljitsch van Beijnum , Jukka Ylitalo , Multi6 List Subject: Re: New multi6 draft: WIMP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>On 2-feb-04, at 12:30, Jukka Ylitalo wrote: >> >> >>>A short hash chain generation is a quite fast operation compared to >>>signature calculation. (If I remember correct, e.g., computing SHA1 >>>five times over a 160bit string takes under 0.5 ms with 2Ghz pentium.) >>>The operation is efficient and makes it more diffucult for an attacker >>>to cause a DoS situation. >> >>Actually this is pretty poor. I seem to remember that a significantly >>slower Pentium can do 2000 DSA signature checks per second. Being able >>to bring down a host with just 2000 packets per second would be a very >>bad thing, as this is easily accomplished over 10 Mbps ethernet (approx >>500 byte packets). > > > I would be interesting in seeing some apple-to-apple comparisons > between different security algorithms that might apply to multi6 solutions: > > One is an anonymous DH exchange - basically the purpose-built keys approach - > how much CPU to do the modular exponentiation? > > Another one is a public key signature (and verification?) > > A third is performing 5 SHA1 hashes of 160 bits. > > If I had a better feel for the relative CPU cost of those 3 operations it > would be easier for me to understand the performance/DoS aspects of these > schemes. Yes. Actually, I find Jukka's numbers a bit surprising. SHA1 is used on a per-packet basis on IPsec, for instance, and many systems can do this at wire speed. And I always thought that bignum operations (signatures, diffie-hellman) were significantly slower than symmetric operations (SHA1) on the same hardware. Reference http://www.eskimo.com/~weidai/benchmarks.html gives the performance on a 2.1 Ghz Pentium for SHA1 as 72 Mbytes/s; for RSA signature takes 4.65 ms and verification 0.19 according to the same source. However, this does not tell us how many individual SHA1 operations were run, just the data amount. Digging into the source code of Crypto++ library on which the tests from the above link were made... hmm.... it seems that it simply calls hash.update repeatedly. Are we comparing apples to oranges if I assume an individual SHA1 operation cost is according to 72 Mbytes/s? I seem to recall that at least HMAC_SHA1 had some fixed cost component. If anyone has better benchmarks, tell us... Anyway, the way I read Wimp is that the amount of SHA1 data to be calculated under the hash in the packet is ~ 90 bytes. For this, using the above numbers I get 1.19 *microsecond*, not millisecond. The RSA for this would be 4.65 millisecond, or about 4000 times slower. DSA signature would be 2.14 millisecond, or about 2000 times slower (without precomputation). --Jari From owner-multi6@ops.ietf.org Tue Feb 24 04:29: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 EAA08978 for ; Tue, 24 Feb 2004 04:29:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvYrc-0007YO-Lq for multi6-data@psg.com; Tue, 24 Feb 2004 09:28:28 +0000 Received: from [194.78.143.100] (helo=hrtades9.atea.be) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvYra-0007Xh-8w for multi6@ops.ietf.org; Tue, 24 Feb 2004 09:28:27 +0000 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D5YY1B20; Tue, 24 Feb 2004 10:28:15 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 10:28:15 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C2@hrtades7.atea.be> From: Coene Lode To: "'Barany, Pete'" , multi6@ops.ietf.org Cc: "'Michael Tuexen'" , "'Randall R. Stewart (home)'" Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Tue, 24 Feb 2004 10:28:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk I am not a specialist on socket issues.. But Michael & Randall might know a bit more on that... >-----Original Message----- >From: Barany, Pete [mailto:pbarany@qualcomm.com] >Sent: zaterdag 21 februari 2004 19:29 >To: multi6@ops.ietf.org >Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt > > >In the SCTP sockets API Internet draft >(draft-ietf-tsvwg-sctpsocket-07.txt), there is a sendmsg() flag >(MSG_ADDR_OVER) for the one-to-many style that allows the application to >request that the SCTP stack override the primary destination address. Do >implementations honor (mandatory) this request, or can the SCTP stack >override it? Thanks. My take is: The implementation must send the msg on the IP address provided instead of the primary destination address. But if the address provided by the application is not reachable at that particular moment, then the SCTP implementation will try any of the alternative addresses of the association(including the primary destination address) > >Pete > Yours sincerely, Lode From owner-multi6@ops.ietf.org Tue Feb 24 04:39: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 EAA09234 for ; Tue, 24 Feb 2004 04:39:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvZ26-0008ds-Nc for multi6-data@psg.com; Tue, 24 Feb 2004 09:39:18 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvZ25-0008dg-Kq for multi6@ops.ietf.org; Tue, 24 Feb 2004 09:39:17 +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 i1O9dAT29779; Tue, 24 Feb 2004 11:39:10 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 11:37:36 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i1O9baZn029280; Tue, 24 Feb 2004 11:37:36 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00tu0suL; Tue, 24 Feb 2004 11:37:35 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 i1O9bYO02771; Tue, 24 Feb 2004 11:37:34 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 24 Feb 2004 11:37:33 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Tue, 24 Feb 2004 11:37:25 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-coene-multi6-sctp-00.txt Thread-Index: AcP6uSxhiKDx5+25Qn28HzBD+brMLwAAJUqA From: To: , , Cc: , X-OriginalArrivalTime: 24 Feb 2004 09:37:33.0974 (UTC) FILETIME=[D4A14B60:01C3FAB9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Lode, > >In the SCTP sockets API Internet draft > >(draft-ietf-tsvwg-sctpsocket-07.txt), there is a sendmsg() flag > >(MSG_ADDR_OVER) for the one-to-many style that allows the application = to > >request that the SCTP stack override the primary destination address. = Do > >implementations honor (mandatory) this request, or can the SCTP stack > >override it? Thanks. >=20 > My take is: > The implementation must send the msg on the IP address provided > instead of the primary destination address.=20 > But if the address provided by the application is not reachable at = that > particular moment, then the SCTP implementation will try any of the > alternative addresses of the association(including the primary = destination > address) That's how we coded it. John From owner-multi6@ops.ietf.org Tue Feb 24 06:00: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 GAA12893 for ; Tue, 24 Feb 2004 06:00:27 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvaGZ-000Fjh-6d for multi6-data@psg.com; Tue, 24 Feb 2004 10:58:19 +0000 Received: from [194.78.143.100] (helo=hrtades9.atea.be) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvaGX-000FjM-Kf for multi6@ops.ietf.org; Tue, 24 Feb 2004 10:58:17 +0000 Received: from hrtades10.atea.be (siemens.atea.be [139.10.143.141]) by hrtades9.atea.be with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id D5YY1CGQ; Tue, 24 Feb 2004 11:58:16 +0100 Received: by siemens.atea.be with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Feb 2004 11:58:16 +0100 Message-ID: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C4@hrtades7.atea.be> From: Coene Lode To: "'Iljitsch van Beijnum'" , Multi6 List Subject: RE: SCTP for multihoming Date: Tue, 24 Feb 2004 11:58:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk A few comments below.. >-----Original Message----- >From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] >Sent: maandag 23 februari 2004 22:00 >To: Multi6 List >Subject: SCTP for multihoming > > >Lode and others, > >I've been reading the SCTP for multihoming draft. Here's my feedback. > >First a more general issue that comes up in the SCTP-related drafts: >there is no way for two hosts to find out whether the paths that exist >between them share any infrastructure. Would it be useful to see if we >can come up with something that allows hosts to find out? I'm thinking >something in the way of the record route option. > Maybe the tools for that already exist. Use a TRACEROUTE on every IP address of the remote peer and try to detect common IP addresses along the routes. A IP address that show up in 2 or more traceroutes: 2 or more paths going through that router(not taking into account the endpoints/host naturally) This might look as a general tool for detecting shared infrastructure... If traceroute does not fit the bill , then something along the record route option might be usefull... Bear in mind.. This will be a optional tool.. Not everybody is that interested in the routes through the network.. >I'm worried about the much more complex packet format (compared to TCP) >that SCTP has, such as different chunks that can be in a single packet. >Are there any figures available about SCTP implementation complexity >and performance? > Complexity: I haven't seen any papers on that issue. I've heard some claims being made about it and I've gone through the SCTP code itself(unfortunaly not through the TCP code) but I am quite sure that the complexity of TCP and SCTP is of the same order... Performance: some papers have looked at the performance and the result are encouraging, to say the least, esspecially if things start going wrong: if the loss rate takes off, then SCTP will start outperforming TCP by at least 10 to 20%(blame/thank SACK for that..) For more infor look at http://www.sctp.be/ research paper corner(a bit down in the page..) And specific: http://www.eecis.udel.edu/~amer/PEL/poc/index.html > >I've been opposed to a strict transport layer solution because then all >transport protocols need to be changed. Still, SCTP is here today so >why not use it for multihoming in the situations where it suits the job >at hand. Another problem with SCTP is that moving applications from TCP >to SCTP means both protocols will have to run side by side for a long >time. Would it make sense to modify SCTP such that it is possible for >applications that expect to run TCP to be multihomed without changes, >and also to be backward compatible? The latter could be done by >exchanging some "I can do SCTP" options in TCP and then (try to) set up >an SCTP session if the other also supports it, or even better, switch >to SCTP in mid-flight. > Migration scenarios haven't been described in detail in the present draft but that is something that will be expanded in the next iteration of the draft. It is safe to say that TCP and UDP will never disappear of the face of the earth... 3 claases of applications can be found in the wild: - applications that can run on SCTP(only): those are new applications that need specific things... These application are only a small subset of the universe... - applications that can run on TCP and SCTP: Those are new and existing applications.. They make up a part of the universe - appplications that run on TCP: those are existing applications They make up the other part of the universe... The same can be said for UDP(but let's not go there for the moment...) Distibution across the classes?:.. Time will tell.. Already existing applications have to do something (change some lines of code when setting the socket for SCTP..) Or something between the application and TCP/SCTP may do that.... But some work needs to be one... Hey ... There ain't such a thing as a free lunch... >And I still think the heartbeats are both evil and most of the time >unnecessary. > Sighn... Well then how are we going to know whether a IP address of the remote peer endpoint is reachable???... But sometimes you can beat the hell out of your remote endpoint with the heartbeats. (..And I will shut up about what I find evil....) >BTW, it would be awesome to have HTTP over SCTP where each of the >elements that make up a web page is loaded over a different stream so >there is no head of line blocking but the session establishment >overhead (both in unnecessary repeating data and in round trip times) >that exists today is mitigated. Well Randall Stewart has already ported Apache to run on SCTP. The site is multihomed and you can try to access it..For more instructions on how to do it, Look at http://www.sctp.org/ > >Now that we're firmly in science fiction territory (Tony Hain once >suggest we form an "Internet Fantasy Task Force", maybe not such a bad >idea...) it occurs to me that SCTP could be wrapped around UDP for >long-lived UDP associations and subsequently add multihoming to UDP and >UDP-based transport protocols such as RTP. At least, if the stream >setup mechanism can be changed to support "one packet streams" >efficiently. What do you think? > Originally, SCTP was designed to be carried on top of UDP... But then the IESG allowed us to treat it as a separate transport protocol. Funny how the world goes around.. But the idea is still valid.... Now that Partial Reliability SCTP has been approved by the IESG recently, what do you get when you set the the retransmission counter 0 for your PR-SCTP messages/packets? Answer: hey...isn't that UDP.... With congestion control.... And in PR-SCTP the knob can go from 0 retransmissions to a real big number of retransmissions.... And is that usefull???:... Just use MPEG4 streams on PR-SCTP and the picture looks beter... This ain't a fantasy anymore but just plain hard fact...(allright,allright I'm getting too exited...) Implementations: look at http://www.sctp.org/ Hope this helps... Yours sincerely Lode From owner-multi6@ops.ietf.org Tue Feb 24 08: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 IAA17946 for ; Tue, 24 Feb 2004 08:04:50 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvcDW-0000Qt-Ot for multi6-data@psg.com; Tue, 24 Feb 2004 13:03:18 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvcDV-0000Qe-Fj for multi6@ops.ietf.org; Tue, 24 Feb 2004 13:03:17 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OD2sH23329; Tue, 24 Feb 2004 15:02:54 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 15:02:50 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1OD2osi000589; Tue, 24 Feb 2004 15:02:50 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00NKDnNz; Tue, 24 Feb 2004 15:02:48 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 i1OD2g708221; Tue, 24 Feb 2004 15:02:42 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 24 Feb 2004 15:02:42 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: SCTP for multihoming Date: Tue, 24 Feb 2004 15:02:41 +0200 Message-ID: Thread-Topic: RE: SCTP for multihoming Thread-Index: AcP6xfCV3r5o5CJRRwCF5OM+mfDdvQADpY5g From: To: , , X-OriginalArrivalTime: 24 Feb 2004 13:02:42.0432 (UTC) FILETIME=[7D0AF000:01C3FAD6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Lode,=20 > >First a more general issue that comes up in the SCTP-related drafts:=20 > >there is no way for two hosts to find out whether the paths that = exist=20 > >between them share any infrastructure. Would it be useful to see if = we=20 > >can come up with something that allows hosts to find out? I'm = thinking=20 > >something in the way of the record route option. >=20 > Maybe the tools for that already exist.=20 SNIP... What I get the feeling is that Lijitsch is saying that if SCTP is used for Multi6, such a feature may be needed. Lode said: > Use a TRACEROUTE on every IP address of the remote peer and try to = detect > common IP addresses along the routes. > A IP address that show up in 2 or more traceroutes: 2 or more paths = going > through that router(not taking into account the endpoints/host = naturally) > This might look as a general tool for detecting shared = infrastructure... > If traceroute does not fit the bill , then something along the record = route > option might be usefull... Bear in mind.. This will be a optional = tool..=20 > Not everybody is that interested in the routes through the network.. Of course, an optional extension to SCTP to provide this feature could be made ... =20 > >I'm worried about the much more complex packet format (compared to = TCP)=20 > >that SCTP has, such as different chunks that can be in a single = packet.=20 > >Are there any figures available about SCTP implementation complexity=20 > >and performance? We have an implementation of SCTP that outperforms vanilla TCP (from an old BSD varient) in terms of throughput in most simple scenarios. = However, newer versions of TCP generally outperform SCTP. Several papers have = noted that as packet sizes approach MTU, SCTP and TCP perform on about the = same order of magnatude. Code size for SCTP & TCP are on the same order of magnatitude as well. > >I've been opposed to a strict transport layer solution because then = all=20 > >transport protocols need to be changed. Still, SCTP is here today so=20 > >why not use it for multihoming in the situations where it suits the = job=20 > >at hand. Another problem with SCTP is that moving applications from = TCP=20 > >to SCTP means both protocols will have to run side by side for a long = > >time. Would it make sense to modify SCTP such that it is possible for = > >applications that expect to run TCP to be multihomed without changes, = > >and also to be backward compatible? The latter could be done by=20 > >exchanging some "I can do SCTP" options in TCP and then (try to) set = up=20 > >an SCTP session if the other also supports it, or even better, switch = > >to SCTP in mid-flight. I agree with Lode that migration / interworking scenarios should be=20 developed more. Some of this is implementation / deployment related, = but you are right that some discussion of this would be a good thing. John From owner-multi6@ops.ietf.org Tue Feb 24 10:00: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 KAA23758 for ; Tue, 24 Feb 2004 10:00:54 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Ave21-000APA-Av for multi6-data@psg.com; Tue, 24 Feb 2004 14:59:33 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Ave1z-000AOt-UD for multi6@ops.ietf.org; Tue, 24 Feb 2004 14:59:32 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1OExprq089543; Tue, 24 Feb 2004 15:59:53 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <4010F077.AF929268@zurich.ibm.com> References: <4010F077.AF929268@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0AABF9EA-66DA-11D8-8CC0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Comments needed on a few multi6 drafts Date: Tue, 24 Feb 2004 15:59:27 +0100 To: Brian E Carpenter X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 23-jan-04, at 10:59, Brian E Carpenter wrote: > In our draft revised charter we have three aggressive milestones: > MAR 04 Submit informational I-D to IESG on how multihoming is > done today [...] > Could everybody who has further comments on the following drafts > please send them promptly, so that we can ask the various document > authors/editors to prepare new versions for WG Last Call very soon: > draft-ietf-multi6-v4-multihoming-00 (very expired, but you can find it > at > http://www.ietf.org/proceedings/01aug/I-D/draft-ietf-multi6-v4- > multihoming-00.txt) I'm not sure about the purpose of this draft. Is it supposed to explain multihoming to people who don't already know about it? It doesn't really do that. If such a document is needed, I'd be happy to write one. (Think http://www.oreillynet.com/pub/a/network/2002/08/12/multihoming.html but targeted to a more IETF-knowledgeable audience.) From owner-multi6@ops.ietf.org Tue Feb 24 10:20: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 KAA25713 for ; Tue, 24 Feb 2004 10:20:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AveLi-000CO2-27 for multi6-data@psg.com; Tue, 24 Feb 2004 15:19:54 +0000 Received: from [129.46.51.59] (helo=ithilien.qualcomm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AveLY-000CLZ-U1 for multi6@ops.ietf.org; Tue, 24 Feb 2004 15:19:44 +0000 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1OFJcvf001985; Tue, 24 Feb 2004 07:19:38 -0800 (PST) Received: from naexfe02.na.qualcomm.com (naexfe02.qualcomm.com [129.46.51.214]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i1OFJZtQ013944; Tue, 24 Feb 2004 07:19:35 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by naexfe02.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 24 Feb 2004 07:19:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Tue, 24 Feb 2004 07:19:34 -0800 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327D46@NAEX01.na.qualcomm.com> Thread-Topic: I-D ACTION:draft-coene-multi6-sctp-00.txt Thread-Index: AcP62Y3j0JCfnweKQnaeZOqlFm3EPgADx6fA From: "Barany, Pete" To: "Michael Tuexen" , "Coene Lode" Cc: , "Randall R. Stewart \(home\)" X-OriginalArrivalTime: 24 Feb 2004 15:19:35.0605 (UTC) FILETIME=[9C79AE50:01C3FAE9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Thanks all for the responses. One other question (and perhaps this is more suitable for the IETF TSVWG, but it is related to the SCTP multihoming draft). In the ADDIP I-D (draft-ietf-tsvwg-addip-sctp-08.txt), addresses can be added/deleted as described therein. However, in the sockets API I-D (draft-ietf-tsvwg-sctpsocket-07.txt), I see a system call 'sctp_getpaddrs()' which allows the upper layer to get all peer addresses in an association. However, I do not see a notification primitive informing the upper layer when an address has been added/deleted per the ADDIP I-D. It would be relatively easy to code this into an implementation, but shouldn't something like this be in the sockets API I-D? Thanks. Pete -----Original Message----- From: Michael Tuexen [mailto:Michael.Tuexen@micmac.franken.de]=20 Sent: Tuesday, February 24, 2004 4:38 AM To: Coene Lode Cc: multi6@ops.ietf.org; 'Randall R. Stewart (home)'; Barany, Pete Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt Dear all, the way Lode describes it is OK. However, there is some room for implementations... Best regards Michael On 24. Feb 2004, at 10:28 Uhr, Coene Lode wrote: > I am not a specialist on socket issues.. But Michael & Randall might=20 > know a > bit more on that... > >> -----Original Message----- >> From: Barany, Pete [mailto:pbarany@qualcomm.com] >> Sent: zaterdag 21 februari 2004 19:29 >> To: multi6@ops.ietf.org >> Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt >> >> >> In the SCTP sockets API Internet draft >> (draft-ietf-tsvwg-sctpsocket-07.txt), there is a sendmsg() flag >> (MSG_ADDR_OVER) for the one-to-many style that allows the application >> to >> request that the SCTP stack override the primary destination address. >> Do >> implementations honor (mandatory) this request, or can the SCTP stack >> override it? Thanks. > > My take is: > The implementation must send the msg on the IP address provided > instead of the primary destination address. > But if the address provided by the application is not reachable at that > particular moment, then the SCTP implementation will try any of the > alternative addresses of the association(including the primary=20 > destination > address) > >> >> Pete >> > > Yours sincerely, > Lode > From owner-multi6@ops.ietf.org Tue Feb 24 11:19: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 LAA27873 for ; Tue, 24 Feb 2004 11:19:30 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvfGJ-000JfN-LP for multi6-data@psg.com; Tue, 24 Feb 2004 16:18:23 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvfGI-000Jf8-Is for multi6@ops.ietf.org; Tue, 24 Feb 2004 16:18:22 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OGIJK03454; Tue, 24 Feb 2004 18:18:19 +0200 (EET) X-Scanned: Tue, 24 Feb 2004 18:17:31 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i1OGHVKO010676; Tue, 24 Feb 2004 18:17:31 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 000cygQv; Tue, 24 Feb 2004 18:17:29 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1OGHOO19636; Tue, 24 Feb 2004 18:17:24 +0200 (EET) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 24 Feb 2004 18:17:24 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Tue, 24 Feb 2004 18:17:24 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-coene-multi6-sctp-00.txt Thread-Index: AcP62Y3j0JCfnweKQnaeZOqlFm3EPgADx6fAAAI8otA= From: To: , , Cc: , X-OriginalArrivalTime: 24 Feb 2004 16:17:24.0411 (UTC) FILETIME=[B00B78B0:01C3FAF1] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable John, > In the ADDIP I-D (draft-ietf-tsvwg-addip-sctp-08.txt), addresses can = be > added/deleted as described therein. However, in the sockets API I-D > (draft-ietf-tsvwg-sctpsocket-07.txt), I see a system call > 'sctp_getpaddrs()' which allows the upper layer to get all peer > addresses in an association. However, I do not see a notification > primitive informing the upper layer when an address has been > added/deleted per the ADDIP I-D. It would be relatively easy to code > this into an implementation, but shouldn't something like=20 > this be in the sockets API I-D? Thanks. That would probably be best addressed to Randy ... John From owner-multi6@ops.ietf.org Tue Feb 24 15:40: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 PAA09880 for ; Tue, 24 Feb 2004 15:40:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvjLX-000MUm-Sb for multi6-data@psg.com; Tue, 24 Feb 2004 20:40:03 +0000 Received: from [217.174.67.68] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvjLR-000MRS-Ac for multi6@ops.ietf.org; Tue, 24 Feb 2004 20:39:59 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 4BD9D2EF6D2; Tue, 24 Feb 2004 21:40:03 +0100 (CET) In-Reply-To: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C4@hrtades7.atea.be> References: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C4@hrtades7.atea.be> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <2A291562-6709-11D8-970C-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , "'Iljitsch van Beijnum'" From: Kurt Erik Lindqvist Subject: Re: SCTP for multihoming Date: Tue, 24 Feb 2004 21:36:46 +0100 To: Coene Lode X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I've been reading the SCTP for multihoming draft. Here's my feedback. >> >> First a more general issue that comes up in the SCTP-related drafts: >> there is no way for two hosts to find out whether the paths that exist >> between them share any infrastructure. Would it be useful to see if we >> can come up with something that allows hosts to find out? I'm thinking >> something in the way of the record route option. >> > Maybe the tools for that already exist. > Use a TRACEROUTE on every IP address of the remote peer and try to > detect > common IP addresses along the routes. > A IP address that show up in 2 or more traceroutes: 2 or more paths > going > through that router(not taking into account the endpoints/host > naturally) > This might look as a general tool for detecting shared > infrastructure... > If traceroute does not fit the bill , then something along the record > route > option might be usefull... > Bear in mind.. This will be a optional tool.. > Not everybody is that interested in the routes through the network.. I am not sure I agree with Iljitsch requirement, if this is a concern, it will be a concern for any solution. And I don't think it is. However, from my recent anycast experience I can say that todays Internet simply isn't that symmetrical.... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDu14KarNKXTPFCVEQLEzwCgnCWyn/rBXjfqeh+n3Qufy3Wn1zUAnRrP jOFXkCn2Gkn67rzHqjkpclX3 =eg5s -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Feb 24 15:43: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 PAA10039 for ; Tue, 24 Feb 2004 15:43:29 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvjOm-000Mtv-1W for multi6-data@psg.com; Tue, 24 Feb 2004 20:43:24 +0000 Received: from [217.174.67.68] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvjON-000MlU-LB for multi6@ops.ietf.org; Tue, 24 Feb 2004 20:43:06 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 04DE72EF6E0; Tue, 24 Feb 2004 21:42:53 +0100 (CET) In-Reply-To: <557474951.20040224094105@brandenburg.com> References: <691756715.20040219081045@brandenburg.com> <1802106614.20040219083419@brandenburg.com> <66347CF0-654F-11D8-B86A-000A95928574@kurtis.pp.se> <557474951.20040224094105@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, "marcelo bagnulo" From: Kurt Erik Lindqvist Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Tue, 24 Feb 2004 21:13:49 +0100 To: Dave Crocker X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> The harder question is how to get information about the availability >>> of >>> new addresses to the client system? Offhand, I think this requires a >>> "push" mechanism from the network, rather than a pull mechanism from >>> the >>> client, in order to make sure the client learns of the changes in a >>> timely fashion. > KEL> Following my question in the other mail, do you also see that this > KEL> mechanism in some way needs to help with the actual address > selection? > > To the extent that the mechanism for notifying of changes in > availability also supplies QOS-related parametric information, yes, it > is helping selection. > > But the actual selection is a separate mechanism, and I think we can > get quite a bit of benefit out of a qos entry that is nothing more > than exists/doesn't-exist. At any rate, the _use_ of the qos-related > information is quite different from creating the database of the info. First I don't think you want to call it QOS. Also, I am not so sure about this. This would require some form of extra state throughout the edge of the provider network, per customer or in worst case, per node. Right? > KEL> So, my concern is that we actually have a problem split in (at > least) > KEL> two pieces - making the end system aware of what addresses with > what > KEL> properties are available to it; and from the set of > addresses/locators > KEL> make the selection of which one to use. > > yes. however this separation is natural. The activities occur > at different times (or, I think, they should) and the hard work > probably is done by different entities (the supplier of the qos > information, versus the user of it). Yes, but it does make some of the implications below. > KEL> You can further complicate the above if we think that selecting a > KEL> address for initial communication is one thing, selecting a > address for > KEL> established communication is something else. > > Yup. > > In fact there is one approach to this domain that says the initial > mechanism is whatever we already have today and that the mechanism for > selections with an existing communication is all that we should pursue > in the near-term, because it provides a strategic, incremental > enhancement. I think that todays state is a must as fall-back. But I don't have a problem of "multi6 capable host" triggering on new features being announce to it and first trying to use that for connection establishing. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDuwgaarNKXTPFCVEQJEuQCfech3KpBRKpQfJjAMmw1WHdAiuP4AoO7Z Rb0S4rtwgihyMVWh8WJwOPvm =tZNI -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Feb 24 15:44: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 PAA10074 for ; Tue, 24 Feb 2004 15:44:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvjPR-000N57-E2 for multi6-data@psg.com; Tue, 24 Feb 2004 20:44:05 +0000 Received: from [217.174.67.68] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvjPL-000Mwj-JE for multi6@ops.ietf.org; Tue, 24 Feb 2004 20:44:02 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id B430D2EF6E8; Tue, 24 Feb 2004 21:43:53 +0100 (CET) In-Reply-To: <1678527996.20040224091006@brandenburg.com> References: <9DB8E308-654D-11D8-B86A-000A95928574@kurtis.pp.se> <1678527996.20040224091006@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: mbagnulo@ing.uc3m.es, multi6@ops.ietf.org From: Kurt Erik Lindqvist Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) Date: Tue, 24 Feb 2004 21:06:37 +0100 To: Dave Crocker X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > KEL> We also had this discussed sometime during the autumn and from > what I > KEL> remember, most seemed to think that mobility and mutli6 required > KEL> solutions with different paramters - to the point where the > solutions > KEL> would be different solutions. > > This sufficiently at odds with my own sense of the solution space > that I really would appreciate any elaboration of the details folks > can conjure up. > > So far, my sense is that there is a very large amount of overlap > between the two problem spaces. No, not 100%, but more than enough > to justify seeking a single solution for the common set of > requirements. > > Multihoming is about multiple addresses. Mobility is about multiple > addresses. The structure, predictability and timing of address > management for the two differ. This might mean they need entirely > different mechanisms, but so far it looks like they can do fine with > just one. From what I remember of the discussions here on the list, most people seem to see several similarities between the two. However the "failure modes" seemed different as well as the timing for the events. Also, I guess the way the address "learning" is/could be/should be handled in different ways for the two scenarios. I am not convinced that the two are similar enough to be able to use the same mechanisms, even with different parameters. But I would be happy to be proved wrong. :-) However, again I think that this is something we also should provide as input for the architectural analysis. Just as impact on ULPs might vary. > KEL> are you arguing that as part of any solution, we should either > include > KEL> a address selection / pairing algorithm or we should make that an > KEL> "external" requirement to be solved by a separate protocol or by > KEL> someone else? > > Any initial specification needs to provide a complete capability. So > I am arguing that we distinguish between near-term "simplistic" > choices that provide initial utility, versus longer-term, extended > choices that can be pursued outside of the initial critical path. Hmm, this has also been discussed before and the standard counter argument is that we should concentrate resources on one solution as we otherwise risk not having anyone at all. I am not arguing one way or the other, but an interesting question is what do you use to categorize any solution in an architectural evaluation in to the categories you describe? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQDuu16arNKXTPFCVEQIssgCg0BkpI1QeXpU9akttvanWY8lASj4AnimP mdYsuFJRqfRdYTD3CPVMUZcp =Ao8r -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Feb 24 15:44: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 PAA10169 for ; Tue, 24 Feb 2004 15:44:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvjPw-000N99-1b for multi6-data@psg.com; Tue, 24 Feb 2004 20:44:36 +0000 Received: from [193.175.24.27] (helo=mail-n.franken.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avbrn-000OJr-Q7 for multi6@ops.ietf.org; Tue, 24 Feb 2004 12:40:51 +0000 Received: from [10.0.1.2] (p5089F6EF.dip.t-dialin.net [80.137.246.239]) by mail-n.franken.de (Postfix) with ESMTP id 4DC70245E9; Tue, 24 Feb 2004 13:39:09 +0100 (CET) In-Reply-To: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C2@hrtades7.atea.be> References: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C2@hrtades7.atea.be> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4B9D73E0-66C6-11D8-AF58-000A95C37894@micmac.franken.de> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, "'Randall R. Stewart (home)'" , "'Barany, Pete'" From: Michael Tuexen Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Tue, 24 Feb 2004 13:38:06 +0100 To: Coene Lode X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Dear all, the way Lode describes it is OK. However, there is some room for implementations... Best regards Michael On 24. Feb 2004, at 10:28 Uhr, Coene Lode wrote: > I am not a specialist on socket issues.. But Michael & Randall might > know a > bit more on that... > >> -----Original Message----- >> From: Barany, Pete [mailto:pbarany@qualcomm.com] >> Sent: zaterdag 21 februari 2004 19:29 >> To: multi6@ops.ietf.org >> Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt >> >> >> In the SCTP sockets API Internet draft >> (draft-ietf-tsvwg-sctpsocket-07.txt), there is a sendmsg() flag >> (MSG_ADDR_OVER) for the one-to-many style that allows the application >> to >> request that the SCTP stack override the primary destination address. >> Do >> implementations honor (mandatory) this request, or can the SCTP stack >> override it? Thanks. > > My take is: > The implementation must send the msg on the IP address provided > instead of the primary destination address. > But if the address provided by the application is not reachable at that > particular moment, then the SCTP implementation will try any of the > alternative addresses of the association(including the primary > destination > address) > >> >> Pete >> > > Yours sincerely, > Lode > From owner-multi6@ops.ietf.org Tue Feb 24 15:55: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 PAA10717 for ; Tue, 24 Feb 2004 15:55:49 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvjaU-000P16-IP for multi6-data@psg.com; Tue, 24 Feb 2004 20:55:30 +0000 Received: from [66.93.186.36] (helo=stewart.chicago.il.us) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvhjK-000CXk-Mk for multi6@ops.ietf.org; Tue, 24 Feb 2004 18:56:30 +0000 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id i1OIuHMC058689; Tue, 24 Feb 2004 12:56:18 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <403B9E51.1040902@stewart.chicago.il.us> Date: Tue, 24 Feb 2004 12:56:17 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Tuexen CC: Coene Lode , multi6@ops.ietf.org, "'Barany, Pete'" Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt References: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C2@hrtades7.atea.be> <4B9D73E0-66C6-11D8-AF58-000A95C37894@micmac.franken.de> In-Reply-To: <4B9D73E0-66C6-11D8-AF58-000A95C37894@micmac.franken.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Michael: I agree, the way Lode describes it is generally correct... but an implementation MAY not follow this .. one never knows :-> I believe KAME does as Lode describes.. however I can't rememeber how I coded the "Unconfirmed" address case. Either I thus consider it "confirmed" or refuse to send to it :-D... its the CRS syndrom ... I will look into this when I get a few cycles to see how I did it :-D R Michael Tuexen wrote: > Dear all, > > the way Lode describes it is OK. However, there is some > room for implementations... > > Best regards > Michael > > On 24. Feb 2004, at 10:28 Uhr, Coene Lode wrote: > >> I am not a specialist on socket issues.. But Michael & Randall might >> know a >> bit more on that... >> >>> -----Original Message----- >>> From: Barany, Pete [mailto:pbarany@qualcomm.com] >>> Sent: zaterdag 21 februari 2004 19:29 >>> To: multi6@ops.ietf.org >>> Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt >>> >>> >>> In the SCTP sockets API Internet draft >>> (draft-ietf-tsvwg-sctpsocket-07.txt), there is a sendmsg() flag >>> (MSG_ADDR_OVER) for the one-to-many style that allows the >>> application to >>> request that the SCTP stack override the primary destination >>> address. Do >>> implementations honor (mandatory) this request, or can the SCTP stack >>> override it? Thanks. >> >> >> My take is: >> The implementation must send the msg on the IP address provided >> instead of the primary destination address. >> But if the address provided by the application is not reachable at that >> particular moment, then the SCTP implementation will try any of the >> alternative addresses of the association(including the primary >> destination >> address) >> >>> >>> Pete >>> >> >> Yours sincerely, >> Lode >> > > > -- Randall R. Stewart 815-477-2127 (office) 815-342-5222 (cell phone) From owner-multi6@ops.ietf.org Tue Feb 24 15:56: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 PAA10744 for ; Tue, 24 Feb 2004 15:56:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvjbW-000P6Q-Hx for multi6-data@psg.com; Tue, 24 Feb 2004 20:56:34 +0000 Received: from [66.93.186.36] (helo=stewart.chicago.il.us) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvhoL-000D7D-E6 for multi6@ops.ietf.org; Tue, 24 Feb 2004 19:01:41 +0000 Received: from stewart.chicago.il.us (stewart.chicago.il.us [127.0.0.1]) by stewart.chicago.il.us (8.12.8p1/8.12.8) with ESMTP id i1OJ1PMC058723; Tue, 24 Feb 2004 13:01:26 -0600 (CST) (envelope-from randall@stewart.chicago.il.us) Message-ID: <403B9F85.9060706@stewart.chicago.il.us> Date: Tue, 24 Feb 2004 13:01:25 -0600 From: "Randall R. Stewart (home)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com CC: pbarany@qualcomm.com, Michael.Tuexen@micmac.franken.de, Lode.Coene@siemens.com, multi6@ops.ietf.org Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] john.loughney@nokia.com wrote: >John, > > > >>In the ADDIP I-D (draft-ietf-tsvwg-addip-sctp-08.txt), addresses can be >>added/deleted as described therein. However, in the sockets API I-D >>(draft-ietf-tsvwg-sctpsocket-07.txt), I see a system call >>'sctp_getpaddrs()' which allows the upper layer to get all peer >>addresses in an association. However, I do not see a notification >>primitive informing the upper layer when an address has been >>added/deleted per the ADDIP I-D. It would be relatively easy to code >>this into an implementation, but shouldn't something like >>this be in the sockets API I-D? Thanks. >> >> > >That would probably be best addressed to Randy ... > >John > > > > > Section 5.3.1.2 covers the adding and deleting of socket addresses in the -07 socket draft... a socket-api conformant implementation that supports ADD-IP SHOULD (at least in theory) give such a notification. R -- Randall R. Stewart 815-477-2127 (office) 815-342-5222 (cell phone) From owner-multi6@ops.ietf.org Tue Feb 24 15:58: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 PAA10814 for ; Tue, 24 Feb 2004 15:58:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avjd6-000PPw-Uy for multi6-data@psg.com; Tue, 24 Feb 2004 20:58:12 +0000 Received: from [193.175.24.27] (helo=mail-n.franken.de) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AviLa-000G86-VO for multi6@ops.ietf.org; Tue, 24 Feb 2004 19:36:03 +0000 Received: from [10.0.1.3] (p5089F6EF.dip.t-dialin.net [80.137.246.239]) by mail-n.franken.de (Postfix) with ESMTP id 82AB72462E; Tue, 24 Feb 2004 20:34:18 +0100 (CET) In-Reply-To: <403B9E51.1040902@stewart.chicago.il.us> References: <57FD2C3A246F76438CA6FDAD8FE9F195A7F4C2@hrtades7.atea.be> <4B9D73E0-66C6-11D8-AF58-000A95C37894@micmac.franken.de> <403B9E51.1040902@stewart.chicago.il.us> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <49AD8793-6700-11D8-A77D-000A95DC192A@micmac.franken.de> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, Coene Lode , "'Barany, Pete'" From: Michael Tuexen Subject: Re: I-D ACTION:draft-coene-multi6-sctp-00.txt Date: Tue, 24 Feb 2004 20:33:14 +0100 To: "Randall R. Stewart (home)" X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,RCVD_IN_NJABL, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit [ post by non-subscriber. with the massive amount of spam, it is easy to miss and therefore delete posts by non-subscribers. if you wish to regularly post from an address that is not subscribed to this mailing list, send a message to -owner@ops.ietf.org and ask to have the alternate address added to the list of addresses from which submissions are automatically accepted. ] Randy, see my comments below. Best regards Michael On Feb 24, 2004, at 7:56 PM, Randall R. Stewart (home) wrote: > Michael: > > I agree, the way Lode describes it is generally correct... but an > implementation MAY not follow this .. one never knows :-> > That's why I wrote 'there is room for implementations'. > I believe KAME does as Lode describes.. however I can't > rememeber how I coded the "Unconfirmed" address case. Either > I thus consider it "confirmed" or refuse to send to it :-D... its > the CRS syndrom ... I will look into this when I get a few cycles > to see how I did it :-D I remember that you said that you would handle this as an implicit 'confirmation', like using connect_x and then send it. But I do not know if this is what the code does... > > R > > Michael Tuexen wrote: > >> Dear all, >> >> the way Lode describes it is OK. However, there is some >> room for implementations... >> >> Best regards >> Michael >> >> On 24. Feb 2004, at 10:28 Uhr, Coene Lode wrote: >> >>> I am not a specialist on socket issues.. But Michael & Randall might >>> know a >>> bit more on that... >>> >>>> -----Original Message----- >>>> From: Barany, Pete [mailto:pbarany@qualcomm.com] >>>> Sent: zaterdag 21 februari 2004 19:29 >>>> To: multi6@ops.ietf.org >>>> Subject: RE: I-D ACTION:draft-coene-multi6-sctp-00.txt >>>> >>>> >>>> In the SCTP sockets API Internet draft >>>> (draft-ietf-tsvwg-sctpsocket-07.txt), there is a sendmsg() flag >>>> (MSG_ADDR_OVER) for the one-to-many style that allows the >>>> application to >>>> request that the SCTP stack override the primary destination >>>> address. Do >>>> implementations honor (mandatory) this request, or can the SCTP >>>> stack >>>> override it? Thanks. >>> >>> >>> My take is: >>> The implementation must send the msg on the IP address provided >>> instead of the primary destination address. >>> But if the address provided by the application is not reachable at >>> that >>> particular moment, then the SCTP implementation will try any of the >>> alternative addresses of the association(including the primary >>> destination >>> address) >>> >>>> >>>> Pete >>>> >>> >>> Yours sincerely, >>> Lode >>> >> >> >> > > > -- > Randall R. Stewart > 815-477-2127 (office) > 815-342-5222 (cell phone) > > > From owner-multi6@ops.ietf.org Tue Feb 24 17:32: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 RAA14646 for ; Tue, 24 Feb 2004 17:32:09 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avl5B-0009aU-LD for multi6-data@psg.com; Tue, 24 Feb 2004 22:31:17 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avl58-0009a0-N3 for multi6@ops.ietf.org; Tue, 24 Feb 2004 22:31:14 +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 i1OMV10J019773; Tue, 24 Feb 2004 14:31:02 -0800 (PST) Received: from bobo (bobo.SFBay.Sun.COM [129.146.89.81]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i1OMUxQ14974; Tue, 24 Feb 2004 23:30:59 +0100 (MET) Date: Tue, 24 Feb 2004 14:31:04 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: modules of a mh solution (was RE: New multi6 draft: WIMP) To: Dave Crocker Cc: Kurt Erik Lindqvist , mbagnulo@ing.uc3m.es, multi6@ops.ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Multihoming is about multiple addresses. Mobility is about multiple > addresses. The structure, predictability and timing of address > management for the two differ. This might mean they need entirely > different mechanisms, but so far it looks like they can do fine with > just one. I agree that there is a lot of commonality between mobile IP (at least the route optimization part) and host multihoming. But when looking at the details things might diverge. For instance, schemes like NOID which derive their sense of security from the DNS don't handle nodes that receive temporary care-of-addresses; the FQDN<->IP address relationship has to be relatively static. (As an aside, it would be good to try to relax this constraint but that might make NOID less secure.) Also, when looking at site multihoming one might come up with schemes that scale well for site granularity but that would have scaling problems when handling host multihoming. If this is the case then presumably there would be problems scaling to host mobility as well. The only example I have of this is the future works section in the SIM draft which speaks of using a hash of a per-site key plus a hash of a host delegation certificate as the ID with the hope that a DHT can scale to doing site lookups from a flat space. (This is far from certain though.) Hopefully the above two examples illustrate that it isn't given that a site multihoming solution would also be capable of solving host mobility. For this reason I think we shouldn't require that solutions handle mobility - but it would be a nice thing to have. Erik From owner-multi6@ops.ietf.org Tue Feb 24 17:42: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 RAA14862 for ; Tue, 24 Feb 2004 17:42:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvlFy-000Abq-QN for multi6-data@psg.com; Tue, 24 Feb 2004 22:42:26 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvlFx-000AbQ-J8 for multi6@ops.ietf.org; Tue, 24 Feb 2004 22:42:25 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1OMgjrq095731; Tue, 24 Feb 2004 23:42:46 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <1719934176.20040211160612@brandenburg.com> References: <1719934176.20040211160612@brandenburg.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: re: celp draft Date: Tue, 24 Feb 2004 23:42:21 +0100 To: Dave Crocker X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 12-feb-04, at 1:06, Dave Crocker wrote: >> http://www.ietf.org/internet-drafts/draft-crocker-celp-00.txt Still catching up... Let me start by strongly disagreeing with: "The basic goal, then, is to find a method for multiaddressing that makes the smallest possible change" IF a change is necessary, it would be stupid to optimize for a small change, as the difference in deployment effort between nog change and a small change is HUGE while the difference between a small change and a larger change isn't very substantial. If changes are necessary, we must make sure we get it right the first time if at all possible. A good example is the change to the socket API when IPv6 was introduced. This change was kept as small as possible, but despite that 5 years later only a fraction of all applications have been updated. And now that we're talking about multihoming we may have to change this API again, or bend over backwards to avoid it. I also disagree with the assertion that transport-based solutions would save on the number of packets exchanged. A wedge solution can monitor transport interactions to see whether there is still connectivity. And the currently existing transport solution, SCTP, adds lots of extra packets by periodically probing connectivity on all paths. In cases where there are two or more backup paths this can save a little on recovery time after a rehoming event, but I think the cure is worse than the illness here and in the case of only one backup path it doesn't help anyway: if the primary path fails the only possible course of action is to use the backup path, regardless of whether we "know" that it works or not. (Obviously when one path fails changes to the other paths at the same time aren't unthinkable so all existing knowledge is suspect.) Also, on the ipv6mh list we had extensive discussions about keepalives and I think I made a good case for taking advantage of path overlap between different destinations, making it possible to reduce the number of keepalives to each individual destination while retaining the desired average failure detection times. "Enhanced transport services access the pool directly. Legacy transport services access the pool via the IP wedge layer service." Ok, this is the part I like. However, this reads like you expect the enhanced transports and the wedge mechanism to live together without sharing any mechanisms. I think that would be a missed opportunity. And I think you're right there is lots of stuff that overlaps with what we're doing in multi6 going on, we need to figure out how to handle this. The fact that there hasn't been significant interaction with the mobility people yet despite the general recognition that there is overlap that has existed for years, isn't a good sign here. One problem: how do we know that different addresses point to the same entity? Within a protocol this could probably be implied, but between protocols this can easily become problematic. For instance, some protocols may not care that a set of addresses points to different hosts providing the same service, while for other protocols switching hosts isn't likely to work. It also works the other way around: if we don't recognize two addresses belong to the same entity we may lose an opportunity to switch between those addresses later. Maybe having identifiers isn't such a bad thing after all... Later: "From my own sense of the net and from the responses so far, I believe that a host can maintain an address pool based solely on a simple list of the destination's addresses. That is, for the near term, the combinatorial complexities of considering local/remote address pairs can be deferred. Of course, the implications (that is, the limitations) of this simplifying assumption need to be stated." Again: we have to do it right the first time if we possibly can. Deferring this also doesn't make sense as ingress filtering by ISPs makes source address problems too common to be able to ignore safely even if ignoring failures in the middle of a path would be considered a good idea. From owner-multi6@ops.ietf.org Wed Feb 25 03:23: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 DAA02920 for ; Wed, 25 Feb 2004 03:23:39 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvuHX-000LDa-JM for multi6-data@psg.com; Wed, 25 Feb 2004 08:20:39 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvuHW-000LDO-4n for multi6@ops.ietf.org; Wed, 25 Feb 2004 08:20:38 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1P8Ktrq003738; Wed, 25 Feb 2004 09:20:55 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7AC0E880-676B-11D8-8CC0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: port blocking (was Re: CELP (was RE:) ) Date: Wed, 25 Feb 2004 09:20:32 +0100 To: Tim Shepard X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 16-feb-04, at 19:01, Tim Shepard wrote: >> As a side note, how is HIP going to allow port blocking? Will it avoid >> worm attacks by its puzzle mechanism. I don't think it is possible >> (but >> it can reduce its spawning speed.) > How does IPSEC allow port blocking? As far as I know, it does not. > After > the IKE exchange establishes a SA, ESP hides the TCP port numbers. > HIP has no better answer to this question than IPSEC, or any other > protocol > that provides for encryption between strangers. > "Having an encrypted conversation with a stranger may be like meeting > that > person in a dark alley. Whatever happens, there are no witnesses." Why would anyone want to filter based on port numbers? It provides no real security, just headaches. On the other hand, I can understand that people are unconfortable having internal hosts communicate with external ones without being able to see what's going on. A way to solve this would be to include firewalls in the authentication and authorization negotiations. From owner-multi6@ops.ietf.org Wed Feb 25 03:35: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 DAA03321 for ; Wed, 25 Feb 2004 03:35:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvuW0-000Mtz-D8 for multi6-data@psg.com; Wed, 25 Feb 2004 08:35:36 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvuVz-000Mtd-98 for multi6@ops.ietf.org; Wed, 25 Feb 2004 08:35:35 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1P8Ztrq003933; Wed, 25 Feb 2004 09:35:55 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9326551E-676D-11D8-8CC0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: draft-savola-multi6-asn-pi-01.txt Date: Wed, 25 Feb 2004 09:35:32 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 20-feb-04, at 17:21, Pekka Savola wrote: >> While limiting this to 15 bits worth of AS numbers solves some >> problems, it also immediately removes much of the potential use from >> this proposal, as this way there is still no solution for people who >> want/need to multihome in IPv6 but don't have an AS number today. > I've targeted this solution for the biggest corporations, for which > (IMHO) multiple addresses are a non-starter. Such corporations have > AS numbers. Such corporations don't crop up from nowhere. The trouble with large corporations is that they typically have many offices. Now either all of those connect to the net individually, and then having a single AS and a single block of address space is of little use, or those offices are connected through a private network that also carries internet traffic, in which case they are their own ISP and they should qualify for an AS and address space like regular ISPs. (The 200 customers within 2 years requirement might be slightly problematic but there is push to lower this a bit anyway.) > But if folks feel we should just allow everyone, one could just as > well allow full 16 bits or even 32 bits. That would just lead to the > exhaustion of AS numbers, though -- and folks would be worse off than > before, as also small enterprises would get AS numbers for the "easy > multihoming ticket". I agree that would be a bad idea. From owner-multi6@ops.ietf.org Wed Feb 25 03:43: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 DAA03547 for ; Wed, 25 Feb 2004 03:43:34 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvudX-000Ntl-7R for multi6-data@psg.com; Wed, 25 Feb 2004 08:43:23 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvudV-000NtS-RQ for multi6@ops.ietf.org; Wed, 25 Feb 2004 08:43:22 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1P8hEL30894; Wed, 25 Feb 2004 10:43:14 +0200 Date: Wed, 25 Feb 2004 10:43:14 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: draft-savola-multi6-asn-pi-01.txt In-Reply-To: <9326551E-676D-11D8-8CC0-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 25 Feb 2004, Iljitsch van Beijnum wrote: > The trouble with large corporations is that they typically have many > offices. Now either all of those connect to the net individually, and > then having a single AS and a single block of address space is of > little use, Well, it could be of a lot of use. But as noted before by Craig Huegen (at least), if using a single netblock, these corporations would have traffic engineering requirements. If more specific routes aren't allowed for traffic engineering purposes, or advertising just a regional subset of address space, this is not enough for a solution. An alternative mechanism, which I have stated earlier, is to "divide-and-conquer" even the larger enterprises: every branch which connects to ISPs has different addresses. This will be pure hell for network admins if they have offices in e.g. 100 or 200 countries, but such is life, I guess... :) Of course, almost all solutions have ignored these traffic engineering considerations. > or those offices are connected through a private network > that also carries internet traffic, in which case they are their own > ISP and they should qualify for an AS and address space like regular > ISPs. (The 200 customers within 2 years requirement might be slightly > problematic but there is push to lower this a bit anyway.) IMHO, the RIR allocation policies do not allow an /32 for this specific case of "Enterprise network having its customers within the enterprise". -- 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 Feb 25 04:06: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 EAA04033 for ; Wed, 25 Feb 2004 04:06:07 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Avuz4-0000hg-2k for multi6-data@psg.com; Wed, 25 Feb 2004 09:05:38 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Avuz2-0000hT-P2 for multi6@ops.ietf.org; Wed, 25 Feb 2004 09:05:36 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1P95wrq004367; Wed, 25 Feb 2004 10:05:58 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Multi6 List" From: Iljitsch van Beijnum Subject: Re: host-centric draft Date: Wed, 25 Feb 2004 10:05:35 +0100 To: X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 20-feb-04, at 18:37, marcelo bagnulo wrote: > for instance, the options that you were mentioning that is missing, > could > you expand on this? > The two layer 3 network that you mention, would this be like a > multihomed > host? The idea is that you build two separate layer 3 networks so that the host gets to make a choice in which network they inject the packet and then there is no complexity moving packets from the part that talks to ISP A to the part that talks to ISP B. The simple way to do this would be to have two network interfaces on each host, where one NIC has an address from ISP A and talks to routers that eventually connect to ISP A, while the other NIC has an address from ISP B and only talks to routers connected to ISP B. A slightly more complex way to do this would be to have the host use different virtual interfaces over a single NIC (using VLANs or some such). >> The problem that rerouting could invalidate an earlier source address >> choice isn't mentioned. > Could expand this too? perhaps an example? Host X wants to talk to remote host Y. X sends packets with source addresses compatible with ISP A to a router that delivers the packet to ISP A and life is good, despite the fact that the router doesn't do source address based routing. Now the link to ISP A fails, so the router reroutes the packets to Y over ISP B. But now the source addresses used by this session are incompatbile with the way the packet is routed. Life is not so good, especially if this was a legacy session that doesn't support changing addresses during the session. Now in this example the problem isn't too bad because the session would have failed also if the site was single homed to ISP A. But if the site uses BGP to determine the best path, it may also reroute traffic over a different ISP if the first ISP is still available. So then we're breaking sessions that would have worked without multihoming. That can't be what we want. So any kind of dynamic best path selection can't be used unless ALL sessions can change addresses. >> I'm unsure why we would want to inject BGP information into hosts. > I don't think that injecting BGP routing table has been considered in > the > draft (but i may be forgetting something) What's all the talk about BGP in the draft about then? >> Reachability yes/no isn't very useful as the actual reachability >> status >> of the other side is in almost all cases hidden by aggregation. So >> basically this only indicates whether the ISP in question is >> available. >> Determining preference based on BGP information is also a relatively >> futile endeavor > Well, > as i see it, there are two systems that can be aware of reachability: > the > routing system or the end host itself > The end host can discover reachability by itself, simply trying to send > packets to the other end. This is more reliable way to discover > reachability, since the host is actually reaching the target. Right. > The other option is to use the routing system. As you mention, the > information provided by the routing system is aggregated, so it hides > some > information. However, the routing system has the information in > advance, while the host has to discover it when it needs it. Our current interdomain routing system doesn't deliver actual reachability information. It is _extremely_ rare for an entire ISP / address block from an ISP to be down. And it's well-established that BGP is very slow to propagate the fact that a prefix is no longer reachable. So I would strongly advice against taking "reachable yes/no" information from BGP. And as explained above, doing path selection based on BGP properties is also problematic. > So the host obtained by the host is more accurate, but the routing > system > provides it faster, i guess. So the question is: can we detect the actual reachability using probes fast enough that we don't feel we also need to look in the routing tables? If end-to-end is 30 seconds while routing table is 30 microseconds, then sure, I agree that the latter is useful. If end-to-end is 3 seconds, maybe having to wait this long some of the time is better than importing all this BGP complexity. If it's 300 milliseconds I'm sure it is. >> I don't really agree. Applications need to try all addresses for a >> correspondent. Some do this today, most don't. And this needs to be >> done in a smart way, a four minute timout between trying successive >> addresses isn't acceptable. > Well, rfc 3484 already states that > "Well-behaved applications SHOULD iterate through the list of > addresses returned from getaddrinfo() until they find a working > address." > But i agree with you, something about this can be included here. > The other point about this is when considering retrying with different > source addresses. If you do this sequentially, i think that it would > be up to the app to retry. > However if you do it in parallel, i think that the ip layer could > simply > generate multiple packets and send them in parallel, so no need to > change > the apps. Agree. But then, we probably want to try multiple destination addresses at the same time too, which can't be done without changes. And we probably want to have a way to signal to the other side "these are all really the same session, don't be worried about the session setup being aborted for the alternative ones". From owner-multi6@ops.ietf.org Wed Feb 25 04:26: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 EAA05298 for ; Wed, 25 Feb 2004 04:26:57 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvvIb-0002Uh-6M for multi6-data@psg.com; Wed, 25 Feb 2004 09:25:49 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvvIZ-0002U5-2k for multi6@ops.ietf.org; Wed, 25 Feb 2004 09:25:47 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1P9QArq004663; Wed, 25 Feb 2004 10:26:10 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <97EE7C6E-6774-11D8-8CC0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org From: Iljitsch van Beijnum Subject: Re: draft-savola-multi6-asn-pi-01.txt Date: Wed, 25 Feb 2004 10:25:47 +0100 To: Pekka Savola X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 25-feb-04, at 9:43, Pekka Savola wrote: >> The trouble with large corporations is that they typically have many >> offices. Now either all of those connect to the net individually, and >> then having a single AS and a single block of address space is of >> little use, > Well, it could be of a lot of use. It could be, but I'm not convinced it is most of the time. > But as noted before by Craig > Huegen (at least), if using a single netblock, these corporations > would have traffic engineering requirements. Everyone who multihomes and doesn't have huge piles of money to burn has traffic engineering requirements. I agree this is problematic, and we need to revisit this at some point. > If more specific routes > aren't allowed for traffic engineering purposes, or advertising just a > regional subset of address space, this is not enough for a solution. Guess what, it is allowed, but most people filter these routes out. > An alternative mechanism, which I have stated earlier, is to > "divide-and-conquer" even the larger enterprises: every branch which > connects to ISPs has different addresses. This will be pure hell for > network admins if they have offices in e.g. 100 or 200 countries, but > such is life, I guess... :) One man's "pure hell" is another man's job security. :-) Why should BigCorp Inc. be allowed to announce 200 /40s for 200 offices, when a collection of 200 small corportations isn't allowed to do the same thing collectively? It's very simple: either you announce your entire block everywhere and carry traffic from location A that needs to be in location B over your own network, or be like anyone else and get PA space (which you can then use for multiaddress multihoming). >> or those offices are connected through a private network >> that also carries internet traffic, in which case they are their own >> ISP and they should qualify for an AS and address space like regular >> ISPs. > IMHO, the RIR allocation policies do not allow an /32 for this > specific case of "Enterprise network having its customers within the > enterprise". Yes, the current "200 customers in 2 years" requirement is problematic (although I'm sure a fortune 500 company can meet it, just give your employees /48s or some such) but so far nobody has been able to come up with something better. From owner-multi6@ops.ietf.org Wed Feb 25 04:36: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 EAA06155 for ; Wed, 25 Feb 2004 04:36:43 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvvSm-0003K4-84 for multi6-data@psg.com; Wed, 25 Feb 2004 09:36:20 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvvSg-0003Ik-0e for multi6@ops.ietf.org; Wed, 25 Feb 2004 09:36:14 +0000 Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by n2.nomadiclab.com (Postfix) with ESMTP id E4756212C33; Wed, 25 Feb 2004 11:36:12 +0200 (EET) Date: Wed, 25 Feb 2004 11:36:12 +0200 (EET) From: Jukka Ylitalo To: Jari Arkko Cc: Erik Nordmark , Iljitsch van Beijnum , Multi6 List Subject: Re: New multi6 draft: WIMP In-Reply-To: <403AFF0F.4030304@piuha.net> Message-ID: References: <403AFF0F.4030304@piuha.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Yes. Actually, I find Jukka's numbers a bit surprising. SHA1 is used Thanks for correcting me Jari. The question is about microseconds, not milliseconds. Br, Jukka > on a per-packet basis on IPsec, for instance, and many systems can do > this at wire speed. And I always thought that bignum operations (signatures, > diffie-hellman) were significantly slower than symmetric operations (SHA1) > on the same hardware. > > Reference http://www.eskimo.com/~weidai/benchmarks.html gives the performance > on a 2.1 Ghz Pentium for SHA1 as 72 Mbytes/s; for RSA signature takes 4.65 ms > and verification 0.19 according to the same source. However, this does not tell > us how many individual SHA1 operations were run, just the data amount. > Digging into the source code of Crypto++ library on which the tests from > the above link were made... hmm.... it seems that it simply calls hash.update > repeatedly. Are we comparing apples to oranges if I assume an individual > SHA1 operation cost is according to 72 Mbytes/s? I seem to recall that > at least HMAC_SHA1 had some fixed cost component. If anyone has better > benchmarks, tell us... > > Anyway, the way I read Wimp is that the amount of SHA1 data to be calculated > under the hash in the packet is ~ 90 bytes. For this, using the above numbers > I get 1.19 *microsecond*, not millisecond. The RSA for this would be 4.65 > millisecond, or about 4000 times slower. DSA signature would be 2.14 millisecond, > or about 2000 times slower (without precomputation). > > --Jari From owner-multi6@ops.ietf.org Wed Feb 25 04:46: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 EAA06993 for ; Wed, 25 Feb 2004 04:46:40 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvvcV-0004Td-5P for multi6-data@psg.com; Wed, 25 Feb 2004 09:46:23 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvvcS-0004SF-08 for multi6@ops.ietf.org; Wed, 25 Feb 2004 09:46:20 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1P9kVrq004947; Wed, 25 Feb 2004 10:46:31 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <403AFF0F.4030304@piuha.net> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <701B60C6-6777-11D8-8CC0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: New multi6 draft: WIMP Date: Wed, 25 Feb 2004 10:46:08 +0100 To: Jukka Ylitalo X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 25-feb-04, at 10:36, Jukka Ylitalo wrote: >> Yes. Actually, I find Jukka's numbers a bit surprising. SHA1 is used > Thanks for correcting me Jari. The question is about microseconds, > not milliseconds. So you can do a SHA-1 hash chain length 5 in 0.5 microseconds??? That seems awfully fast, just 1000 clockcycles... From owner-multi6@ops.ietf.org Wed Feb 25 08:50: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 IAA16445 for ; Wed, 25 Feb 2004 08:50:24 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AvzOr-0002d2-7r for multi6-data@psg.com; Wed, 25 Feb 2004 13:48:33 +0000 Received: from [66.92.66.146] (helo=alva.home) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AvzOp-0002cp-Uq for multi6@ops.ietf.org; Wed, 25 Feb 2004 13:48:32 +0000 Received: from shep (helo=alva.home) by alva.home with local-esmtp (Exim 3.36 #1 (Debian)) id 1AvzOY-0000OA-00; Wed, 25 Feb 2004 08:48:14 -0500 From: Tim Shepard To: Iljitsch van Beijnum cc: Multi6 List Subject: Re: port blocking (was Re: CELP (was RE:) ) In-reply-to: Your message of Wed, 25 Feb 2004 09:20:32 +0100. <7AC0E880-676B-11D8-8CC0-000A95CD987A@muada.com> Date: Wed, 25 Feb 2004 08:48:14 -0500 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > Why would anyone want to filter based on port numbers? It provides no > real security, just headaches. On the other hand, I can understand that > people are unconfortable having internal hosts communicate with > external ones without being able to see what's going on. A way to solve > this would be to include firewalls in the authentication and > authorization negotiations. Well, I agree with you. But apparently there are some who have raised objections to end-to-end encryption that does not allow a meddling middlebox to discriminate based on port numbers. I was just pointing out that any such objection to HIP would be no different than an objection to IPSEC in general. -Tim Shepard shep@alum.mit.edu From owner-multi6@ops.ietf.org Wed Feb 25 10:29: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 KAA21897 for ; Wed, 25 Feb 2004 10:29:37 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aw0xl-000FEP-Kt for multi6-data@psg.com; Wed, 25 Feb 2004 15:28:41 +0000 Received: from [18.26.0.122] (helo=mercury.lcs.mit.edu) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw0xk-000FEC-6F for multi6@ops.ietf.org; Wed, 25 Feb 2004 15:28:40 +0000 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D37D3872E3; Wed, 25 Feb 2004 10:28:39 -0500 (EST) To: multi6@ops.ietf.org Subject: Re: draft-savola-multi6-asn-pi-01.txt Cc: jnc@mercury.lcs.mit.edu Message-Id: <20040225152839.D37D3872E3@mercury.lcs.mit.edu> Date: Wed, 25 Feb 2004 10:28:39 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > From: Pekka Savola > every branch which connects to ISPs has different addresses. This will > be pure hell for network admins if they have offices in e.g. 100 or 200 > countries, but such is life, I guess... :) And those 100-200 branches also have different street/mailing addresses, right? Which causes all sorts of grief in having to have 200 different kinds of pre-printed stationery with street/mailing addresses on it, etc, etc, etc. But people don't piss/moan/whine about it, because that's a fundamental aspect of street/mailing addresses. The routing has to have "names" which are topologically significant. If people want a namespace which *doesn't* have those properties, because they find those properties *inconvenient*, then they can get off their tailbones and add one. Harumph. Noel PS: Pekka, I know you understand this already; this is just a sore spot with me. From owner-multi6@ops.ietf.org Wed Feb 25 12:09: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 MAA00246 for ; Wed, 25 Feb 2004 12:09:19 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aw2WC-0003GZ-So for multi6-data@psg.com; Wed, 25 Feb 2004 17:08:20 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw2WB-0003GK-VM for multi6@ops.ietf.org; Wed, 25 Feb 2004 17:08:20 +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 i1PH8Ci5012920; Wed, 25 Feb 2004 10:08:13 -0700 (MST) Received: from lillen (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i1PH8AQ02448; Wed, 25 Feb 2004 18:08:10 +0100 (MET) Date: Wed, 25 Feb 2004 09:06:36 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: host-centric draft To: Iljitsch van Beijnum Cc: mbagnulo@ing.uc3m.es, Multi6 List In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > So the question is: can we detect the actual reachability using probes > fast enough that we don't feel we also need to look in the routing > tables? If end-to-end is 30 seconds while routing table is 30 > microseconds, then sure, I agree that the latter is useful. If > end-to-end is 3 seconds, maybe having to wait this long some of the > time is better than importing all this BGP complexity. If it's 300 > milliseconds I'm sure it is. That's on the benefit side, but also have too look at the cost side in terms of scaling. If all hosts perform e2e probing of all the local/peer locator pairs this might add up to a lot of packets; might be more than the amount of data packets that are exchanged in some cases (imagine hosts being sensors which only send a data packet every 30 seconds and now you add probing 4 or so local/peer locator pairs!). If we care about *site* (and not *host*) multihoming one could try to have hosts share the information they learn from probing with their neighboring hosts. But that leads more or less to reinventing a routing protocol. Erik From owner-multi6@ops.ietf.org Wed Feb 25 12:44: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 MAA02256 for ; Wed, 25 Feb 2004 12:44:25 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aw34f-0007Qn-N4 for multi6-data@psg.com; Wed, 25 Feb 2004 17:43:57 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw34c-0007QY-HN for multi6@ops.ietf.org; Wed, 25 Feb 2004 17:43:54 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1PHiGrq011391; Wed, 25 Feb 2004 18:44:17 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2C4F5D6C-67BA-11D8-997E-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: host-centric draft Date: Wed, 25 Feb 2004 18:43:51 +0100 To: Erik Nordmark X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 25-feb-04, at 18:06, Erik Nordmark wrote: >> So the question is: can we detect the actual reachability using probes >> fast enough that we don't feel we also need to look in the routing >> tables? > That's on the benefit side, but also have too look at the cost side > in terms of scaling. > If all hosts perform e2e probing of all the local/peer locator pairs > this might add up to a lot of packets; I'm afraind looking at the routing table first has very little impact on the number of reachability probes that are sent. After all, any given prefix is present in BGP 99% or more of the time, but we still don't know whether a certain address within that prefix is reachable. So only in the 1% of all cases where the routing table tells us the prefix is unavailable we save something. > might be more than the amount of > data packets that are exchanged in some cases (imagine hosts being > sensors > which only send a data packet every 30 seconds and now you add probing > 4 or > so local/peer locator pairs!). That's why I think we should only perform reachability checks when we already know or at least have a strong suspicion that something is wrong. One possible exception is session establishment: it might be useful to try several setup attempts in parallel, as the one that completes the fastest is probably also the one that offers best peformance during the session. > If we care about *site* (and not *host*) multihoming one could try to > have hosts share the information they learn from probing with their > neighboring hosts. But that leads more or less to reinventing > a routing protocol. I think this would be useful (how many routing protocols are there? still room for one more) but we have other things on our plate right now. From owner-multi6@ops.ietf.org Wed Feb 25 14: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 OAA06687 for ; Wed, 25 Feb 2004 14:24:18 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Aw4cv-000K2c-Eq for multi6-data@psg.com; Wed, 25 Feb 2004 19:23:25 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1Aw4ct-000K1c-GU for multi6@ops.ietf.org; Wed, 25 Feb 2004 19:23:23 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 74A4DA011; Wed, 25 Feb 2004 20:23:22 +0100 (CET) Received: from lolo (lolo.it.uc3m.es [163.117.139.223]) by smtp01.uc3m.es (Postfix) with SMTP id 40F3D9F6B; Wed, 25 Feb 2004 20:23:22 +0100 (CET) Reply-To: From: "marcelo bagnulo" To: "Iljitsch van Beijnum" Cc: "Multi6 List" Subject: RE: host-centric draft Date: Wed, 25 Feb 2004 20:21:30 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The idea is that you build two separate layer 3 networks so that the > host gets to make a choice in which network they inject the packet and > then there is no complexity moving packets from the part that talks to > ISP A to the part that talks to ISP B. The simple way to do this would > be to have two network interfaces on each host, where one NIC has an > address from ISP A and talks to routers that eventually connect to ISP > A, while the other NIC has an address from ISP B and only talks to > routers connected to ISP B. A slightly more complex way to do this > would be to have the host use different virtual interfaces over a > single NIC (using VLANs or some such). Ok, i see what you mean now, but i am not sure that this approach is very attractive though. There are two possibilities, as you explain: - different physical paths: this is very expensive, i guess and normally, you don't have to build a parallel network when you add a new ISP. So, while i can see that some networks, with extreme fault tolerance requirements may find this attractive, i see it a bit too much for a general solution. - VLANs approach. this would be an option. However, i am not so sure about how simple to manage would this be. I mean you will have to create VLANs all over the multihomed site, which AFAIK would be a manual process, right?. I don't know, we can explore a bit more this, but i think that it would be similar than using some sort of source address dependent routing, but even more complex. > > >> The problem that rerouting could invalidate an earlier source address > >> choice isn't mentioned. > > > Could expand this too? perhaps an example? > > Host X wants to talk to remote host Y. X sends packets with source > addresses compatible with ISP A to a router that delivers the packet to > ISP A and life is good, despite the fact that the router doesn't do > source address based routing. Now the link to ISP A fails, so the > router reroutes the packets to Y over ISP B. But now the source > addresses used by this session are incompatbile with the way the packet > is routed. Life is not so good, especially if this was a legacy session > that doesn't support changing addresses during the session. > > Now in this example the problem isn't too bad because the session would > have failed also if the site was single homed to ISP A. But if the site > uses BGP to determine the best path, it may also reroute traffic over a > different ISP if the first ISP is still available. So then we're > breaking sessions that would have worked without multihoming. That > can't be what we want. So any kind of dynamic best path selection can't > be used unless ALL sessions can change addresses. This would is addressed in the draft, since the rules for selecting the path is first determined by the source address (no matter if the path is preferred or not) and only if there is no path through the isp associated with this source address the packet is discarded and the initiating host is informed. See the rules detailed in section 7.2.1 But anyway, i think that your concerns about bgp are more general than this particular case, so let's consider this with a broader approach. Remember that the draft only deals with the problem of discovering a reachable locator for initial contact. It does not address the problem of preserving established communications There are two approaches proposed in the draft: - A host based approach, where the host tries with all the possible combinations of source and destination addresses (probably in parallel) and it selects the combination that provides faster response. - an hybrid approach, where the host tries with one combination of source and destination address and instead of waiting until timeout, it is the routing system that informs about reachability to the initiating host. That means, routers close to the exit site run BGP and knows about which addresses are reachable through which isps. Then the host generates a packet with a given source and destination address, and when it reaches one of these routers that run bgp, the routers knows if this packet will probably make it or not, since it has knowledge about which destinations are reachable through which providers. So, if the router knows that the packet won't make it its final destination, it just discards it and informs the host that it should try with a different source address, or just abort, because the requested destination is unreachable. This approach seems to provide a faster answer because the router already has reachability information, as opposed to the host that has to discover it through polling. Now, your concern seems to be (as you have expanded in a following email) that the information in the router is not really valuable, since most of the time all the prefixes are in the global routing table, and that aggregation hides most of the relevant information. Do you have any data to back this up? I don't really have a preference here about any of the two approaches, i only think that running bgp would be too much for small sites, so host based approach would suit better for this case. But when considering medium/big sites, i get the feeling that people think that BGP information is pretty valuable and that an hybrid approach would provide some value. I mean, is what we use today, and packets make it most of the time. But as you have mentioned already, as more aggregated the routing tables are, the less valuable bgp information will be. > [...] > > So the host obtained by the host is more accurate, but the routing > > system > > provides it faster, i guess. > > So the question is: can we detect the actual reachability using probes > fast enough that we don't feel we also need to look in the routing > tables? If end-to-end is 30 seconds while routing table is 30 > microseconds, then sure, I agree that the latter is useful. If > end-to-end is 3 seconds, maybe having to wait this long some of the > time is better than importing all this BGP complexity. If it's 300 > milliseconds I'm sure it is. Actually i think that if we accept that bgp will only provide hints (how strong they are, we haven't agreed yet), we may still have to rely on end host probes when using BGP hints. > > >> I don't really agree. Applications need to try all addresses for a > >> correspondent. Some do this today, most don't. And this needs to be > >> done in a smart way, a four minute timout between trying successive > >> addresses isn't acceptable. > > > Well, rfc 3484 already states that > > "Well-behaved applications SHOULD iterate through the list of > > addresses returned from getaddrinfo() until they find a working > > address." > > > But i agree with you, something about this can be included here. > > > The other point about this is when considering retrying with different > > source addresses. If you do this sequentially, i think that it would > > be up to the app to retry. > > > However if you do it in parallel, i think that the ip layer could > > simply > > generate multiple packets and send them in parallel, so no need to > > change > > the apps. > > Agree. But then, we probably want to try multiple destination addresses > at the same time too, which can't be done without changes. And we > probably want to have a way to signal to the other side "these are all > really the same session, don't be worried about the session setup being > aborted for the alternative ones". > YEs but i am focussing only in discoverung a reachable locator for initiating a communication :-) Regards, marcelo From owner-multi6@ops.ietf.org Thu Feb 26 02:08: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 CAA20311 for ; Thu, 26 Feb 2004 02:08:53 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwFcZ-000GUF-UA for multi6-data@psg.com; Thu, 26 Feb 2004 07:07:47 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwFcY-000GTz-IU for multi6@ops.ietf.org; Thu, 26 Feb 2004 07:07:46 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i1Q77ib17311; Thu, 26 Feb 2004 09:07:44 +0200 Date: Thu, 26 Feb 2004 09:07:44 +0200 (EET) From: Pekka Savola To: Iljitsch van Beijnum cc: multi6@ops.ietf.org Subject: Re: draft-savola-multi6-asn-pi-01.txt In-Reply-To: <97EE7C6E-6774-11D8-8CC0-000A95CD987A@muada.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 25 Feb 2004, Iljitsch van Beijnum wrote: > On 25-feb-04, at 9:43, Pekka Savola wrote: > > IMHO, the RIR allocation policies do not allow an /32 for this > > specific case of "Enterprise network having its customers within the > > enterprise". > > Yes, the current "200 customers in 2 years" requirement is problematic > (although I'm sure a fortune 500 company can meet it, just give your > employees /48s or some such) but so far nobody has been able to come up > with something better. I've been contacted about this off-list, so let me clarify. The current policy is more than just "200 /48's". To be more specific, you have to make the allocations to *other organizations*. From RIPE policy, which is identical to the "global policy proposal" in this aspect: ---- 5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organisation must: a) be an LIR; b) not be an End Site; c) plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation; and d) have a plan for making at least 200 /48 assignments to other organisations within two years. ---- -- 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 Feb 26 05:54: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 FAA03741 for ; Thu, 26 Feb 2004 05:54:26 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AwJ7R-000FuD-F1 for multi6-data@psg.com; Thu, 26 Feb 2004 10:51:53 +0000 Received: from [131.160.193.2] (helo=n2.nomadiclab.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AwJ7P-000Ftq-On for multi6@ops.ietf.org; Thu, 26 Feb 2004 10:51:51 +0000 Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 36989212C33; Thu, 26 Feb 2004 12:51:50 +0200 (EET) Date: Thu, 26 Feb 2004 12:51:50 +0200 (EET) From: Jukka Ylitalo To: Iljitsch van Beijnum Cc: Multi6 List Subject: Re: New multi6 draft: WIMP In-Reply-To: <701B60C6-6777-11D8-8CC0-000A95CD987A@muada.com> Message-ID: References: <403AFF0F.4030304@piuha.net> <701B60C6-6777-11D8-8CC0-000A95CD987A@muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk > So you can do a SHA-1 hash chain length 5 in 0.5 microseconds??? That > seems awfully fast, just 1000 clockcycles... Jari gave us excellent bench mark results. There is no big difference if I didn't remember the exact time. Is it 0.5 or 2 microseconds, it doesn't matter. Let's focus on the essential issues. The main point was that the hash chain computation is much more efficient than public key crypto. Right? -- Jukka From owner-multi6@ops.ietf.org Sun Feb 29 09:13: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 JAA23576 for ; Sun, 29 Feb 2004 09:13:36 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxRdv-000NJx-Oq for multi6-data@psg.com; Sun, 29 Feb 2004 14:10:07 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxRdu-000NJj-4w for multi6@ops.ietf.org; Sun, 29 Feb 2004 14:10:06 +0000 Received: from d12relay01.megacenter.de.ibm.com (d12relay01.megacenter.de.ibm.com [9.149.165.180]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i1TEA3RT083642 for ; Sun, 29 Feb 2004 14:10:03 GMT Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1TEA67D226276 for ; Sun, 29 Feb 2004 15:10:07 +0100 Received: from zurich.ibm.com (sig-9-145-175-186.de.ibm.com [9.145.175.186]) by collon.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA31474 for ; Sun, 29 Feb 2004 15:09:54 +0100 Message-ID: <4041E82B.3A1502C7@zurich.ibm.com> Date: Sun, 29 Feb 2004 14:24:59 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Multi6 Subject: Seoul Multi6 meeting Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Unfortunately I cannot be in Seoul, so Kurtis will be running the meeting this week. However, I would like to remind people that in our new charter, which is the final stage of IESG approval, it is stated that "Development of specific solutions will require approval of the IESG (e.g., a recharter)." and one of our milestones is "APR 04 First draft of architectural evaluation" so although it is good to see such a variety of preliminary solution drafts, our main job now is not to design a specific solution, but to conduct the architectural analysis that will lead to a choice of approach. That's why these two agenda items are very important: 4. draft-lear-multi6-things-to-think-about-00.txt, 30 mins, Eliot Lear 5. Architectural analysis, Geoff Huston, 20 mins. I hope the meeting goes well. Brian Carpenter multi6 co-chair From owner-multi6@ops.ietf.org Sun Feb 29 10:48: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 KAA27699 for ; Sun, 29 Feb 2004 10:48:41 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxT99-000Mgd-L6 for multi6-data@psg.com; Sun, 29 Feb 2004 15:46:27 +0000 Received: from [213.156.1.123] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1AxT98-000MgR-AC for multi6@ops.ietf.org; Sun, 29 Feb 2004 15:46:26 +0000 Received: from [127.0.0.1] (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i1TFklrq087873 for ; Sun, 29 Feb 2004 16:46:47 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <6DF65BFE-6ACE-11D8-9DA7-000A95CD987A@muada.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: Iljitsch van Beijnum Subject: Ad-hoc streaming Date: Sun, 29 Feb 2004 16:46:24 +0100 X-Mailer: Apple Mail (2.612) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In response to my message a while ago, Kurtis has graciously offered to do some ad-hoc streaming for those of us who won't be participating in person. If you're interested, please have a look at http://www.muada.com/multi6streaming.php and send me a message if you want to participate, so I can make sure there are no bandwidth problems with the streaming server. Expect 300 kbps or less for video, or just 32 kbps audio. Also note that when the wednesday morning session starts it's still tuesday evening and night in the US and Europe, respectively. :-) And if anyone has information on the jabber situation, please send it my way... Iljitsch From owner-multi6@ops.ietf.org Sun Feb 29 20:52: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 UAA22830 for ; Sun, 29 Feb 2004 20:52:56 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1Axcal-000Gq1-Ok for multi6-data@psg.com; Mon, 01 Mar 2004 01:51:35 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1Axcah-000GpB-Oi for multi6@ops.ietf.org; Mon, 01 Mar 2004 01:51:31 +0000 Received: (qmail 33494 invoked from network); 1 Mar 2004 01:50:28 -0000 Received: from cfw2-mohta.dhcp.ietf59.or.kr (HELO necom830.hpcl.titech.ac.jp) (218.37.229.112) by necom830.hpcl.titech.ac.jp with SMTP; 1 Mar 2004 01:50:28 -0000 Message-ID: <404297A5.8020006@necom830.hpcl.titech.ac.jp> Date: Mon, 01 Mar 2004 10:53:41 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Brian E Carpenter CC: Multi6 Subject: Re: Seoul Multi6 meeting References: <4041E82B.3A1502C7@zurich.ibm.com> In-Reply-To: <4041E82B.3A1502C7@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Brian; > so although it is good to see such a variety of preliminary > solution drafts, our main job now is not to design a specific > solution, but to conduct the architectural analysis that > will lead to a choice of approach. That's why these two agenda > items are very important: > 4. draft-lear-multi6-things-to-think-about-00.txt, 30 mins, Eliot Lear > 5. Architectural analysis, Geoff Huston, 20 mins. g/[Aa]rchitectural/s//requirement/g > so although it is good to see such a variety of preliminary > solution drafts, our main job now is not to design a specific > solution, but to conduct the requirement analysis that > will lead to a choice of approach. That's why these two agenda > items are very important: > 4. draft-lear-multi6-things-to-think-about-00.txt, 30 mins, Eliot Lear > 5. requirement analysis, Geoff Huston, 20 mins. You are looping. Masataka Ohta From owner-multi6@ops.ietf.org Sun Feb 29 20:56: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 UAA23017 for ; Sun, 29 Feb 2004 20:56:08 -0500 (EST) Received: from lserv by psg.com with local (Exim 4.30; FreeBSD) id 1AxceT-000HuA-JL for multi6-data@psg.com; Mon, 01 Mar 2004 01:55:25 +0000 Received: from [131.112.32.132] (helo=necom830.hpcl.titech.ac.jp) by psg.com with smtp (Exim 4.30; FreeBSD) id 1AxceS-000Hto-NN for multi6@ops.ietf.org; Mon, 01 Mar 2004 01:55:24 +0000 Received: (qmail 33507 invoked from network); 1 Mar 2004 01:54:22 -0000 Received: from cfw2-mohta.dhcp.ietf59.or.kr (HELO necom830.hpcl.titech.ac.jp) (218.37.229.112) by necom830.hpcl.titech.ac.jp with SMTP; 1 Mar 2004 01:54:22 -0000 Message-ID: <4042988E.7050506@necom830.hpcl.titech.ac.jp> Date: Mon, 01 Mar 2004 10:57:34 +0900 From: Masataka Ohta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Multi6 List Subject: List of IDs required to read? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Since chairs worked hard to make ID deadline on proposals completely fuzzy, it is not clear what are the valid proposals and what are not. Can chairs provide list of IDs required to read for the next session? Can Geoff provide list of IDs considered in his presentation? Masataka Ohta