From owner-multi6@ops.ietf.org Thu Jul 1 03:58: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 DAA02929 for ; Thu, 1 Jul 2004 03:58:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfwRR-000Nuw-G3 for multi6-data@psg.com; Thu, 01 Jul 2004 07:57:09 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfwRP-000Nu7-NV for multi6@ops.ietf.org; Thu, 01 Jul 2004 07:57:08 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 4979848E051; Thu, 1 Jul 2004 09:57:10 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <3D0D030A-CB34-11D8-A581-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 , Iljitsch van Beijnum From: Kurt Erik Lindqvist Subject: Re: identifiers and security Date: Thu, 1 Jul 2004 09:57:03 +0200 To: Erik Nordmark X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Catching up a bit] On 2004-06-28, at 13.52, Erik Nordmark wrote: > > Thus something which is quite insecure (weaker than NOID as above) when > IPsec isn't used, but when IPsec is used it is as strong as with IPsec > in > today's Internet. > Is anybody interested in exploring these ideas further? Personally I think that we at some point need to clarify the "do no harm" view. I.e do we want to try and achieve something better than today? Or is relying on the security extension headers of IPv6 give us some slack? Or do we just agree that the world is ok today and trying to do better is shooting for the stars? I personally wouldn't mind aiming for something a bit higher than today. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQOPD0qarNKXTPFCVEQLbjACgpMCLlTWA5QTXLStMOEJKErl/Dx0An33D oVSIXu9eHjQktzyFIVta6/uc =p8By -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 1 04:05:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03199 for ; Thu, 1 Jul 2004 04:05:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfwZM-000Oud-Er for multi6-data@psg.com; Thu, 01 Jul 2004 08:05:20 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfwZK-000Otg-Om for multi6@ops.ietf.org; Thu, 01 Jul 2004 08:05:19 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id B5B2F48E1EF; Thu, 1 Jul 2004 10:05:20 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <5EABF672-CB35-11D8-A581-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , marcelo bagnulo braun From: Kurt Erik Lindqvist Subject: Re: about Wedgelayer 3.5 / Fat IP approaches Date: Thu, 1 Jul 2004 10:05:08 +0200 To: Erik Nordmark X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-28, at 14.35, Erik Nordmark wrote: >> In this case, the multi6 layer could provide enhanced services and >> preserve connectivity even if the locator used on the refferral or >> call >> back becomes unreachable. >> So i guess that we can have 4 cases: >> a- non multi6 aware app running on a non multi6 aware host: in this >> case a locator must be used for refferals >> b- non multi6 aware app running on a multi6 aware host: in this case >> the app will pass the 128 bit string that it is using to the other >> end. >> So the multi6 layer has to be capable to obtain the locator set form >> this 128 bit string i.e. we need an id to locator mapping mechanism > > It is actually more constrained than that since other instances of > the application might be running on non-multi6 aware hosts. > So the conservative approach would be to always hand an IP > address/locator > to unmodified applications, that way the application can use it > for callbacks and referrals without any constraints on which hosts the > different instances of the app is running. For a transition scenario this will most likely more be the rule than the exception. SIP comes to mind of an application where you would do referrals and you can not trust that all "nodes" are of the same "instance"/protocol version/awareness. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQOPFuKarNKXTPFCVEQKT0QCg/eOifwbywPqBgcwcl0Kw2A5QZj8AoJFh Dk+jyIfwZcadamZqSRMvpF4S =y2oT -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 1 04: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 EAA03425 for ; Thu, 1 Jul 2004 04:10:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfweD-000PS5-9w for multi6-data@psg.com; Thu, 01 Jul 2004 08:10:21 +0000 Received: from [207.69.200.25] (helo=barry.mail.mindspring.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfweC-000PRg-BV for multi6@ops.ietf.org; Thu, 01 Jul 2004 08:10:20 +0000 Received: from 1cust161.tnt59.dfw5.da.uu.net ([67.203.43.161] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BfweB-0007yp-00 for multi6@ops.ietf.org; Thu, 01 Jul 2004 04:10:20 -0400 Message-ID: <40E3E05A.21917106@ix.netcom.com> Date: Thu, 01 Jul 2004 02:58:51 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: "multi6@ops.ietf.org" Subject: Court Says Customers May Take IPs Away From ISP - profound impact on RIR's as well? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=1.0 required=5.0 tests=BAYES_44,RCVD_IN_NJABL, RCVD_IN_SORBS,TO_ADDRESS_EQ_REAL autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit All, "Huston, I think we have a problem"! http://www.merit.edu/mail.archives/nanog/msg05815.html Could this perhaps have an impact on the current allocation and Multihoming in IPv6 in the near term? Seems so. Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Thu Jul 1 04:11: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 EAA03485 for ; Thu, 1 Jul 2004 04:11:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfwew-000PXq-R0 for multi6-data@psg.com; Thu, 01 Jul 2004 08:11:06 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfwev-000PXH-K0 for multi6@ops.ietf.org; Thu, 01 Jul 2004 08:11:06 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 45C8C48E280; Thu, 1 Jul 2004 10:11:08 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <2ECA5E67-CB36-11D8-A581-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 , Iljitsch van Beijnum From: Kurt Erik Lindqvist Subject: Re: identity persistence and comparison issues Date: Thu, 1 Jul 2004 10:10:58 +0200 To: Erik Nordmark X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-28, at 14.45, Erik Nordmark wrote: >> What if we just always show the application a long-lived identifier, >> even though when it sets up a session we use ephemeral identifiers? > > That's part of what Jukka and I were pondering a bit. > I think it is very interesting; just need to make sure that > the additional local mapping on the host from the long-lived to > the ephemeral doesn't introduce attacks that we don't know how to > handle. Without having thought this through very much I have a few questions on this, As you would need to keep state that would be very much like a cache. Would you not open your self up for "cache-poisoning" very much like todays DNS? - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQOPHFaarNKXTPFCVEQLEqACfX3JL9KkJQkiflYwE8rosfUE8otQAoLuh CIRhucKydadbJeOfgWlNAK/D =fNTb -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 1 04:31: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 EAA04781 for ; Thu, 1 Jul 2004 04:31:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfwyT-0001E9-1O for multi6-data@psg.com; Thu, 01 Jul 2004 08:31:17 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfwyR-0001Dq-Hr for multi6@ops.ietf.org; Thu, 01 Jul 2004 08:31:16 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 4F3B848E40E; Thu, 1 Jul 2004 10:31:18 +0200 (CEST) In-Reply-To: <40E3E05A.21917106@ix.netcom.com> References: <40E3E05A.21917106@ix.netcom.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <02263B70-CB39-11D8-A581-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: "multi6@ops.ietf.org" From: Kurt Erik Lindqvist Subject: Re: Court Says Customers May Take IPs Away From ISP - profound impact on RIR's as well? Date: Thu, 1 Jul 2004 10:31:11 +0200 To: Jeff Williams X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 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-07-01, at 11.58, Jeff Williams wrote: > All, > > "Huston, I think we have a problem"! > http://www.merit.edu/mail.archives/nanog/msg05815.html > > Could this perhaps have an impact on the current allocation > and Multihoming in IPv6 in the near term? Seems so. No. And there is a lot more to this story than what is in that email. And it is all very off-topic for this list. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQOPL1KarNKXTPFCVEQJYiwCaAkOepH/9rBAC5p1PloqofH8VdfAAn2nC mlRSxsLMyV1l3f2IHw5hHhpO =QaBt -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 1 04:50: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 EAA05771 for ; Thu, 1 Jul 2004 04:50:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfxGS-0002l1-Un for multi6-data@psg.com; Thu, 01 Jul 2004 08:49:52 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfxGR-0002kX-UF for multi6@ops.ietf.org; Thu, 01 Jul 2004 08:49:52 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i618lh53003650; Thu, 1 Jul 2004 02:47:44 -0600 (MDT) Received: from localhost (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 i618nU203486; Thu, 1 Jul 2004 10:49:31 +0200 (MEST) Date: Thu, 1 Jul 2004 01:49:30 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: about Wedgelayer 3.5 / Fat IP approaches To: "Henderson, Thomas R" Cc: marcelo bagnulo braun , Jukka Ylitalo , Multi6 List , Erik Nordmark In-Reply-To: "Your message with ID" <6938661A6EDA8A4EA8D1419BCE46F24C04060722@xch-nw-27.nw.nos.boeing.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.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 > So, assuming that HIP hosts started to use low order bits of the > HIT in their locators, and then used such a locator as an AID, > the main differences I see are in the use of/reliance on PK crypto > in the context establishment handshakes, as well as IPsec reliance > (HIP relies on PK signings for handshakes, and relies on IPsec, > while CB64 relies on neither), and some of the basic protocol > mechanisms of the two proposals (which one might argue are just > details): > - CB64 handshake occurs in parallel with start of data transfer > (actually, after first data packet has been sent), while HIP holds > the first packet waiting for HIP handshake to complete (or > possibly piggybacks it on the HIP exchange). I think this is the only issue which is tied to the type of ID that is used. In HIP as defined, since the ID used by the transport is not a locator, the handshake must occur before ULP packets can be exchange. But with a CB64 AID that is also a locator one has the option to do them concurrently or even defer the handshake. > - CB64 uses flow IDs and locators as keys to find context state > for the session, while HIP uses IPsec SPIs And Pekka Nikander has told me that it wouldn't be hard to have HIP optionally use the same scheme if HIP wanted to support the case when the payload is not encrypted. > - CB64 adds new locator for peer upon discovering it as a source > address in a packet (and issuing PK-signed challenge/response), > while HIP explicitly signals the new locator in a signed HIP > exchange. For CB64 this derives from allowing router rewriting of the locators as a way to signal changes in the working/desired path. I don't think this is tied to the format of the ID so HIP and CB64 could be made to behave whichever way we desire here. > Another difference is length of the hash of the key, which may > cause some subtle differences. With 64 bit IDs (or, strictly > speaking, ID tags, since the public keys are the actual > identifiers), we can provide an embedded stack name in the AID, > whereas with HITs, we can only provide a mapping between > (truncated) stack name and AIDs. When we have discussed > shortening HITs to accommodate some structure to aid reverse > lookups, there have been concerns raised that 64 bit IDs might > not be strong enough to withstand server farm attacks in the > future (generating different key that hashes to same ID). > If a larger hash is used as the identifier, then the AID with > truncated HIT can be viewed as a slightly less secure > identifier used for support of referrals for non-multi6/HIP > aware apps, which keeps the door open for future HIP-aware > apps to directly use the full IDs. But there are some cases where the larger ID (that doesn't fit in the AID seen by the ULPs) does not help. Example: busy server receives a context from a client with large ID = X and AID=P1 | hash(X) Server later receives a context from a client with large ID = Y and AID=P1 | hash(Y) and the hash values are identical. Even though the multihoming layer can disambiguate the two contexts, it can not handle both at the same time because the ULP can not tell them apart. Thus when a packet would be passed down from the ULP, the multihoming layer wouldn't know which of the two contexts to use for transmitting the packet. The number of contexts the server can handle before this probability of collisions is an issue is of course a function of the hash size. With 64 bits of hash handling 4 Billion contexts concurrently would imply about .5 probability that two have the same hash, but the prefixes would most likely be different so that the AIDs would be different. Erik From owner-multi6@ops.ietf.org Thu Jul 1 05:07: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 FAA06569 for ; Thu, 1 Jul 2004 05:07:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfxWX-0004gc-QY for multi6-data@psg.com; Thu, 01 Jul 2004 09:06:29 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfxWW-0004gI-Ch for multi6@ops.ietf.org; Thu, 01 Jul 2004 09:06:28 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7B3722A1E2; Thu, 1 Jul 2004 11:06:27 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 63EB82A1BC; Thu, 1 Jul 2004 11:06:27 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13910A32-CB3E-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: 7bit Cc: "Henderson, Thomas R" , Jukka Ylitalo , Multi6 List From: marcelo bagnulo braun Subject: Re: about Wedgelayer 3.5 / Fat IP approaches Date: Thu, 1 Jul 2004 11:07:28 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > >> Another difference is length of the hash of the key, which may >> cause some subtle differences. With 64 bit IDs (or, strictly >> speaking, ID tags, since the public keys are the actual >> identifiers), we can provide an embedded stack name in the AID, >> whereas with HITs, we can only provide a mapping between >> (truncated) stack name and AIDs. When we have discussed >> shortening HITs to accommodate some structure to aid reverse >> lookups, there have been concerns raised that 64 bit IDs might >> not be strong enough to withstand server farm attacks in the >> future (generating different key that hashes to same ID). >> If a larger hash is used as the identifier, then the AID with >> truncated HIT can be viewed as a slightly less secure >> identifier used for support of referrals for non-multi6/HIP >> aware apps, which keeps the door open for future HIP-aware >> apps to directly use the full IDs. > > But there are some cases where the larger ID (that doesn't fit in the > AID > seen by the ULPs) does not help. > > Example: busy server receives a context from a client with large ID = X > and AID=P1 | hash(X) > Server later receives a context from a client with large ID = Y > and AID=P1 | hash(Y) > and the hash values are identical. > > Even though the multihoming layer can disambiguate the two contexts, it > can not handle both at the same time because the ULP can not tell them > apart. > I think that Tom was considering the case were apps have been upgraded and they are HIP aware (using a new api), so they can actually deal with the full HIT or even directly with the HI, so they can benefit from enhanced security. Regards, marcelo > Thus when a packet would be passed down from the ULP, the multihoming > layer wouldn't know which of the two contexts to use for transmitting > the > packet. The number of contexts the server can handle before this > probability of > collisions is an issue is of course a function of the hash size. With > 64 bits > of hash handling 4 Billion contexts concurrently would imply about .5 > probability that two have the same hash, but the prefixes would most > likely be > different so that the AIDs would be different. > > Erik > From owner-multi6@ops.ietf.org Thu Jul 1 05: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 FAA07762 for ; Thu, 1 Jul 2004 05:23:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfxmc-0006BF-IE for multi6-data@psg.com; Thu, 01 Jul 2004 09:23:06 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfxmb-0006B0-5D for multi6@ops.ietf.org; Thu, 01 Jul 2004 09:23:05 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5694B2A201; Thu, 1 Jul 2004 11:23:04 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 40A822A200; Thu, 1 Jul 2004 11:23:04 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <65C9BDB7-CB40-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: 7bit Cc: Multi6 , Iljitsch van Beijnum From: marcelo bagnulo braun Subject: Re: identifiers and security Date: Thu, 1 Jul 2004 11:24:05 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 >> I think if the redirection problem by attackers that are on-path >> temporarily is limited to individual unprotected sessions, we are not >> materially worse off than today as the same attacker could break the >> sessions today also, and redirecting an unprotected session presumably >> isn't worse than breaking it as the contents aren't secret. > > I think there is a difference between > - someone breaking into to office looking at the pieces of paper on > my desk > - someone breaking into my office and installing a device which allows > them to look at all future pieces of paper I will place on my desk > > Thus there is a difference between looking at unprotected communication > while being on the path, and looking at unprotected communication > long after having left the path. > But this might be a case where we can make things be slightly worse > than > in today's Internet since this communication was unprotected in any > case. > I am not sure how slightly this is... suppose a host A with Locator LA A server B with locator LB and an attacker X with locator LX A usually connects to B to get some information, for instance the news. Now, X manages to be on the path between A and B for a while. Now, X starts a communication with A and pretends to be B, and X creates a state in A mapping the identifier of A with locator LX. Note that it can do that because the verification will be based on the RR and X will succeed because he is on the path. Then, X leaves the place and goes to somewhere more comfortable for him Now, in the future when A tries to reach B he will contacting X... forever ;-) I don't feel that this would be acceptable Regards, marcelo > Erik > > From owner-multi6@ops.ietf.org Thu Jul 1 05:41:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08871 for ; Thu, 1 Jul 2004 05:41:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfy3f-0007dK-Es for multi6-data@psg.com; Thu, 01 Jul 2004 09:40:43 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfy3e-0007d5-7E for multi6@ops.ietf.org; Thu, 01 Jul 2004 09:40:42 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id A40D248EB35; Thu, 1 Jul 2004 11:40:48 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 , Iljitsch van Beijnum From: Kurt Erik Lindqvist Subject: Re: Engaging apps folks Date: Thu, 1 Jul 2004 11:40:41 +0200 To: Erik Nordmark X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-06-29, at 14.08, Erik Nordmark wrote: > My experience, and I think Kurt said something similar, is that it > is hard to engage application folks without something concrete like > a proposal that they look at. This makes it tricky to get feedback > before > we have nailed down enough of the approach to be able write down how it > will affect applications, unless we do the work to present the apps > folks > with a menu having different choices. I think the other approach is for me and Brian (and perhaps David) to actually ask the Apps ADs for help. I think that we are fairly deep into the discussion on what properties what get's passed to the ULPs can have. In order to understand this better I think we need some input from Apps. But let's discuss this off-line and see what we can do. I have got some comments off-line from some apps people I know. I tried to convince them to join the mailinglist, but with not much success so far :-( - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQOPcHaarNKXTPFCVEQJngwCfckCd0m5ocNMUOLtbvIV6+uDJQP4AoNd+ /HsPp06Lq6Q/oFKJIRdzwoT4 =rpSo -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 1 05:46: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 FAA09283 for ; Thu, 1 Jul 2004 05:46:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfy8n-00086r-3T for multi6-data@psg.com; Thu, 01 Jul 2004 09:46:01 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfy8l-00086c-P2 for multi6@ops.ietf.org; Thu, 01 Jul 2004 09:46:00 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F06A62A1BC; Thu, 1 Jul 2004 11:45:58 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id B967B2A1B4; Thu, 1 Jul 2004 11:45:58 +0200 (CEST) In-Reply-To: <3D0D030A-CB34-11D8-A581-000A95928574@kurtis.pp.se> References: <3D0D030A-CB34-11D8-A581-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <990DE4D4-CB43-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Erik Nordmark , Multi6 , Iljitsch van Beijnum From: marcelo bagnulo braun Subject: how secure mh should be? Re: identifiers and security Date: Thu, 1 Jul 2004 11:46:59 +0200 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Kurtis, imho is important to reach a common criteria here. i think that the minimum goal should be that the resulting solution=20 should be as secure as current fixed, single homed IPv6 internet. As you say, i wouldn't mind if the result is a bit more secure, but i=20 wouldn't require it Regards, marcelo El 01/07/2004, a las 9:57, Kurt Erik Lindqvist escribi=F3: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > [Catching up a bit] > > On 2004-06-28, at 13.52, Erik Nordmark wrote: > >> >> Thus something which is quite insecure (weaker than NOID as above)=20 >> when >> IPsec isn't used, but when IPsec is used it is as strong as with = IPsec >> in >> today's Internet. >> Is anybody interested in exploring these ideas further? > > Personally I think that we at some point need to clarify the "do no > harm" view. I.e do we want to try and achieve something better than > today? Or is relying on the security extension headers of IPv6 give us > some slack? Or do we just agree that the world is ok today and trying > to do better is shooting for the stars? > > I personally wouldn't mind aiming for something a bit higher than=20 > today. > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQOPD0qarNKXTPFCVEQLbjACgpMCLlTWA5QTXLStMOEJKErl/Dx0An33D > oVSIXu9eHjQktzyFIVta6/uc > =3Dp8By > -----END PGP SIGNATURE----- > > From owner-multi6@ops.ietf.org Thu Jul 1 05:47: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 FAA09390 for ; Thu, 1 Jul 2004 05:47:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfyA2-0008Dt-3z for multi6-data@psg.com; Thu, 01 Jul 2004 09:47:18 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfyA1-0008Df-0l for multi6@ops.ietf.org; Thu, 01 Jul 2004 09:47:17 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 36EE42A1B4; Thu, 1 Jul 2004 11:47:16 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 202432A18F; Thu, 1 Jul 2004 11:47:16 +0200 (CEST) In-Reply-To: <5EABF672-CB35-11D8-A581-000A95928574@kurtis.pp.se> References: <5EABF672-CB35-11D8-A581-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List , Erik Nordmark From: marcelo bagnulo braun Subject: Re: about Wedgelayer 3.5 / Fat IP approaches Date: Thu, 1 Jul 2004 11:48:17 +0200 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 >> It is actually more constrained than that since other instances of >> the application might be running on non-multi6 aware hosts. >> So the conservative approach would be to always hand an IP >> address/locator >> to unmodified applications, that way the application can use it >> for callbacks and referrals without any constraints on which hosts the >> different instances of the app is running. > > For a transition scenario this will most likely more be the rule than > the exception. SIP comes to mind of an application where you would do > referrals and you can not trust that all "nodes" are of the same > "instance"/protocol version/awareness. > Does this implies that AID have to be routable IP addresses? regards, marcelo > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQOPFuKarNKXTPFCVEQKT0QCg/eOifwbywPqBgcwcl0Kw2A5QZj8AoJFh > Dk+jyIfwZcadamZqSRMvpF4S > =y2oT > -----END PGP SIGNATURE----- > From owner-multi6@ops.ietf.org Thu Jul 1 06:09: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 GAA10784 for ; Thu, 1 Jul 2004 06:09:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfyUA-000Alk-57 for multi6-data@psg.com; Thu, 01 Jul 2004 10:08:06 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfyU9-000AlV-8z for multi6@ops.ietf.org; Thu, 01 Jul 2004 10:08:05 +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 i61A7p0R025560; Thu, 1 Jul 2004 03:07:51 -0700 (PDT) Received: from localhost (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 i61A7j210593; Thu, 1 Jul 2004 12:07:45 +0200 (MEST) Date: Thu, 1 Jul 2004 02:26:33 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: about Wedgelayer 3.5 / Fat IP approaches To: Brian E Carpenter Cc: marcelo bagnulo braun , Jukka Ylitalo , Multi6 List , Erik Nordmark In-Reply-To: "Your message with ID" <40E2DC40.1050909@zurich.ibm.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.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 > I really don't want to start a discussion here about cryptographic > strength, but my objection to CGAs in the multi6 context is that they > include the /48 prefix in the hash, and that is variable in multi6, > which means that the host ID changes when you change prefix. I think > that's an unfortunate property because it eliminates some possible > tricks in the ID/locator split. Which reminds me about one part I overlooked in thinking about cb64 where the IID is different per prefix: if we do this it isn't any longer possible to have router rewrite the source locator, because a different prefix would imply that the suffix needs to be different. So we need to add that to the list of things to trade off. Erik From owner-multi6@ops.ietf.org Thu Jul 1 06:09: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 GAA10804 for ; Thu, 1 Jul 2004 06:09:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfyUG-000AmR-IJ for multi6-data@psg.com; Thu, 01 Jul 2004 10:08:12 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfyUF-000AmB-N3 for multi6@ops.ietf.org; Thu, 01 Jul 2004 10:08:11 +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 i61A800R025598; Thu, 1 Jul 2004 03:08:01 -0700 (PDT) Received: from localhost (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 i61A7t210606; Thu, 1 Jul 2004 12:07:56 +0200 (MEST) Date: Thu, 1 Jul 2004 02:37:06 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identity persistence and comparison issues To: Kurt Erik Lindqvist Cc: Erik Nordmark , Multi6 , Iljitsch van Beijnum In-Reply-To: "Your message with ID" <2ECA5E67-CB36-11D8-A581-000A95928574@kurtis.pp.se> 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.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 > Without having thought this through very much I have a few questions on > this, > > As you would need to keep state that would be very much like a cache. > Would you not open your self up for "cache-poisoning" very much like > todays DNS? In principle,yes. But the WIMP+AID idea wouldn't AFAIK have more of a problem in this space than NOID or cb64 type approaches. All can use the return routability implicit in establishing the state to place some trust (no worse than today's Internet) in the initial locators, and then verify additional locators before they are marked as "usable" in the cache. WIMP+AID should be able to take the same approach. Erik From owner-multi6@ops.ietf.org Thu Jul 1 06:23: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 GAA11787 for ; Thu, 1 Jul 2004 06:23:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfyis-000CEu-DY for multi6-data@psg.com; Thu, 01 Jul 2004 10:23:18 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfyir-000CEe-9d for multi6@ops.ietf.org; Thu, 01 Jul 2004 10:23:17 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i61AOd2r048912; Thu, 1 Jul 2004 12:24:40 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <990DE4D4-CB43-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <3D0D030A-CB34-11D8-A581-000A95928574@kurtis.pp.se> <990DE4D4-CB43-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: how secure mh should be? Re: identifiers and security Date: Thu, 1 Jul 2004 12:23:12 +0200 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 1-jul-04, at 11:46, marcelo bagnulo braun wrote: > imho is important to reach a common criteria here. Yes. But in order to do that, we need to analyze the situation so we can make a proper decision. > i think that the minimum goal should be that the resulting solution > should be as secure as current fixed, single homed IPv6 internet. > As you say, i wouldn't mind if the result is a bit more secure, but i > wouldn't require it I think the first statement doesn't really provide much guidance: whatever we do, multihoming makes things different, and whether that's worse or not isn't necessarily something we automatically agree on. That is, unless multihoming actually makes everything more secure. Now that can't be a bad thing, can it? Actually: yes. Too much security is harmful. In order to be secure, you must either implement additional mechanisms, which requires additional complexity, bandwidth and/or computation. In many cases that's just fine: if my email message becomes 7k rather than 4k and it takes 50 ms to decode it, who cares? But if I want to transmit a 8 Gbps stream from my radio astronomy observatory to a remote computing facilty, I don't have the luxury to do even an MD5 over that data. Insisting on security when the necessary mechanisms aren't available or can't be applied means making communication impossible. (BTW, that's one of my issues with Secure BGP / secure origin BGP: if you require everything to be signed there WILL be times when "good" communications will be impossible because of certificate problems. And it's not like there are never problems with certificates...) Remember, most traffic flowing over the internet is completely unprotected and people don't seem to be bothered by that too much. Going back to Erik's analogy of someone looking through the window into your office. I think we can agree that giving such a person the opportunity to install a device that allows her to keep observing what happens long after she's left is unacceptable. On the other hand, the owner of the office does have papers out that are visible through the window, so they are taking a risk and it's not our place to take exception to that. What I've been saying for a while now is that redirecting individual unprotected sessions isn't really worse than what an attacker can do today. In our analogy: today someone can look through the window and read (for instance) the pages of a book that is open in our proverbial office. Redirecting individual sessions would be comparable to someone being able to read the entire book rather than only the pages that are visible at that moment. Now it's possible to argue that this is worse, but my position is that if the book was confidential, it shouldn't have been open in front of the window so people could read a couple of pages in the first place. So there are three possible cases: 1. The book is confidential and the user wants to keep it that way = IPsec/TLS. Our MH mechanisms should protect these against redirection. 2. The book is confidential but the user has it open in view of the window anyway = no IPsec/TLS and wireless. It doesn't make sense to consider this situation as there is leakage of confidential information regardless, the only question is whether it's going to be a bit more. 3. The contents of the book aren't confidential = redirecting isn't worse than breaking (if they can steal your book, why bother making sure they can't read it if they can pick it up at the bookstore anyway?). From owner-multi6@ops.ietf.org Thu Jul 1 06:24: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 GAA11831 for ; Thu, 1 Jul 2004 06:24:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfyja-000CKD-R3 for multi6-data@psg.com; Thu, 01 Jul 2004 10:24:02 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfyjZ-000CJt-Rb for multi6@ops.ietf.org; Thu, 01 Jul 2004 10:24:02 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id F23B22A22B for ; Thu, 1 Jul 2004 12:24:00 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id DD3B42A216 for ; Thu, 1 Jul 2004 12:24:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Multi6 List From: marcelo bagnulo braun Subject: Advantages and disadvantages of using CB64 type of identifiers Date: Thu, 1 Jul 2004 12:25:01 +0200 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Erik wrote: > So we need to add that to the list of things to trade off. i have tried to compile the advantages and disadvantages of cb64 type of ids Advantages and disadvantages of using CB64 type of identifiers Advantages: - The AID is a routable address, so apps can handle them without modification - referrals and call backs - long lived sessions can recover when the state is lost in the multi6 layer - It is possible to use the reverse DNS to discover alternative locators - they are crypto in nature, so "strong" authentication is achieved Disadvantages - fixed 64 bit iid/prefix boundary - in particular the lower 64 bits cannot be used for subneting - are 64 bits long enough defense against future hash collision attacks? - an attacker creates a public key with the same hash of the iid of the target - source locator rewriting by edge routers is precluded - changes in the prefix implies changes in the identifiers - so when the mh site changes isps it will need to renumber both its locators and its identifiers - in order to be able to use the reverse dns to discover the full set of locators, the reverse dns tree has to be fully populated, which may be challenging in as hoc environments. any others? regards, marcelo From owner-multi6@ops.ietf.org Thu Jul 1 06:42: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 GAA13260 for ; Thu, 1 Jul 2004 06:42:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bfz0x-000Dwm-IX for multi6-data@psg.com; Thu, 01 Jul 2004 10:41:59 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bfz0w-000DwW-3L for multi6@ops.ietf.org; Thu, 01 Jul 2004 10:41:58 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 425B42A24F; Thu, 1 Jul 2004 12:41:57 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 2B6952A25A; Thu, 1 Jul 2004 12:41:57 +0200 (CEST) In-Reply-To: References: <3D0D030A-CB34-11D8-A581-000A95928574@kurtis.pp.se> <990DE4D4-CB43-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6A90FD30-CB4B-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 From: marcelo bagnulo braun Subject: Re: how secure mh should be? Re: identifiers and security Date: Thu, 1 Jul 2004 12:42:57 +0200 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Iljitsch, i think we agree more than i thought :-) El 01/07/2004, a las 12:23, Iljitsch van Beijnum escribi=F3: > On 1-jul-04, at 11:46, marcelo bagnulo braun wrote: > >> imho is important to reach a common criteria here. > > Yes. But in order to do that, we need to analyze the situation so we=20= > can make a proper decision. > >> i think that the minimum goal should be that the resulting solution=20= >> should be as secure as current fixed, single homed IPv6 internet. > >> As you say, i wouldn't mind if the result is a bit more secure, but i=20= >> wouldn't require it > > I think the first statement doesn't really provide much guidance: Well, i think it in the following way. In the new environment, where multihomed sites implement the proposed=20 solution, is it possible to launch new attacks that were not possible=20= in the previous Internet (i.e. the internet without the multi6=20 solution)? If the answer is yes, then we have to carefully understand the scope of=20= these attacks and see if this is acceptable > whatever we do, multihoming makes things different, and whether=20 > that's worse or not isn't necessarily something we automatically agree=20= > on. agree that there is no automatic agreeing when evaluating the new=20 possible attacks > That is, unless multihoming actually makes everything more secure.=20 > Now that can't be a bad thing, can it? Actually: yes. Too much=20 > security is harmful. In order to be secure, you must either implement=20= > additional mechanisms, which requires additional complexity, bandwidth=20= > and/or computation. In many cases that's just fine: if my email=20 > message becomes 7k rather than 4k and it takes 50 ms to decode it, who=20= > cares? But if I want to transmit a 8 Gbps stream from my radio=20 > astronomy observatory to a remote computing facilty, I don't have the=20= > luxury to do even an MD5 over that data. Insisting on security when=20 > the necessary mechanisms aren't available or can't be applied means=20 > making communication impossible. agree with this point. again, the cost of the enhanced security has to be evaluated in each=20 case > > (BTW, that's one of my issues with Secure BGP / secure origin BGP: if=20= > you require everything to be signed there WILL be times when "good"=20 > communications will be impossible because of certificate problems. And=20= > it's not like there are never problems with certificates...) > > Remember, most traffic flowing over the internet is completely=20 > unprotected and people don't seem to be bothered by that too much. > > Going back to Erik's analogy of someone looking through the window=20 > into your office. I think we can agree that giving such a person the=20= > opportunity to install a device that allows her to keep observing what=20= > happens long after she's left is unacceptable. On the other hand, the=20= > owner of the office does have papers out that are visible through the=20= > window, so they are taking a risk and it's not our place to take=20 > exception to that. What I've been saying for a while now is that=20 > redirecting individual unprotected sessions isn't really worse than=20 > what an attacker can do today. agree redirection of a single connection by an on path attacker may be=20 acceptable, but redirecting all future connection is not acceptable Bottom line: the goal is to preserve actual security: anything more or=20= less secure has to be evaluated in particular, agree? Regards, marcelo > In our analogy: today someone can look through the window and read=20 > (for instance) the pages of a book that is open in our proverbial=20 > office. Redirecting individual sessions would be comparable to someone=20= > being able to read the entire book rather than only the pages that are=20= > visible at that moment. Now it's possible to argue that this is worse,=20= > but my position is that if the book was confidential, it shouldn't=20 > have been open in front of the window so people could read a couple of=20= > pages in the first place. So there are three possible cases: > > 1. The book is confidential and the user wants to keep it that way =3D=20= > IPsec/TLS. Our MH mechanisms should protect these against redirection. > 2. The book is confidential but the user has it open in view of the=20 > window anyway =3D no IPsec/TLS and wireless. It doesn't make sense to=20= > consider this situation as there is leakage of confidential=20 > information regardless, the only question is whether it's going to be=20= > a bit more. > 3. The contents of the book aren't confidential =3D redirecting isn't=20= > worse than breaking (if they can steal your book, why bother making=20 > sure they can't read it if they can pick it up at the bookstore=20 > anyway?). > From owner-multi6@ops.ietf.org Thu Jul 1 06: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 GAA14163 for ; Thu, 1 Jul 2004 06:56:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BfzEl-000FPg-K7 for multi6-data@psg.com; Thu, 01 Jul 2004 10:56:15 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BfzEk-000FPD-La for multi6@ops.ietf.org; Thu, 01 Jul 2004 10:56:14 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 1570F48F4A4; Thu, 1 Jul 2004 12:56:21 +0200 (CEST) In-Reply-To: <40E2B13C.1090002@zurich.ibm.com> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <40E2B13C.1090002@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <46F9F97B-CB4D-11D8-A205-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: multi6@ops.ietf.org, Geoff Huston From: Kurt Erik Lindqvist Subject: Re: Q1 Re: revision of architecture draft is now published Date: Thu, 1 Jul 2004 12:56:17 +0200 To: Brian E Carpenter X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For the records I am for adopting this. - - kurtis - On 2004-06-30, at 14.25, Brian E Carpenter wrote: > Geoff, thanks. > > Because of the way our charter is currently written, we have two > separate > questions to the WG. Here is the first one: > > Do people agree to adopt this draft as a WG draft (which means > that the next update will be draft-ietf-multi6-architectures-00.txt)? > > That doesn't mean you have to agree that it's perfect, just that it > is a good basis for a WG deliverable. > > Please answer this question without worrying whether the Appendix > is split off, and please respond by July 9th. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > > > > Geoff Huston wrote: >> draft-huston-multi6-architectures-01.txt has been published by the >> drafts editor. This version integrates comments made by working group >> members on the -00 version and also includes material proposed in the >> interim multi6 working group meeting earlier this month. >> I would like to propose to the chairs that the working group consider: >> - that this document be adopted as a working group document, and >> - that the appendix of this document be split off from the main text >> of the document and separately developed as a working group document. >> thanks. > -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQOPt1KarNKXTPFCVEQJkqACg1xQ14J0uae5XSkH4kX54tc5UNUQAoImK vVhTnBHu8e3n10evHg9F/v8y =wO+d -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 1 16:42: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 QAA00864 for ; Thu, 1 Jul 2004 16:42:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bg8Mt-000OZA-1Z for multi6-data@psg.com; Thu, 01 Jul 2004 20:41:15 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bg8Ms-000OYq-4d for multi6@ops.ietf.org; Thu, 01 Jul 2004 20:41:14 +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 i61Kex0R023275; Thu, 1 Jul 2004 13:40:59 -0700 (PDT) Received: from localhost (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 i61Ker207536; Thu, 1 Jul 2004 22:40:54 +0200 (MEST) Date: Thu, 1 Jul 2004 11:46:55 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: about Wedgelayer 3.5 / Fat IP approaches To: marcelo bagnulo braun Cc: Erik Nordmark , "Henderson, Thomas R" , Jukka Ylitalo , Multi6 List In-Reply-To: "Your message with ID" <13910A32-CB3E-11D8-A131-000D93ACD0FE@it.uc3m.es> 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.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 > > Example: busy server receives a context from a client with large ID = X > > and AID=P1 | hash(X) > > Server later receives a context from a client with large ID = Y > > and AID=P1 | hash(Y) > > and the hash values are identical. > > > > Even though the multihoming layer can disambiguate the two contexts, it > > can not handle both at the same time because the ULP can not tell them > > apart. > > > > I think that Tom was considering the case were apps have been upgraded > and they are HIP aware (using a new api), so they can actually deal > with the full HIT or even directly with the HI, so they can benefit > from enhanced security. But even if the application can do that it doesn't help the TCP from telling the two peers with the same AID apart. Erik From owner-multi6@ops.ietf.org Thu Jul 1 16:42: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 QAA00882 for ; Thu, 1 Jul 2004 16:42:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bg8N6-000Ob3-Si for multi6-data@psg.com; Thu, 01 Jul 2004 20:41:28 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bg8N6-000Oan-0w for multi6@ops.ietf.org; Thu, 01 Jul 2004 20:41:28 +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 i61KfGJ6020688; Thu, 1 Jul 2004 13:41:17 -0700 (PDT) Received: from localhost (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 i61KfB207544; Thu, 1 Jul 2004 22:41:11 +0200 (MEST) Date: Thu, 1 Jul 2004 12:15:40 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: identifiers and security To: marcelo bagnulo braun Cc: Erik Nordmark , Multi6 , Iljitsch van Beijnum In-Reply-To: "Your message with ID" <65C9BDB7-CB40-11D8-A131-000D93ACD0FE@it.uc3m.es> 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.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 > I am not sure how slightly this is... > > suppose a host A with Locator LA > A server B with locator LB > and an attacker X with locator LX > > A usually connects to B to get some information, for instance the news. > > Now, X manages to be on the path between A and B for a while. > Now, X starts a communication with A and pretends to be B, and X > creates a state in A mapping the identifier of A with locator LX. > Note that it can do that because the verification will be based on the > RR and X will succeed because he is on the path. > Then, X leaves the place and goes to somewhere more comfortable for him > > Now, in the future when A tries to reach B he will contacting X... > forever ;-) > > I don't feel that this would be acceptable I agree at some level, because this was the conservative approach that was taken in the MIPv6 security design. But one can argue against that by: - if the attacker was on the path, why couldn't the attacker leave a small device (running on a battery for a month for instance) attached? Erik From owner-multi6@ops.ietf.org Thu Jul 1 18:54:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07069 for ; Thu, 1 Jul 2004 18:54:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgAQU-000ENP-26 for multi6-data@psg.com; Thu, 01 Jul 2004 22:53:06 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgAQT-000EMq-1x for multi6@ops.ietf.org; Thu, 01 Jul 2004 22:53:05 +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 i61Mr1J6013102; Thu, 1 Jul 2004 15:53:01 -0700 (PDT) Received: from localhost (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 i61Mqu218374; Fri, 2 Jul 2004 00:52:57 +0200 (MEST) Date: Thu, 1 Jul 2004 15:08:14 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Advantages and disadvantages of using CB64 type of identifiers To: marcelo bagnulo braun Cc: 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.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 > - source locator rewriting by edge routers is precluded > - changes in the prefix implies changes in the identifiers > - so when the mh site changes isps it will need > to renumber both its locators and its identifiers Hmm - this assumes that the IID is different for each prefix. My understanding is that SeND chose different IIDs for different prefixes but that might be overkill. If the IID is not a function of the prefix it would enable redirection by a resourceful attacker by precomputing 2^64 public/private keys that hash to all 2^64 IIDs. If the content of the packets are encrypted the redirection would not provide access to the content; it could only be used for DoS or for gathering the content for cryptoanalysis. A while back Jari Arkko computed the amount of space needed to store 2^64 precomputed keys, and the storage space was a few buildings the size of the former world trade center buildings I think. An organization which is willing to spend that much resources today on redirecting packets can probably do it more efficiently by gaining access to links within or between large ISPs. So the question is whether we believe that the cost of the precomputation and storage would drop so much over 20 years that this would become one of the more attractive ways to DoS or gather data for cryptoanalysis. Erik From owner-multi6@ops.ietf.org Thu Jul 1 19:13: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 TAA07800 for ; Thu, 1 Jul 2004 19:13:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgAji-000HTl-1i for multi6-data@psg.com; Thu, 01 Jul 2004 23:12:58 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgAjg-000HTD-SE for multi6@ops.ietf.org; Thu, 01 Jul 2004 23:12:56 +0000 Received: from slb-av-01.boeing.com ([129.172.13.4]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA21930; Thu, 1 Jul 2004 18:12:43 -0500 (CDT) Received: from xch-nw-23p.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i61NCgb15922; Thu, 1 Jul 2004 16:12:42 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nw-23p.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 1 Jul 2004 16:12:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.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 Wedgelayer 3.5 / Fat IP approaches Date: Thu, 1 Jul 2004 16:12:40 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060729@xch-nw-27.nw.nos.boeing.com> Thread-Topic: about Wedgelayer 3.5 / Fat IP approaches Thread-Index: AcRfSFyX2Hjq0gBOS0Sk1meW1RiwTwAZ1SdQ From: "Henderson, Thomas R" To: "Erik Nordmark" Cc: "marcelo bagnulo braun" , "Jukka Ylitalo" , "Multi6 List" X-OriginalArrivalTime: 01 Jul 2004 23:12:41.0304 (UTC) FILETIME=[E88B9D80:01C45FC0] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]=20 > Sent: Thursday, July 01, 2004 1:50 AM > To: Henderson, Thomas R > Cc: marcelo bagnulo braun; Jukka Ylitalo; Multi6 List; Erik Nordmark > Subject: RE: about Wedgelayer 3.5 / Fat IP approaches >=20 >=20 >=20 > > So, assuming that HIP hosts started to use low order bits of the > > HIT in their locators, and then used such a locator as an AID, > > the main differences I see are in the use of/reliance on PK crypto > > in the context establishment handshakes, as well as IPsec reliance=20 > > (HIP relies on PK signings for handshakes, and relies on IPsec,=20 > > while CB64 relies on neither), and some of the basic protocol=20 > > mechanisms of the two proposals (which one might argue are just > > details): > > - CB64 handshake occurs in parallel with start of data transfer > > (actually, after first data packet has been sent), while HIP holds > > the first packet waiting for HIP handshake to complete (or > > possibly piggybacks it on the HIP exchange).=20 >=20 > I think this is the only issue which is tied to the type of ID that > is used. In HIP as defined, since the ID used by the=20 > transport is not a > locator, the handshake must occur before ULP packets can be exchange. > But with a CB64 AID that is also a locator one has the option > to do them concurrently or even defer the handshake. I agree with you that this is the main issue tied to the ID, but the CB64 approach might be usable by HIP if HIP were to define a non-IPsec mode of operation. Presently, the transport ID used by HIP is the HIT, but I think that it could perhaps be the AID instead, allowing a more CB64 operation. The price to pay for deferred or concurrent handshakes is perhaps weaker authentication. >=20 > > - CB64 uses flow IDs and locators as keys to find context state > > for the session, while HIP uses IPsec SPIs >=20 > And Pekka Nikander has told me that it wouldn't be hard to have HIP > optionally use the same scheme if HIP wanted to support the case when > the payload is not encrypted. This seems feasible to me. >=20 > > - CB64 adds new locator for peer upon discovering it as a source > > address in a packet (and issuing PK-signed challenge/response),=20 > > while HIP explicitly signals the new locator in a signed HIP=20 > > exchange. >=20 > For CB64 this derives from allowing router rewriting of the locators > as a way to signal changes in the working/desired path. > I don't think this is tied to the format of the ID so HIP and CB64 > could be made to behave whichever way we desire here. >=20 Agreed. > > Another difference is length of the hash of the key, which may I'll respond to rest of this in the next post. Tom From owner-multi6@ops.ietf.org Thu Jul 1 19:38: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 TAA08876 for ; Thu, 1 Jul 2004 19:38:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgB86-000KID-O2 for multi6-data@psg.com; Thu, 01 Jul 2004 23:38:10 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgB85-000KHw-KK for multi6@ops.ietf.org; Thu, 01 Jul 2004 23:38:09 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA21282; Thu, 1 Jul 2004 16:38:02 -0700 (PDT) Received: from XCH-NWBH-01.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i61Nc1P28889; Thu, 1 Jul 2004 18:38:01 -0500 (CDT) 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); Thu, 1 Jul 2004 16:37:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.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 Wedgelayer 3.5 / Fat IP approaches Date: Thu, 1 Jul 2004 16:37:58 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> Thread-Topic: about Wedgelayer 3.5 / Fat IP approaches Thread-Index: AcRfq8fkeR3twhmdTI6K5V4nXt+ULQACiIqg From: "Henderson, Thomas R" To: "Erik Nordmark" , "marcelo bagnulo braun" Cc: "Jukka Ylitalo" , "Multi6 List" X-OriginalArrivalTime: 01 Jul 2004 23:37:58.0971 (UTC) FILETIME=[712538B0:01C45FC4] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]=20 > Sent: Thursday, July 01, 2004 11:47 AM > To: marcelo bagnulo braun > Cc: Erik Nordmark; Henderson, Thomas R; Jukka Ylitalo; Multi6 List > Subject: Re: about Wedgelayer 3.5 / Fat IP approaches >=20 >=20 > > > Example: busy server receives a context from a client=20 > with large ID =3D X > > > and AID=3DP1 | hash(X) > > > Server later receives a context from a client with large ID =3D Y > > > and AID=3DP1 | hash(Y) > > > and the hash values are identical. > > > > > > Even though the multihoming layer can disambiguate the=20 > two contexts, it > > > can not handle both at the same time because the ULP can=20 > not tell them=20 > > > apart. > > > > >=20 > > I think that Tom was considering the case were apps have=20 > been upgraded=20 > > and they are HIP aware (using a new api), so they can actually deal=20 > > with the full HIT or even directly with the HI, so they can benefit=20 > > from enhanced security. >=20 > But even if the application can do that it doesn't help the=20 > TCP from telling > the two peers with the same AID apart. >=20 If the locators are the AIDs, then there is indeed a problem because two hosts have the same locator. Administratively, this might be=20 preventable in most cases by forcing a host to pick a new key if=20 truncate(hash(key)) matches with another host within that prefix. However, not in the mobility case, where a host might roam into a prefix where there is an AID collision. Anyway, if my m6 layer can differentiate between the two hosts, and my applications have provided me with more than the AIDs, I don't see why my transport couldn't work also (perhaps not by the AIDs=20 alone, but by some context information passed in the implementation). = If there is no exchange of larger IDs prior to conversation, then yes, I agree that one can construct ambiguity scenarios where an application intends to talk to one host but instead talks to=20 another. The CB64 draft seems to argue that applications can provide the additional verification if desired (Sec. 4.1 point 7). So in summary, if the (larger) IDs collide, there is potential for=20 ambiguity. If the IDs do not collide, there is still potential for=20 ambiguity if AIDs collide and: i) applications use AIDs only ii) applications use larger IDs, but the handshake is delayed or concurrent, causing the hosts to not be differentiated at the m6 layer by their IDs Tom From owner-multi6@ops.ietf.org Fri Jul 2 02:46: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 CAA10517 for ; Fri, 2 Jul 2004 02:46:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgHmx-000Etx-RR for multi6-data@psg.com; Fri, 02 Jul 2004 06:44:47 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgHmw-000EtX-RS for multi6@ops.ietf.org; Fri, 02 Jul 2004 06:44:47 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 4BF4C490777; Fri, 2 Jul 2004 08:44:44 +0200 (CEST) In-Reply-To: <990DE4D4-CB43-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <3D0D030A-CB34-11D8-A581-000A95928574@kurtis.pp.se> <990DE4D4-CB43-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <0AF7811D-CBF0-11D8-A205-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Erik Nordmark , Multi6 , Iljitsch van Beijnum From: Kurt Erik Lindqvist Subject: Re: how secure mh should be? Re: identifiers and security Date: Fri, 2 Jul 2004 08:21:24 +0200 To: marcelo bagnulo braun X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-07-01, at 11.46, marcelo bagnulo braun wrote: > imho is important to reach a common criteria here. > > i think that the minimum goal should be that the resulting solution > should be as secure as current fixed, single homed IPv6 internet. > > As you say, i wouldn't mind if the result is a bit more secure, but i > wouldn't require it I've been struggling not to say that maybe we should. But that is more of a layer9/mgmt issue as we then would require to define "how much" better. But I think that every improvement is a big advantage. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQOT+6KarNKXTPFCVEQJN8gCgtB1f0kqtxJy6lDYH/VZFKQV59HAAnRrA 5ConZSi9xDB6WiEAsUu1/A+Z =6HL3 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Fri Jul 2 04:23: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 EAA14440 for ; Fri, 2 Jul 2004 04:23:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgJJJ-000OeJ-FE for multi6-data@psg.com; Fri, 02 Jul 2004 08:22:17 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgJJ8-000Oc9-VB for multi6@ops.ietf.org; Fri, 02 Jul 2004 08:22:08 +0000 Received: from gihz1.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i628KPrE009701; Fri, 2 Jul 2004 18:20:30 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040702152130.01d6f8c0@kahuna.telstra.net> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Fri, 02 Jul 2004 15:26:52 +1000 To: marcelo bagnulo braun From: Geoff Huston Subject: Re: revision of architecture draft is now published Cc: kurtis@kurtis.pp.se, multi6@ops.ietf.org, brc@zurich.ibm.com In-Reply-To: <8D58C314-CAA3-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <8D58C314-CAA3-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Marcelo, thanks for your careful review of this draft - its appreciated of course. I have no issues with any of these suggestions and will integrate them into the next version of the draft if there are no objections from the working group, although my concerns about traffic engineering remain. I recognise that its in the RFC3582 goal set, but I still have the concern that "The consideration here appears to be that hosts need much more information at hand if they are to make locator address selection decisions based on some form of metric of relative load currently being imposed on select components of a number of end-to end network paths, and it raises the entire issue of Traffic Engineering being a network function independent of host function or an outcome of host interaction with the network, and if the host is to interact with the network how is this interaction to be signalled?" regards, Geoff From owner-multi6@ops.ietf.org Fri Jul 2 06:06: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 GAA24907 for ; Fri, 2 Jul 2004 06:06:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgKux-000BQQ-QI for multi6-data@psg.com; Fri, 02 Jul 2004 10:05:15 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgKuw-000BQ2-8N for multi6@ops.ietf.org; Fri, 02 Jul 2004 10:05:14 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i62A5DGP117846 for ; Fri, 2 Jul 2004 10:05:13 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i62A5CCD277594 for ; Fri, 2 Jul 2004 12:05:12 +0200 Received: from zurich.ibm.com (sig-9-145-139-12.de.ibm.com [9.145.139.12]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA44292 for ; Fri, 2 Jul 2004 12:05:11 +0200 Message-ID: <40E517AB.8080803@zurich.ibm.com> Date: Fri, 02 Jul 2004 10:07:07 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: [Fwd: I-D ACTION:draft-ietf-dna-goals-00.txt] 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.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 Multi6 people might like to look at this and consider whether a successful DNA solution might form part of the multihoming toolkit. The model would be that a signal from DNA that the network attachment had changed would be a strong hint that a multihoming event is about to occur. If you think any of the goals listed in the draft need to be modified to assist multihoming, please have that discussion on the dna mailing list, not here. Brian -------- Original Message -------- Subject: I-D ACTION:draft-ietf-dna-goals-00.txt Date: Fri, 11 Jun 2004 15:41:44 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: dna@eng.monash.edu.au A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detecting Network Attachment Working Group of the IETF. Title : Detecting Network Attachment in IPv6 Goals Author(s) : J. Choi, G. Daley Filename : draft-ietf-dna-goals-00.txt Pages : 17 Date : 2004-6-11 At the time a host establishes a new link-layer connection, it may or may not have a valid IP configuration for Internet connectivity. The host may check for link change, i.e. determine whether a link change has occurred, and then, based on the result, it can automatically decide whether its IP configuration is still valid or not. While checking for link change, the host may also collect necessary information to initiate a new IP configuration for the case that the IP subnet has changed. In this memo, this procedure is called Rapid attachment detection is required when a host has on-going data traffic. Current DNA schemes are inadequate to support real-time applications. The existing procedures for advertising network information incur reception delays and do not provide enough information to properly determine the identity of links. For to-be-defined, efficient DNA schemes, a way to correctly represent a link change, a complete and consistent procedure for network information advertisement and a rapid delivery of the advertisements will be necessary. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dna-goals-00.txt From owner-multi6@ops.ietf.org Fri Jul 2 06:57: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 GAA27663 for ; Fri, 2 Jul 2004 06:57:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgLih-000HYJ-Ks for multi6-data@psg.com; Fri, 02 Jul 2004 10:56:39 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgLig-000HXt-6o for multi6@ops.ietf.org; Fri, 02 Jul 2004 10:56:38 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 119E139DFE; Fri, 2 Jul 2004 12:56:35 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id EE80639DF9; Fri, 2 Jul 2004 12:56:34 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Multi6 , Iljitsch van Beijnum From: marcelo bagnulo braun Subject: Re: identifiers and security Date: Fri, 2 Jul 2004 12:57:37 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 El 01/07/2004, a las 21:15, Erik Nordmark escribi=F3: >> I am not sure how slightly this is... >> >> suppose a host A with Locator LA >> A server B with locator LB >> and an attacker X with locator LX >> >> A usually connects to B to get some information, for instance the=20 >> news. >> >> Now, X manages to be on the path between A and B for a while. >> Now, X starts a communication with A and pretends to be B, and X >> creates a state in A mapping the identifier of A with locator LX. >> Note that it can do that because the verification will be based on = the >> RR and X will succeed because he is on the path. >> Then, X leaves the place and goes to somewhere more comfortable for=20= >> him >> >> Now, in the future when A tries to reach B he will contacting X... >> forever ;-) >> >> I don't feel that this would be acceptable > > I agree at some level, because this was the conservative approach that > was taken in the MIPv6 security design. > > But one can argue against that by: > - if the attacker was on the path, why couldn't the attacker leave a=20= > small > device (running on a battery for a month for instance) attached? > :-) i would argue that the attacker is still on the path (so you can do=20 this in single homed internet), and this is not a time shifted attack,=20= but i see your point. regards, marcelo > Erik > From owner-multi6@ops.ietf.org Fri Jul 2 07:03:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27983 for ; Fri, 2 Jul 2004 07:03:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgLpX-000IMQ-Oq for multi6-data@psg.com; Fri, 02 Jul 2004 11:03:43 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgLpW-000IM7-GX for multi6@ops.ietf.org; Fri, 02 Jul 2004 11:03:42 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AB71339E35; Fri, 2 Jul 2004 13:03:41 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 951C739E31; Fri, 2 Jul 2004 13:03:41 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <9FBC54E7-CC17-11D8-A131-000D93ACD0FE@ing.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: Advantages and disadvantages of using CB64 type of identifiers Date: Fri, 2 Jul 2004 13:04:44 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: quoted-printable El 02/07/2004, a las 0:08, Erik Nordmark escribi=F3: >> - source locator rewriting by edge routers is precluded >> - changes in the prefix implies changes in the identifiers >> - so when the mh site changes isps it will need >> to renumber both its locators and its identifiers > > Hmm - this assumes that the IID is different for each prefix. > or for the set of prefixes that are configured in the mh site. But=20 bottom line is that when a prefix is added or removed, iids have to=20 change. > My understanding is that SeND chose different IIDs for different=20 > prefixes > but that might be overkill. that would be great news > If the IID is not a function of the prefix > it would enable redirection by a resourceful attacker > by precomputing 2^64 public/private keys that hash to all 2^64 IIDs. > If the content of the packets are encrypted the redirection would not > provide access to the content; it could only be used for DoS or for > gathering the content for cryptoanalysis. > i don't quite follow this... i mean, if the iid is used by apps to provide some form of=20 authentication/authorization, having a public key that matches with the=20= iid may enable to impersonate the real owner of the iid, right? and since the iids are crypto, one may assume that apps may want to use=20= to authentication, i guess. But this may depend on the details, i guess. regards, marcelo > A while back Jari Arkko computed the amount of space needed to store > 2^64 precomputed keys, and the storage space was a few buildings the=20= > size > of the former world trade center buildings I think. > > An organization which is willing to spend that much resources today on > redirecting packets can probably do it more efficiently by gaining=20 > access > to links within or between large ISPs. > > So the question is whether we believe that the cost of the=20 > precomputation > and storage would drop so much over 20 years that this would become = one > of the more attractive ways to DoS or gather data for cryptoanalysis. > > Erik > From owner-multi6@ops.ietf.org Fri Jul 2 07:19: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 HAA28655 for ; Fri, 2 Jul 2004 07:19:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgM3m-000K3Z-9Z for multi6-data@psg.com; Fri, 02 Jul 2004 11:18:26 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgM3k-000K3G-L1 for multi6@ops.ietf.org; Fri, 02 Jul 2004 11:18:25 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id D000639E54; Fri, 2 Jul 2004 13:18:23 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id B98E639E0E; Fri, 2 Jul 2004 13:18:23 +0200 (CEST) In-Reply-To: <6.0.1.1.2.20040702152130.01d6f8c0@kahuna.telstra.net> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <8D58C314-CAA3-11D8-A131-000D93ACD0FE@it.uc3m.es> <6.0.1.1.2.20040702152130.01d6f8c0@kahuna.telstra.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: kurtis@kurtis.pp.se, multi6@ops.ietf.org, brc@zurich.ibm.com From: marcelo bagnulo braun Subject: Re: revision of architecture draft is now published Date: Fri, 2 Jul 2004 13:19:26 +0200 To: Geoff Huston X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Geoff, El 02/07/2004, a las 7:26, Geoff Huston escribi=F3: > [...] > although my concerns about traffic engineering remain. > > I recognise that its in the RFC3582 goal set, but I still have the=20 > concern that "The consideration here appears to be that hosts need=20 > much more information at hand if they are to make locator address=20 > selection decisions based on some form of metric of relative load=20 > currently being imposed on select components of a number of end-to end=20= > network paths, and it raises the entire issue of Traffic Engineering=20= > being a network function independent of host function or an outcome of=20= > host interaction with the network, and if the host is to interact with=20= > the network how is this interaction to be signalled?" Ok, i agree with your point here. perhaps we have a terminology problem here.... My intention about the TE capabilities of a mh are much more modest=20 than selecting paths according to the current load. I think that a=20 multihoming solution should allow the site to express some sort of=20 preferences about which path to use, both for incoming and outgoing=20 traffic . I think that this capability is present in current IPv4=20 multihoming solution, and similar capabilities should be provided by=20 the IPv6 multihomig solution. I think that this is a reasonable goal, and that we should analyze=20 different alternatives (if any) to provide it. Perhaps we end up=20 concluding that the TE capabilities of the IPv6 multihoming solution=20 are very limited (and that they will not match current IPv4 multihoming=20= TE capabilities), but i think that this should be conclusion after=20 analysing the possibilities and the tradeoffs, hence my opinion that=20 this should be part of the analysis. Regards, marcelo > > regards, > > Geoff > > From owner-multi6@ops.ietf.org Fri Jul 2 07:38: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 HAA29292 for ; Fri, 2 Jul 2004 07:38:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgMN5-000MuD-Hp for multi6-data@psg.com; Fri, 02 Jul 2004 11:38:23 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgMN3-000Mtf-VY for multi6@ops.ietf.org; Fri, 02 Jul 2004 11:38:22 +0000 Received: from [IPv6:::1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i62Bdc2r075038; Fri, 2 Jul 2004 13:39:41 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <3725F22A-CA74-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <3725F22A-CA74-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4AD71113-CC1C-11D8-B883-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: cb64 Date: Fri, 2 Jul 2004 13:38:09 +0200 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 30-jun-04, at 11:02, marcelo bagnulo braun wrote: >> But then this locator change wouldn't be protected by the key, so >> what's the point of having it? > We are considering cb64, Just goes to show you (well, me) that looking at the subject once in a while isn't a bad idea... Sorry guys. From owner-multi6@ops.ietf.org Fri Jul 2 09:52: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 JAA06116 for ; Fri, 2 Jul 2004 09:52:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgOR3-000Dvr-78 for multi6-data@psg.com; Fri, 02 Jul 2004 13:50:37 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgOR1-000DvS-Vx for multi6@ops.ietf.org; Fri, 02 Jul 2004 13:50:36 +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 i62DoJil008020; Fri, 2 Jul 2004 07:50:20 -0600 (MDT) Received: from localhost (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 i62DoB223832; Fri, 2 Jul 2004 15:50:12 +0200 (MEST) Date: Fri, 2 Jul 2004 06:50:09 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: about Wedgelayer 3.5 / Fat IP approaches To: "Henderson, Thomas R" Cc: Erik Nordmark , marcelo bagnulo braun , Jukka Ylitalo , Multi6 List In-Reply-To: "Your message with ID" <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.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.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 > If the locators are the AIDs, then there is indeed a problem because > two hosts have the same locator. Administratively, this might be > preventable in most cases by forcing a host to pick a new key if > truncate(hash(key)) matches with another host within that prefix. > However, not in the mobility case, where a host might roam into > a prefix where there is an AID collision. > > Anyway, if my m6 layer can differentiate between the two hosts, and > my applications have provided me with more than the AIDs, I don't > see why my transport couldn't work also (perhaps not by the AIDs > alone, but by some context information passed in the implementation). Yes, with enough thrust pigs can fly :-) It might not be a good idea to assume that all transports and all middleware layers of software will be modified to carry some additional context where they today only carry a FQDN or an IP address. But since such collisions are supposed to be infrequent, it might actually make a lot more sense to guard against them. What harm would be caused in the context of a CGA-like scheme if a host couldn't at the same time communicate with two (or more) hosts which have the same 64 bit hash even though the public keys are different? As long as the nodes with the same 64-bit hash do not communicate with the same peer at the same time this would have no ill effect at all. > If there is no exchange of larger IDs prior to conversation, then > yes, I agree that one can construct ambiguity scenarios where an > application intends to talk to one host but instead talks to > another. The CB64 draft seems to argue that applications can provide > the additional verification if desired (Sec. 4.1 point 7). Section 4.1 point 7 talks about something different; doing the PK crypto check before any locator change. As specified cb64 relies on the RR check for the initial setup, and not until there is a locator change does it end up using public-key crypto. Erik From owner-multi6@ops.ietf.org Fri Jul 2 10:03: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 KAA06519 for ; Fri, 2 Jul 2004 10:03:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgOdD-000FWl-H2 for multi6-data@psg.com; Fri, 02 Jul 2004 14:03:11 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgOdC-000FWQ-Hb for multi6@ops.ietf.org; Fri, 02 Jul 2004 14:03:10 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i62E1753005244; Fri, 2 Jul 2004 08:01:07 -0600 (MDT) Received: from localhost (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 i62E30225369; Fri, 2 Jul 2004 16:03:01 +0200 (MEST) Date: Fri, 2 Jul 2004 07:02:58 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Advantages and disadvantages of using CB64 type of identifiers To: marcelo bagnulo braun Cc: Erik Nordmark , Multi6 List In-Reply-To: "Your message with ID" <9FBC54E7-CC17-11D8-A131-000D93ACD0FE@ing.uc3m.es> 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.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 > i mean, if the iid is used by apps to provide some form of > authentication/authorization, having a public key that matches with the > iid may enable to impersonate the real owner of the iid, right? > and since the iids are crypto, one may assume that apps may want to use > to authentication, i guess. > But this may depend on the details, i guess. If the upper layers, the application itself, TLS, and IPsec, *only* use the AID as the identifier (and not a certificate name with a PKI, or a longer hash of the same public key that was used to generate the CGA) then this would be a concern. But I suspect that even opportunistic IPsec would rely on having e.g. the full public keys in the DNS or something similar. Hence hash collisions would only be useful for redirecting the encrypted content. Erik From owner-multi6@ops.ietf.org Fri Jul 2 13:23: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 NAA21413 for ; Fri, 2 Jul 2004 13:23:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgRjJ-000G2d-Ak for multi6-data@psg.com; Fri, 02 Jul 2004 17:21:41 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgRjI-000G2K-B5 for multi6@ops.ietf.org; Fri, 02 Jul 2004 17:21:40 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Fri, 2 Jul 2004 10:21:24 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 2 Jul 2004 10:21:34 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 2 Jul 2004 10:21:39 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 2 Jul 2004 10:21:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Advantages and disadvantages of using CB64 type of identifiers Date: Fri, 2 Jul 2004 10:21:38 -0700 Message-ID: Thread-Topic: Advantages and disadvantages of using CB64 type of identifiers thread-index: AcRfvt/ilK0str5/QBKV1gSOYA9yDwAmNDZQ From: "Christian Huitema" To: "Erik Nordmark" , "marcelo bagnulo braun" Cc: "Multi6 List" X-OriginalArrivalTime: 02 Jul 2004 17:21:32.0599 (UTC) FILETIME=[05081C70:01C46059] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > My understanding is that SeND chose different IIDs for different prefixes > but that might be overkill. If the IID is not a function of the prefix > it would enable redirection by a resourceful attacker > by precomputing 2^64 public/private keys that hash to all 2^64 IIDs. > If the content of the packets are encrypted the redirection would not > provide access to the content; it could only be used for DoS or for > gathering the content for cryptoanalysis. There are two issues: catalog attacks and privacy implications. I have already expressed my reservations about the privacy effects of having unique identifiers in addresses. I would certainly not recommend that my company ships anything like that. > A while back Jari Arkko computed the amount of space needed to store > 2^64 precomputed keys, and the storage space was a few buildings the size > of the former world trade center buildings I think. You do not need to compute 2^64 keys to start having an effect. Suppose that there are N users in the system, and that the bad guys have computed a catalog of M keys. The average number of hits that a catalog of size N will achieve is approximately NxM/2^64. There are currently at least 500M Internet users, it is reasonable to expect some growth, so we can set N to about 1 billion -- 2^30. This means you need M=3D2^34 to = get at least one hit. That is probably less than a Terabyte of data, i.e. pretty soon a single hard disk. Everybody should be convinced that, when it comes to cryptography, 2^64 is actually a small number. SEND alleviates this risk by cryptographically link a public key to the entire 128 bits of the address. This is NOT overkill. -- Christian Huitema From owner-multi6@ops.ietf.org Fri Jul 2 17:46:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08617 for ; Fri, 2 Jul 2004 17:46:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgVpf-000Pz5-Kr for multi6-data@psg.com; Fri, 02 Jul 2004 21:44:31 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgVpc-000Pxy-0h for multi6@ops.ietf.org; Fri, 02 Jul 2004 21:44:29 +0000 Received: from gihz1.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i62LiFrC077382; Sat, 3 Jul 2004 07:44:18 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040703073609.01f85d88@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 03 Jul 2004 07:42:23 +1000 To: marcelo bagnulo braun From: Geoff Huston Subject: Re: revision of architecture draft is now published Cc: multi6@ops.ietf.org In-Reply-To: References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <8D58C314-CAA3-11D8-A131-000D93ACD0FE@it.uc3m.es> <6.0.1.1.2.20040702152130.01d6f8c0@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: quoted-printable At 09:19 PM 2/07/2004, marcelo bagnulo braun wrote: >Hi Geoff, > >El 02/07/2004, a las 7:26, Geoff Huston escribi=F3: > >>[...] > >>although my concerns about traffic engineering remain. >> >>I recognise that its in the RFC3582 goal set, but I still have the=20 >>concern that "The consideration here appears to be that hosts need much=20 >>more information at hand if they are to make locator address selection=20 >>decisions based on some form of metric of relative load currently being=20 >>imposed on select components of a number of end-to end network paths, and= =20 >>it raises the entire issue of Traffic Engineering being a network=20 >>function independent of host function or an outcome of host interaction=20 >>with the network, and if the host is to interact with the network how is= =20 >>this interaction to be signalled?" > >Ok, i agree with your point here. > >perhaps we have a terminology problem here.... > >My intention about the TE capabilities of a mh are much more modest than=20 >selecting paths according to the current load. I think that a multihoming= =20 >solution should allow the site to express some sort of preferences about=20 >which path to use, both for incoming and outgoing traffic . I think that=20 >this capability is present in current IPv4 multihoming solution, and=20 >similar capabilities should be provided by the IPv6 multihomig solution. > >I think that this is a reasonable goal, and that we should analyze=20 >different alternatives (if any) to provide it. Perhaps we end up=20 >concluding that the TE capabilities of the IPv6 multihoming solution are=20 >very limited (and that they will not match current IPv4 multihoming TE=20 >capabilities), but i think that this should be conclusion after analysing= =20 >the possibilities and the tradeoffs, hence my opinion that this should be= =20 >part of the analysis. I've no problem with the goal as a theoretical objective. My comment is in= =20 looking at the information available to a host that would be used as the=20 basis of a preference decision. To be of any practical use this preference= =20 would be based on some level of information about the current state of the= =20 network paths (available capacity, latency, [QoS stuff]) and at this point= =20 we appear to be reentering the QoS routing realm with the added issue of=20 host / network interaction. However I suppose that the question here is that given that some=20 considerations about TE should be included in the document, what text is=20 appropriate here that notes the goal, but references the large body of work= =20 that has been undertaken already on QoS and TE? Suggestions are, obviously, solicited! thanks, Geoff From owner-multi6@ops.ietf.org Fri Jul 2 18:12: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 SAA10457 for ; Fri, 2 Jul 2004 18:12:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgWGA-0005Q8-9B for multi6-data@psg.com; Fri, 02 Jul 2004 22:11:54 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgWG8-0005Pe-Ql for multi6@ops.ietf.org; Fri, 02 Jul 2004 22:11:53 +0000 Received: from gihz1.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i62MBgrA077775; Sat, 3 Jul 2004 08:11:44 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040703080325.02123e38@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Sat, 03 Jul 2004 08:11:43 +1000 To: marcelo bagnulo braun From: Geoff Huston Subject: Re: 2nd part Re: revision of architecture draft is now published Cc: multi6@ops.ietf.org In-Reply-To: <2ABC09C2-CAB6-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <2ABC09C2-CAB6-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Marcelo, At 02:54 AM 1/07/2004, marcelo bagnulo braun wrote: >- about section 4.5 > >I am not sure about the following comment: > > "Packet header rewriting by remote network elements has a large number > of associated considerations, and documentation relating to the > considerations of the use of Network Address Translators [4] contains > much of this material." > >I mean, if the multi6 layer within the host replaces the received locator >by the ULP identifier, then it doesn't really matter the locator than was >actually carried in the packet, right? I mean, in any case, the locator is >transparent to the ULP which only deals with the identifier. > >Moreover, perhaps replacing locators by identifiers introduce some of the >nat problems, but in any case, i don't see how this related to the fact >that the locator is replaced by the host or by the edge router. So perhaps >some comment like this one is required but imho is not restricted to this >section but to all mechanisms that replace locators by identifiers. >Perhaps you were considering other issues here? What I was attempting to point out is that packet header rewriting by _remote_ network elements is effectively a description of a session hijacking technique. In order to allow locator rewriting in a manner that is resilient to hijacking there needs to be some element of visible authorization of the locator substitution. A session hijack is an unauthorized and undetected rewriting of packet headers, while a path switch is in effect a authorized rewrite of the packet headers. If this is performed within the host then the authority issues are somewhat different than when such a header rewrite is performed at some point in the network path. If this part of the document is unclear, then perhaps you could suggest a clearer rewording of this? regards, Geoff From owner-multi6@ops.ietf.org Sat Jul 3 10:22:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02010 for ; Sat, 3 Jul 2004 10:22:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BglN5-0009iu-7l for multi6-data@psg.com; Sat, 03 Jul 2004 14:20:03 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BglN3-0009hm-El for multi6@ops.ietf.org; Sat, 03 Jul 2004 14:20:02 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9905F39CEB; Sat, 3 Jul 2004 16:20:00 +0200 (CEST) Received: from [163.117.252.49] (unknown [163.117.252.49]) by smtp01.uc3m.es (Postfix) with ESMTP id C982B39CEE; Sat, 3 Jul 2004 16:19:58 +0200 (CEST) In-Reply-To: <6.0.1.1.2.20040703073609.01f85d88@localhost> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <8D58C314-CAA3-11D8-A131-000D93ACD0FE@it.uc3m.es> <6.0.1.1.2.20040702152130.01d6f8c0@kahuna.telstra.net> <6.0.1.1.2.20040703073609.01f85d88@localhost> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org From: marcelo bagnulo braun Subject: Re: revision of architecture draft is now published Date: Sat, 3 Jul 2004 16:04:43 +0200 To: Geoff Huston X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > However I suppose that the question here is that given that some=20 > considerations about TE should be included in the document, what text=20= > is appropriate here that notes the goal, but references the large body=20= > of work that has been undertaken already on QoS and TE? > > Suggestions are, obviously, solicited! > Well, after re-reading the document, it is my impression that the=20 document actually already contains several references to this point. First, the document includes it explicitely in the base scenario Section 2: =A0=A0In addition there is the potential consideration of being able to =A0=A0distribute traffic load across a number of network paths according = to =A0=A0some pre-determined objective, as a form of traffic engineering. which is all that imho is needed in this part of the doc. After, in section 4.2 the document describes the key point of how path=20= selection is affected in this new multiaddress configuration Section 4.2 =A0=A0The further implication here is that path selection (ISP A vs ISP = B =A0=A0transit for incoming packets) is an outcome of the process of =A0=A0selecting an address for the destination host. Moreover, in the discussion of section 5.3.1 several considerations=20 about locator selection are presented. Perhaps an option would be to include a new subsection in section 5.3=20 about policy based locator selection. In this section, it could be possible to highlight that in this new=20 multiaddress configuration, policy (and TE in general) is no longer=20 solely achieved through manipulation of the routing system, but a=20 relevant part of the path selection is performed through address=20 selection and that it is possible to achieve policing and TE by=20 influencing locator selection process. In particular a reference RFC=20 3484 and its policy table could be useful. Another interesting point that could be considered in the analysis is=20 that the element that performs the locator selection (host or edge=20 router) determines also policy, so the choice of using packet rewriting=20= or host based locator selection shifts the policy capability from one=20 element to the other. this is relevant imho, because if hosts perform policing, then a more=20 fine grained policy is simpler to achieve, because hosts can select=20 locators depending for instance in the application that is sending=20 traffic. However, policy configuration in every host may be a=20 management problem. Finally, policy enforcement may be rather=20 challenging when the host based approach is used, since it is up to the=20= hosts themselves. In the edge router case, policy enforcement by router=20= is more similar to what we have today imho. well, this kind of stuff is what i think could be interesting to=20 include in the analysis, since may be relevant for instance when=20 selecting between the host based and the edge router based locator=20 selection. Regards, marcelo > thanks, > > Geoff > > From owner-multi6@ops.ietf.org Sat Jul 3 10:22:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02028 for ; Sat, 3 Jul 2004 10:22:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BglN9-0009jl-AA for multi6-data@psg.com; Sat, 03 Jul 2004 14:20:07 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BglN8-0009jN-2C for multi6@ops.ietf.org; Sat, 03 Jul 2004 14:20:06 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4121F39CD7; Sat, 3 Jul 2004 16:20:05 +0200 (CEST) Received: from [163.117.252.49] (unknown [163.117.252.49]) by smtp01.uc3m.es (Postfix) with ESMTP id A503839CEE; Sat, 3 Jul 2004 16:20:01 +0200 (CEST) In-Reply-To: <6.0.1.1.2.20040703080325.02123e38@localhost> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <2ABC09C2-CAB6-11D8-A131-000D93ACD0FE@it.uc3m.es> <6.0.1.1.2.20040703080325.02123e38@localhost> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2A4C9B24-CCFC-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org From: marcelo bagnulo braun Subject: Re: 2nd part Re: revision of architecture draft is now published Date: Sat, 3 Jul 2004 16:20:42 +0200 To: Geoff Huston X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 El 03/07/2004, a las 0:11, Geoff Huston escribi=F3: > Hi Marcelo, > > At 02:54 AM 1/07/2004, marcelo bagnulo braun wrote: >> - about section 4.5 >> >> I am not sure about the following comment: >> >> "Packet header rewriting by remote network elements has a large=20 >> number >> of associated considerations, and documentation relating to the >> considerations of the use of Network Address Translators [4]=20 >> contains >> much of this material." >> >> I mean, if the multi6 layer within the host replaces the received=20 >> locator by the ULP identifier, then it doesn't really matter the=20 >> locator than was actually carried in the packet, right? I mean, in=20 >> any case, the locator is transparent to the ULP which only deals with=20= >> the identifier. >> >> Moreover, perhaps replacing locators by identifiers introduce some of=20= >> the nat problems, but in any case, i don't see how this related to=20= >> the fact that the locator is replaced by the host or by the edge=20 >> router. So perhaps some comment like this one is required but imho is=20= >> not restricted to this section but to all mechanisms that replace=20 >> locators by identifiers. >> Perhaps you were considering other issues here? > > What I was attempting to point out is that packet header rewriting by=20= > _remote_ network elements is effectively a description of a session=20 > hijacking technique. In order to allow locator rewriting in a manner=20= > that is resilient to hijacking there needs to be some element of=20 > visible authorization of the locator substitution. A session hijack=20= > is an unauthorized and undetected rewriting of packet headers, while a=20= > path switch is in effect a authorized rewrite of the packet headers.=20= > If this is performed within the host then the authority issues are=20 > somewhat different than when such a header rewrite is performed at=20 > some point in the network path. > > If this part of the document is unclear, then perhaps you could=20 > suggest a clearer rewording of this? > Ok, this is not what i thought you were considering at this point. Since you are aiming to a security issue, i would suggest that you=20 include a reference to the threats document here. I mean, i would say=20 that : Packet header rewriting by remote network elements has a large number=20 of associated security considerations, and any packet rewriting=20 mechanism has to provide proper protection against the attacks=20 described in [threats], in particular against Redirection Attacks regards, marcelo > regards, > > Geoff > From owner-multi6@ops.ietf.org Sat Jul 3 10:22: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 KAA02046 for ; Sat, 3 Jul 2004 10:22:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BglNA-0009k8-SK for multi6-data@psg.com; Sat, 03 Jul 2004 14:20:08 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BglN1-0009h0-GV for multi6@ops.ietf.org; Sat, 03 Jul 2004 14:19:59 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 9B7D239D07; Sat, 3 Jul 2004 16:19:58 +0200 (CEST) Received: from [163.117.252.49] (unknown [163.117.252.49]) by smtp01.uc3m.es (Postfix) with ESMTP id A03F939CEE; Sat, 3 Jul 2004 16:19:56 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <222ACFCC-CCF1-11D8-A131-000D93ACD0FE@ing.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: "Multi6 List" , "Erik Nordmark" From: marcelo bagnulo braun Subject: Re: Advantages and disadvantages of using CB64 type of identifiers Date: Sat, 3 Jul 2004 15:01:43 +0200 To: "Christian Huitema" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: quoted-printable Hi Christian, El 02/07/2004, a las 19:21, Christian Huitema escribi=F3: >> My understanding is that SeND chose different IIDs for different > prefixes >> but that might be overkill. If the IID is not a function of the = prefix >> it would enable redirection by a resourceful attacker >> by precomputing 2^64 public/private keys that hash to all 2^64 IIDs. >> If the content of the packets are encrypted the redirection would not >> provide access to the content; it could only be used for DoS or for >> gathering the content for cryptoanalysis. > > There are two issues: catalog attacks and privacy implications. I have > already expressed my reservations about the privacy effects of having > unique identifiers in addresses. I would certainly not recommend that=20= > my > company ships anything like that. > i don't fully understand why do you think that having an identifier in=20= the address is worse than current IPv4 situation (where the id and=20 locator are one, and multihomed sites have a single address) or the=20 current IPv6 situation (i guess that something similar to privacy=20 extensions could be achieved by periodically creating new keys hence=20 new identifiers) >> A while back Jari Arkko computed the amount of space needed to store >> 2^64 precomputed keys, and the storage space was a few buildings the > size >> of the former world trade center buildings I think. > > You do not need to compute 2^64 keys to start having an effect. = Suppose > that there are N users in the system, and that the bad guys have > computed a catalog of M keys. The average number of hits that a = catalog > of size N will achieve is approximately NxM/2^64. There are currently=20= > at > least 500M Internet users, it is reasonable to expect some growth, so=20= > we > can set N to about 1 billion -- 2^30. This means you need M=3D2^34 to = get > at least one hit. Yes but how useful would this single hit be? i mean this hit is likely to correspond with an identifier of an=20 unknown host. i guess that an attacker would be interested in knowing the identifier=20= of a specific victim, right? perhaps we need (at least i need) to understand the potential attacks a=20= bit more... > That is probably less than a Terabyte of data, i.e. > pretty soon a single hard disk. > > Everybody should be convinced that, when it comes to cryptography, = 2^64 > is actually a small number. SEND alleviates this risk by > cryptographically link a public key to the entire 128 bits of the > address. This is NOT overkill. i still don't have an opinion about this being an overkill or not. regards, marcelo > > -- Christian Huitema > From owner-multi6@ops.ietf.org Sun Jul 4 00:02: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 AAA08169 for ; Sun, 4 Jul 2004 00:02:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BgyAq-000Jjv-GH for multi6-data@psg.com; Sun, 04 Jul 2004 04:00:16 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BgyAp-000Jjc-CN for multi6@ops.ietf.org; Sun, 04 Jul 2004 04:00:15 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 90E853AD for ; Sun, 4 Jul 2004 00:00:14 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 04 Jul 2004 00:00:14 -0400 Message-Id: <20040704040014.90E853AD@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Messages | Bytes | Who --------+------+--------+----------+------------------------ 29.81% | 31 | 25.86% | 127832 | erik.nordmark@sun.com 21.15% | 22 | 21.55% | 106530 | marcelo@it.uc3m.es 7.69% | 8 | 16.22% | 80156 | kurtis@kurtis.pp.se 9.62% | 10 | 8.98% | 44383 | iljitsch@muada.com 8.65% | 9 | 7.24% | 35778 | brc@zurich.ibm.com 4.81% | 5 | 4.24% | 20974 | jukka.ylitalo@nomadiclab.com 3.85% | 4 | 3.87% | 19137 | thomas.r.henderson@boeing.com 3.85% | 4 | 2.83% | 13977 | gih@telstra.net 3.85% | 4 | 2.82% | 13961 | mbagnulo@ing.uc3m.es 1.92% | 2 | 1.69% | 8347 | huitema@windows.microsoft.com 0.96% | 1 | 1.73% | 8551 | jeroen@unfix.org 0.96% | 1 | 1.00% | 4935 | internet-drafts@ietf.org 0.96% | 1 | 0.92% | 4540 | shep@alum.mit.edu 0.96% | 1 | 0.54% | 2659 | sra@hactrn.net 0.96% | 1 | 0.52% | 2557 | lambert@psc.edu --------+------+--------+----------+------------------------ 100.00% | 104 |100.00% | 494317 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Jul 4 03:59:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29368 for ; Sun, 4 Jul 2004 03:59:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh1sY-0003jy-FR for multi6-data@psg.com; Sun, 04 Jul 2004 07:57:38 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh1sW-0003ja-Sb for multi6@ops.ietf.org; Sun, 04 Jul 2004 07:57:37 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i647vZGm093886; Sun, 4 Jul 2004 07:57:35 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i647vYsw135042; Sun, 4 Jul 2004 09:57:34 +0200 Received: from zurich.ibm.com (sig-9-145-172-72.de.ibm.com [9.145.172.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA43560; Sun, 4 Jul 2004 09:57:33 +0200 Message-ID: <40E7B863.9070505@zurich.ibm.com> Date: Sun, 04 Jul 2004 09:57:23 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Christian Huitema CC: Erik Nordmark , marcelo bagnulo braun , Multi6 List Subject: Is 80 bits enough? [Re: Advantages and disadvantages of using CB64 type of identifiers] 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.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 Christian Huitema wrote: ... > > Everybody should be convinced that, when it comes to cryptography, 2^64 > is actually a small number. SEND alleviates this risk by > cryptographically link a public key to the entire 128 bits of the > address. This is NOT overkill. But is 2^80 big enough? Omitting the /48 prefix from the crypto would avoid the hash changing when rehoming to a different prefix. Brian From owner-multi6@ops.ietf.org Sun Jul 4 04:01: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 EAA29428 for ; Sun, 4 Jul 2004 04:01:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh1wX-0004e2-S3 for multi6-data@psg.com; Sun, 04 Jul 2004 08:01:45 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh1wW-0004dO-Fr for multi6@ops.ietf.org; Sun, 04 Jul 2004 08:01:44 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6481hgB101758 for ; Sun, 4 Jul 2004 08:01:43 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6481hsw177274 for ; Sun, 4 Jul 2004 10:01:43 +0200 Received: from zurich.ibm.com (sig-9-145-172-72.de.ibm.com [9.145.172.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA24794 for ; Sun, 4 Jul 2004 10:01:41 +0200 Message-ID: <40E7B958.4050602@zurich.ibm.com> Date: Sun, 04 Jul 2004 10:01:28 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Re: draft-nordmark-multi6-threats-01.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.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: ... > >>I guess that different apps will have different security requirements. >>However, i am considering the default scenario here. I mean the multi6 >>solution will provide some default level of security based on some >>security tools used by the solution. >>If a particular communication requires additional security, it will >>obtain it by special means (TLS for instance) > > > But TLS wouldn't by itself prevent a weakness in the multihoming layer > being used to redirect the packets to a black hole; neither would IPsec > when IPsec is layer above the multihoming layer. Yes, let's focus on multi6 not making things worse at the network layer, now that we have decided to focus on network layer solutions. As long as we meet that goal, and allow IPSEC and TLS to work as normal, we haven't made things worse for apps, and that all we should aim at. Brian From owner-multi6@ops.ietf.org Sun Jul 4 04:21: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 EAA00290 for ; Sun, 4 Jul 2004 04:21:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh2Fi-0007cp-Nn for multi6-data@psg.com; Sun, 04 Jul 2004 08:21:34 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh2Fh-0007cB-G4 for multi6@ops.ietf.org; Sun, 04 Jul 2004 08:21:33 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i648LRGP083110; Sun, 4 Jul 2004 08:21:27 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i648LQtV291010; Sun, 4 Jul 2004 10:21:26 +0200 Received: from zurich.ibm.com (sig-9-145-172-72.de.ibm.com [9.145.172.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA60578; Sun, 4 Jul 2004 10:21:24 +0200 Message-ID: <40E7BDFB.7030708@zurich.ibm.com> Date: Sun, 04 Jul 2004 10:21:15 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 CC: Iljitsch van Beijnum Subject: Re: how secure mh should be? Re: identifiers and security References: <3D0D030A-CB34-11D8-A581-000A95928574@kurtis.pp.se> <990DE4D4-CB43-11D8-A131-000D93ACD0FE@it.uc3m.es> <0AF7811D-CBF0-11D8-A205-000A95928574@kurtis.pp.se> In-Reply-To: <0AF7811D-CBF0-11D8-A205-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.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 Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2004-07-01, at 11.46, marcelo bagnulo braun wrote: > > >>imho is important to reach a common criteria here. >> >>i think that the minimum goal should be that the resulting solution >>should be as secure as current fixed, single homed IPv6 internet. >> >>As you say, i wouldn't mind if the result is a bit more secure, but i >>wouldn't require it > > > I've been struggling not to say that maybe we should. But that is more > of a layer9/mgmt issue as we then would require to define "how much" > better. But I think that every improvement is a big advantage. Well, we have a generic threat analysis accepted as a WG draft. I think (as Iljitsch said when discussing the agenda of the interim meeting) that we will need to refine the threat analysis once we have a clear sense of the recommended direction for the solution. Personally, I think we should suspend the philosophical debate until then, and concentrate on reaching a concrete outline of the wedge/3.5 model. Brian From owner-multi6@ops.ietf.org Sun Jul 4 04: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 EAA00603 for ; Sun, 4 Jul 2004 04:28:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh2MB-0008jD-2L for multi6-data@psg.com; Sun, 04 Jul 2004 08:28:15 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh2M9-0008iP-Mf for multi6@ops.ietf.org; Sun, 04 Jul 2004 08:28:14 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i648SBgB049360; Sun, 4 Jul 2004 08:28:11 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i648SBtV237906; Sun, 4 Jul 2004 10:28:11 +0200 Received: from zurich.ibm.com (sig-9-145-172-72.de.ibm.com [9.145.172.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA60638; Sun, 4 Jul 2004 10:28:08 +0200 Message-ID: <40E7BF8F.70101@zurich.ibm.com> Date: Sun, 04 Jul 2004 10:27:59 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: marcelo bagnulo braun CC: Multi6 Subject: Re: identity persistence and comparison issues References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <98F51062-C9D9-11D8-A131-000D93ACD0FE@it.uc3m.es> In-Reply-To: <98F51062-C9D9-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: 8bit marcelo bagnulo braun wrote: > > El 29/06/2004, a las 13:30, Brian E Carpenter escribió: > >> Iljitsch van Beijnum wrote: >> >>> On 28-jun-04, at 14:45, Erik Nordmark wrote: >>> >>>> And if the long-lived ID is one of the locators we can provide >>>> compatbility >>>> for unmodified applications which do referrals and callbacks. >>> >>> We should really talk to some apps people to figure out how important >>> this is. It's entirely trivial to shoot yourself in the foot today >>> with NAT or multiple addresses anyway, and then there is dual stack. >>> How are referrals going to work when a future participant in the >>> communication may be limited to one IP version, which happens to be >>> the other one than the one used by current participants? >>> It may very well be that apps and protocols need to be changed anyway >>> in order to work with IPv6, or IPv4+IPv6. >> >> >> The point is that today, the underlying assumption of most applications >> is that the IP address they get back from an A or AAAA query, or any >> other source including manual config, is a permanent identifier with >> the nice property that the routing system can use it as a locator. >> >> NAT breaks this assumption of course. But we are trying to repair the >> damage done by NAT. So I suggest that a multi6 goal should be that the >> thing an application gets back from an AAAA query, or any other source >> including manual config, > > > including a referral? That is my meaning, yes. Brian > > >> must be a permanent identifier with the >> nice property that something below the socket API can transform it >> into a locator. >> > > i agree with this > > regards, marcelo > >> Which leads me to wonder whether session survival for sessions using >> temporary things such as RFC 3041 addresses is a reasonable goal for >> multi6. >> >> Brian >> > > > From owner-multi6@ops.ietf.org Sun Jul 4 04:40: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 EAA01019 for ; Sun, 4 Jul 2004 04:40:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh2XT-000Ag2-35 for multi6-data@psg.com; Sun, 04 Jul 2004 08:39:55 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh2XR-000AfX-OL for multi6@ops.ietf.org; Sun, 04 Jul 2004 08:39:54 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i648dqGP115716; Sun, 4 Jul 2004 08:39:52 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i648dqtV242082; Sun, 4 Jul 2004 10:39:52 +0200 Received: from zurich.ibm.com (sig-9-145-172-72.de.ibm.com [9.145.172.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA26868; Sun, 4 Jul 2004 10:39:51 +0200 Message-ID: <40E7C24D.6090905@zurich.ibm.com> Date: Sun, 04 Jul 2004 10:39:41 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Christian Huitema CC: Multi6 Subject: Re: identity persistence and comparison issues 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.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 Christian, Christian Huitema wrote: >>The point is that today, the underlying assumption of most > > applications > >>is that the IP address they get back from an A or AAAA query, or any >>other source including manual config, is a permanent identifier with >>the nice property that the routing system can use it as a locator. > > > Is that actually true? I wish I'd written "most middleware" because that is really what I meant, but it isn't a popular word in the IETF. > > Looking at my own neighborhood, I see the following: > > 1) The most popular applications, web browsing and e-mail, do not make > the assumption that addresses are identifiers. Web servers commonly use > techniques such as DNS load balancers, and the clients see a different > address every time. For some definition of "time". Within the time that the client middleware caches a DNS reply (which may or may not correspond to the official TTL), the address is treated as permanent. Indeed, the clash between this and the (sometimes egregious) behaviour of DNS load balancers can today cause problems.... RFC 2775. > Mail clients typically resolve a domain name before > any attempt to communicate with a server. Except for the bizarre case of mail to user@[IPv6:2001:xxxx] > > 2) The vast majority of networking applications are not written to the > socket API. They are typically written in Visual Basic, C# or other high > level languages, and they interface the network through high level calls > such as RPC, DCOM or WinInet (an API to the HTTP protocol). The > underlying libraries do not assume that the addresses are fixed; the API > typically uses a service name or a server name, not an IP address. The middleware may have the illusion that the FQDN is the identifier in use, but run time middleware such as JDK or Globus XIO uses sockets and caches DNS replies. Indeed, if the application layer uses an FQDN for referrals, we don't have a problem with referrals - but although we might recommend this, we can't enforce it. > > 3) Emerging applications written around instant messaging services, peer > to peer services or SIP do not assume that a host address is fixed. > Indeed, the SIP payloads carry the "current IP address" at which a SIP > UA expects to receive packets. Yes, post-NAT applications have to deal with this - but if the "current IP address" changes due to multihoming, how will the SIP layer know it, unless we enhance the socket API? > > Indeed, most of these applications have a concept of "session", and > expect that the addresses will remain stable for the duration of the > session. But many also have a capability to reconnect if the session is > interrupted, and the reconnection procedures typically include a name > resolution. Yes. But do we want that to become the *expected* behaviour following a multihoming event? Brian From owner-multi6@ops.ietf.org Sun Jul 4 04: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 EAA01200 for ; Sun, 4 Jul 2004 04:43:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh2ar-000BKs-6h for multi6-data@psg.com; Sun, 04 Jul 2004 08:43:25 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh2an-000BK7-Ry for multi6@ops.ietf.org; Sun, 04 Jul 2004 08:43:22 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i648hFGm088576; Sun, 4 Jul 2004 08:43:15 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i648hFsw175472; Sun, 4 Jul 2004 10:43:15 +0200 Received: from zurich.ibm.com (sig-9-145-172-72.de.ibm.com [9.145.172.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA88792; Sun, 4 Jul 2004 10:43:13 +0200 Message-ID: <40E7C318.8080909@zurich.ibm.com> Date: Sun, 04 Jul 2004 10:43:04 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Subject: Re: Install DNS mappings based on TLS/IPsec? References: <906B9382-CA0D-11D8-9359-000A95CD987A@muada.com> In-Reply-To: <906B9382-CA0D-11D8-9359-000A95CD987A@muada.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.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 Iljitsch, Are you suggesting that the multi6 solution should have a strict dependency on using TLS or IPSEC? Brian Iljitsch van Beijnum wrote: > One of the problems we may have to solve is a mapping system from an > identifier to a set of locators, or from a single locator to the full > set. A straightforward way to do this would be routable IP address -> > FQDN -> full set of routable IP addresses. Unfortunately, this requires > that both the forward and reverse DNS trees are populated properly. This > in itself is somewhat hard (but doable for well-managed sites, if not > for ad-hoc and "basement multihoming" situations). However, without full > deployment of DNSSEC this information isn't particularly trustworthy. > > It occurs to me that there may be an alternative way to make these FQDN > <-> address mappings available: they can be negotiated as part of the > IPsec or TLS negotiations. Think about it: TLS already verifies > ownership of a FQDN, so after that any FQDN -> address mappings that are > provided are supposedly trustworthy, and more so than information > learned through unprotected DNS queries. > > In many cases, a reverse lookup (address -> FQDN) isn't necessary, but > if it is, things get more complicated. It's not inconceivable that > someone would want to override valid reverse mapping information in the > DNS with invalid information negotiatated with IPsec/TLS. For instance, > I may have a valid certificate for justforkicks.net and I could tell you > that the addresses that belong to Google actually map to > justforkicks.net and then any time Google spiders your website my domain > name shows up in your logs. Not immediately fatal, but problematic > nonetheless. This problem can be solved in one of two ways: > > 1. only allow installing reverse mapping if there aren't any present in > the DNS > 2. only allow installing reverse mapping for addresses that wouldn't > normally be used for non-MH purposes > > An example of the addresses under 2. could be RFC 3041 addresses. Those > can be used for non-MH purposes, but presumably not for anything that > would be bothered by injecting false reverse DNS information. I.e. as > long as people don't use RFC 3041 addresses for anything worth MH > protection there is no problem. Another choice would be addresses > derived from EUI-64s with the u/l flag set to global and the group bit > set. There is currently no reasonable way that such addresses show up by > accidentt. > > I think that such a mechanism would very nicely compliment a NOID-like > solution, as it effectively removes dependency on the DNS for a large > number of applications. At the same time, the solution in question can > be deployed without having to wait for this mechanism to be implemented; > it can be put to use as soon as it's available, in the mean time there's > the DNS. > > From owner-multi6@ops.ietf.org Sun Jul 4 05:09:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02040 for ; Sun, 4 Jul 2004 05:09:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh2zE-000GQv-Ur for multi6-data@psg.com; Sun, 04 Jul 2004 09:08:36 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh2zD-000GQG-JI for multi6@ops.ietf.org; Sun, 04 Jul 2004 09:08:36 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6498YGP109228 for ; Sun, 4 Jul 2004 09:08:34 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6498Ysw179102 for ; Sun, 4 Jul 2004 11:08:34 +0200 Received: from zurich.ibm.com (sig-9-145-172-72.de.ibm.com [9.145.172.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA43432 for ; Sun, 4 Jul 2004 11:08:33 +0200 Message-ID: <40E7C907.1030605@zurich.ibm.com> Date: Sun, 04 Jul 2004 11:08:23 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Modified CGAs? [Re: about Wedgelayer 3.5 / Fat IP approaches] References: <40E1575A.9010709@zurich.ibm.com> <8E1939A4-C9D8-11D8-A131-000D93ACD0FE@it.uc3m.es> <40E2DC40.1050909@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: 8bit marcelo bagnulo braun wrote: > > El 30/06/2004, a las 17:29, Brian E Carpenter escribió: > >>>> >>>> CGAs have other downsides for multihoming, too. >>>> >>> such as? >> >> >> >> >> >> I really don't want to start a discussion here about cryptographic >> strength, but my objection to CGAs in the multi6 context is that they >> include the /48 prefix in the hash, and that is variable in multi6, >> which means that the host ID changes when you change prefix. I think >> that's an unfortunate property because it eliminates some possible >> tricks in the ID/locator split. >> > > Well, probably it is my fault for using the wrong terminology, but i was > considering cgas as a concept rather than the specific approach followed > by the send wg. > for instance you can consider the cb64 draft or even the ideas discussed > between Iljitsch and Jari about including all the prefixes or some other > workarounds. > > My point was basically that having a string that it can be used as a > valid locator and that it also has a crypto nature would provide several > benefits, since it enables a way to prove its ownership and apps can > treat it as a regular ip address > > Makes more sense? Yes, and my first thought on reading the SEND CGA draft was that a very simple modification to CGAs - not including the /48 in the hash - would make them suitable for multi6 and still make the attacker's problem sufficiently hard (2^80). On another point elsewhere in this thread, my assumption has always been that the need for uniqueness applies only to {prefix + subnet + CGA} Brian > > regards, marcelo > > PS: it is clear that if we are going to use one locator as ULP id, the > id will have to change when renumbering, the benefit of this, is that > apps still handle ip addresses and that most of their assumptions still > hold. > >> Brian >> > > From owner-multi6@ops.ietf.org Sun Jul 4 05:14: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 FAA02214 for ; Sun, 4 Jul 2004 05:14:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh34Z-000HSB-Mg for multi6-data@psg.com; Sun, 04 Jul 2004 09:14:07 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh34Y-000HRi-BO for multi6@ops.ietf.org; Sun, 04 Jul 2004 09:14:06 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i649E5gB112652 for ; Sun, 4 Jul 2004 09:14:05 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i649E5sw179122 for ; Sun, 4 Jul 2004 11:14:05 +0200 Received: from zurich.ibm.com (sig-9-145-172-72.de.ibm.com [9.145.172.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA43544 for ; Sun, 4 Jul 2004 11:14:03 +0200 Message-ID: <40E7CA52.6070900@zurich.ibm.com> Date: Sun, 04 Jul 2004 11:13:54 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Re: about Wedgelayer 3.5 / Fat IP approaches 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.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 I'm going to declare this a bogus concern for multi6. If people need shorter prefixes than /48 because 65k subnets are not enough, that is an IANA/RIR issue. We should work within current assumptions, i.e. that the IID is 64 bits. It would be good to avoid this being an architectural restriction - but arguing for a 64 bit IID on grounds of cryptographic strength is fine. If someone wants to run with a 48 bit ID and accept the cryprographic risk, that isn't our problem here. Brian (co-chair hat on) Tim Shepard wrote: >>>>CB64 -like split sounds good. Right, there arises some AID >>>>ownership problems if it is not bound to the HIT. >>>>It would be nice to have a new version of Multi6 HIP draft that >>>>describes how HIP could be used with CB64 -like AIDs. >>>> >>> >>>how this would differ from the cb64 draft by Erik? >>> > > >>So, assuming that HIP hosts started to use low order bits of the >>[...] >>details): >>- CB64 handshake occurs in parallel with start of data transfer >>(actually, after first data packet has been sent), while HIP holds >>the first packet waiting for HIP handshake to complete (or >>possibly piggybacks it on the HIP exchange).=20 >>- CB64 uses flow IDs and locators as keys to find context state >>for the session, while HIP uses IPsec SPIs >>- CB64 adds new locator for peer upon discovering it as a source >>address in a packet (and issuing PK-signed challenge/response),=20 >>while HIP explicitly signals the new locator in a signed HIP=20 >>exchange. >> >>Another difference is length of the hash of the key, which may >>cause some subtle differences. With 64 bit IDs (or, strictly >>speaking, ID tags, since the public keys are the actual >>identifiers), we can provide an embedded stack name in the AID,=20 >>whereas with HITs, we can only provide a mapping between=20 >>(truncated) stack name and AIDs. When we have discussed=20 >>shortening HITs to accommodate some structure to aid reverse=20 >>lookups, there have been concerns raised that 64 bit IDs might=20 >>not be strong enough to withstand server farm attacks in the=20 >>future (generating different key that hashes to same ID). =20 >>[...] > > > > I am concerned about putting hashes in the bottom 64-bits of IPv6 > addresses, because that may lead to a future (albiet, probably a few > years or decades out) when we discover that some situations are > constrained by a shortage of IPv6 address space. For example, someone > who only gets a /48 prefix from their provider, and has gazillions of > machines to deploy whose stacks and/or applications all expect the > bottom 64-bits to be this hash thing, has to do all of their > subnetting in a 16-bit field. That 16-bit field is just too small for > my taste. I'd worry a lot less if it was 32-bits. So maybe if we can > figure out how to ensure that anyone who wants one can get a /40 > prefix from each and every ISP that they buy some connectivity from, > and can confine the hash thing to the bottom 56 bits of the IPv6 > address, then that would laeve 32-bits in between, and it might then > be OK. But now 56-bits might not be long enough to get the security > we want from the hash? > > Maybe IPv6 should have been designed with 192-bit addresses so that > there would clearly be enough bits to put together all of these sorts > of techniques. > > -Tim Shepard > shep@alum.mit.edu > From owner-multi6@ops.ietf.org Sun Jul 4 05:16:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02380 for ; Sun, 4 Jul 2004 05:16:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh36y-000I0x-LW for multi6-data@psg.com; Sun, 04 Jul 2004 09:16:36 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh36x-000I0A-7u for multi6@ops.ietf.org; Sun, 04 Jul 2004 09:16:35 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i649GYGP024348 for ; Sun, 4 Jul 2004 09:16:34 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i649GXtV144420 for ; Sun, 4 Jul 2004 11:16:34 +0200 Received: from zurich.ibm.com (sig-9-145-172-72.de.ibm.com [9.145.172.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA80180 for ; Sun, 4 Jul 2004 11:16:32 +0200 Message-ID: <40E7CAE6.5060503@zurich.ibm.com> Date: Sun, 04 Jul 2004 11:16:22 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.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.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 Some discussion on this thread refers to dependency on HIP. Question to the WG: given the current state of HIP, do we want to consider dependency on HIP as a) acceptable b) unacceptable? Brian (co-chair hat on) From owner-multi6@ops.ietf.org Sun Jul 4 05:56: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 FAA03657 for ; Sun, 4 Jul 2004 05:56:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh3ip-000ME1-Ay for multi6-data@psg.com; Sun, 04 Jul 2004 09:55:43 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh3in-000MDg-UQ for multi6@ops.ietf.org; Sun, 04 Jul 2004 09:55:42 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i649v22r021177; Sun, 4 Jul 2004 11:57:04 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40E7C318.8080909@zurich.ibm.com> References: <906B9382-CA0D-11D8-9359-000A95CD987A@muada.com> <40E7C318.8080909@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4C81F70F-CDA0-11D8-9011-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Install DNS mappings based on TLS/IPsec? Date: Sun, 4 Jul 2004 11:55:36 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 4-jul-04, at 10:43, Brian E Carpenter wrote: > Are you suggesting that the multi6 solution should have a strict > dependency on using TLS or IPSEC? Certainly not. I'm saying two things: - if the DNS doesn't work, discover information that would normally be in the DNS through the TLS or IKE negotiation, and - the DNS is often insecure, so let the TLS or IKE derived information override it to increase security But if TLS/IPsec aren't used, the information is taken from the DNS. From owner-multi6@ops.ietf.org Sun Jul 4 06:04: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 GAA03885 for ; Sun, 4 Jul 2004 06:04:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh3r0-000Nnv-6o for multi6-data@psg.com; Sun, 04 Jul 2004 10:04:10 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh3qq-000NjR-P8 for multi6@ops.ietf.org; Sun, 04 Jul 2004 10:04:01 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i64A5O2r021361; Sun, 4 Jul 2004 12:05:24 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40E7CAE6.5060503@zurich.ibm.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <778E1EDC-CDA1-11D8-9011-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] Date: Sun, 4 Jul 2004 12:03:58 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 4-jul-04, at 11:16, Brian E Carpenter wrote: > Question to the WG: given the current state of HIP, do we > want to consider dependency on HIP as > a) acceptable > b) unacceptable? Unless I'm mistaken HIP is still work in progress so that doesn't help. Apart from that I have two concerns: the identifier space is flat, which can create problems such as with referrals, and HIP as it is today requires the use of IPsec, which adds processing and bandwidth overhead whether or not this is desired or appropriate for a certain communication session. This leads me to believe that using HIP as-is isn't a very good idea for multi6, but it's certainly conceivable that a good multihoming solution could be created based largely on HIP. From owner-multi6@ops.ietf.org Sun Jul 4 06:21: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 GAA04397 for ; Sun, 4 Jul 2004 06:21:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bh46p-000Ph8-14 for multi6-data@psg.com; Sun, 04 Jul 2004 10:20:31 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bh46n-000Pgh-ET for multi6@ops.ietf.org; Sun, 04 Jul 2004 10:20:30 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 76CDF39D57; Sun, 4 Jul 2004 12:20:28 +0200 (CEST) Received: from [163.117.252.20] (unknown [163.117.252.20]) by smtp01.uc3m.es (Postfix) with ESMTP id F3F9539D39; Sun, 4 Jul 2004 12:20:26 +0200 (CEST) In-Reply-To: <40E7BF8F.70101@zurich.ibm.com> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <98F51062-C9D9-11D8-A131-000D93ACD0FE@it.uc3m.es> <40E7BF8F.70101@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <65301179-CDA2-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 From: marcelo bagnulo braun Subject: Re: identity persistence and comparison issues Date: Sun, 4 Jul 2004 12:10:37 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 El 04/07/2004, a las 10:27, Brian E Carpenter escribi=F3: >>> NAT breaks this assumption of course. But we are trying to repair = the >>> damage done by NAT. So I suggest that a multi6 goal should be that=20= >>> the >>> thing an application gets back from an AAAA query, or any other=20 >>> source >>> including manual config, >> including a referral? > > That is my meaning, yes. > ok. I wonder if this goal doesn't imposes ULP identifiers to be routable IP=20= addresses I mean, when we consider backward compatibility in a communication=20 between to hosts, we can assume that if the two hosts are multi6=20 capable they will recognize each other and they will start using the=20 new identifier name space and that when a multi6 capable host=20 communicates with a non multi6 capable host, the multi6 capable one=20 will find out that the other host don't support the multi6 solution and=20= will fall back to legacy IPv6 and will use IPv6 addresses as=20 identifiers. so far everything is ok however, if you add referrals support, the problem is that the multi6=20 capable host doesn't know in which host the identifier will end up, as=20= Erik has mentioned. So even if the identifier has been initially used=20 between two multi6 capable hosts, in a future communication, one of=20 them can use this new identifier in a referral to a non multi6 capable=20= host, which will fail, since it will unable to use it as a valid=20 locator. So, coming back to the goal as you stated it: a multi6 goal should be that the thing an application gets back from an AAAA query, or any other source including manual config, must be a permanent identifier with the nice property that something below the socket API can transform it into a locator. So as we don't know if the host that receives the referral is multi6=20 capable, we don't know if there will be something below the socket api=20= to make the transformation. So i guess that in order to fulfill this goal and to be fully backward=20= compatible, the ULP identifier adopted by the multi6 solution has to be=20= a routable IP address. The other option would be decide not to support this kind of scenario. Regards, marcelo > Brian > >>> must be a permanent identifier with the >>> nice property that something below the socket API can transform it >>> into a locator. >>> >> i agree with this >> regards, marcelo >>> Which leads me to wonder whether session survival for sessions using >>> temporary things such as RFC 3041 addresses is a reasonable goal for >>> multi6. >>> >>> Brian >>> > From owner-multi6@ops.ietf.org Mon Jul 5 02:14: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 CAA07391 for ; Mon, 5 Jul 2004 02:14:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhMhy-000CVR-Jl for multi6-data@psg.com; Mon, 05 Jul 2004 06:12:06 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhMhx-000CVD-KQ for multi6@ops.ietf.org; Mon, 05 Jul 2004 06:12:05 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Sun, 4 Jul 2004 23:12:07 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 4 Jul 2004 23:12:23 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 4 Jul 2004 23:12:03 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Sun, 4 Jul 2004 23:11:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Advantages and disadvantages of using CB64 type of identifiers Date: Sun, 4 Jul 2004 23:12:04 -0700 Message-ID: Thread-Topic: Advantages and disadvantages of using CB64 type of identifiers thread-index: AcRhCVMqC8U1x+iiRhiEm2XB8WVgvQBTE9Dw From: "Christian Huitema" To: "marcelo bagnulo braun" Cc: "Multi6 List" , "Erik Nordmark" X-OriginalArrivalTime: 05 Jul 2004 06:11:55.0912 (UTC) FILETIME=[F9197080:01C46256] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > i don't fully understand why do you think that having an identifier in > the address is worse than current IPv4 situation (where the id and > locator are one, and multihomed sites have a single address) or the > current IPv6 situation (i guess that something similar to privacy > extensions could be achieved by periodically creating new keys hence > new identifiers) First, I don't believe in arguments such as "this is not worse than what we did in the past" when it comes to security and privacy. We should be on a path to improvement, not a soft descent into complacency. Second, having a unique 64 bit identifier in the addresses is actually worse than the current situation in either IPv4 or IPv6.=20 In IPv4, the addresses are often dynamically affected; it is possible, if a site manager so chooses, to give nodes a different address at each session. Hosts using dial-up connections receive new addresses for each connection. Hosts using broadband connections often receive new addresses every 24 hours. When a host is multi-homed to several networks, it will indeed receive different IPv4 addresses on each of these networks. The current IPv6 practice is to have the 64 bit identifier be either an IEEE 802 identifier (default) or a random number (temporary addresses, SEND). When a host is multi-homed through several interfaces, the different identifiers are used on different interfaces. When a host configures addresses from multiple prefixes on the same interface, the 802 identifier will often be the same, but the random identifiers will be different. The current ND spec allows for using the same identifier with different prefixes, but it certainly does not mandate it. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Jul 5 02:14: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 CAA07433 for ; Mon, 5 Jul 2004 02:14:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhMkZ-000Co8-T1 for multi6-data@psg.com; Mon, 05 Jul 2004 06:14:47 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhMkZ-000Cnr-2T for multi6@ops.ietf.org; Mon, 05 Jul 2004 06:14:47 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Sun, 4 Jul 2004 23:14:07 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 4 Jul 2004 23:15:05 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 4 Jul 2004 23:15:04 -0700 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); Sun, 4 Jul 2004 23:14:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Is 80 bits enough? [Re: Advantages and disadvantages of using CB64 type of identifiers] Date: Sun, 4 Jul 2004 23:14:45 -0700 Message-ID: Thread-Topic: Is 80 bits enough? [Re: Advantages and disadvantages of using CB64 type of identifiers] thread-index: AcRhnKZfnGTSORPXR6CfBEam6cxVZAAunveg From: "Christian Huitema" To: "Brian E Carpenter" Cc: "Erik Nordmark" , "marcelo bagnulo braun" , "Multi6 List" X-OriginalArrivalTime: 05 Jul 2004 06:14:51.0435 (UTC) FILETIME=[61B81FB0:01C46257] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > > Everybody should be convinced that, when it comes to cryptography, 2^64 > > is actually a small number. SEND alleviates this risk by > > cryptographically link a public key to the entire 128 bits of the > > address. This is NOT overkill. >=20 > But is 2^80 big enough? Omitting the /48 prefix from the crypto would > avoid the hash changing when rehoming to a different prefix. Not really. The 16 bit subnet identifier is not very random in practice. In many cases, the value is 0 or 1, and you get only 1 additional bit, not 16... -- Christian Huitema From owner-multi6@ops.ietf.org Mon Jul 5 02:38: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 CAA09534 for ; Mon, 5 Jul 2004 02:38:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhN6u-000GLO-Q8 for multi6-data@psg.com; Mon, 05 Jul 2004 06:37:52 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhN6r-000GKy-2u for multi6@ops.ietf.org; Mon, 05 Jul 2004 06:37:49 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 3436A8983B; Mon, 5 Jul 2004 09:37:48 +0300 (EEST) Message-ID: <40E8F61C.90200@piuha.net> Date: Mon, 05 Jul 2004 09:33:00 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema Cc: Multi6 List Subject: Re: Advantages and disadvantages of using CB64 type of identifiers 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.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 Christian Huitema wrote: > First, I don't believe in arguments such as "this is not worse than what > we did in the past" when it comes to security and privacy. We should be > on a path to improvement, not a soft descent into complacency. Second, > having a unique 64 bit identifier in the addresses is actually worse > than the current situation in either IPv4 or IPv6. Agreed. > The current IPv6 practice is to have the 64 bit identifier be either an > IEEE 802 identifier (default) or a random number (temporary addresses, > SEND). When a host is multi-homed through several interfaces, the > different identifiers are used on different interfaces. When a host > configures addresses from multiple prefixes on the same interface, the > 802 identifier will often be the same, but the random identifiers will > be different. The current ND spec allows for using the same identifier > with different prefixes, but it certainly does not mandate it. Right. I believe "does not mandate same interface identifier" part should be our guideline in multi6 too. (I think we heard an argument here a while back that while privacy is good to have, it should not be mandatory and managers should be able to choose whether they use the same or different interface identifier. But on the other hand, if we choose a multi6 mechanism that mandates the same interface ID to be used, then that choice is taken away from the managers: they can either give up multihoming or privacy.) --Jari From owner-multi6@ops.ietf.org Mon Jul 5 02:49: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 CAA10185 for ; Mon, 5 Jul 2004 02:49:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhNHl-000IBU-Uz for multi6-data@psg.com; Mon, 05 Jul 2004 06:49:05 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhNHl-000IBF-1N for multi6@ops.ietf.org; Mon, 05 Jul 2004 06:49:05 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 006508983B; Mon, 5 Jul 2004 09:49:03 +0300 (EEST) Message-ID: <40E8F8C0.3040609@piuha.net> Date: Mon, 05 Jul 2004 09:44:16 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: Multi6 List , Iljitsch van Beijnum Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> In-Reply-To: <40E7CAE6.5060503@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.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 I did not realize we were already in the vote-for-the-solution stage. Anyway, I would be OK with the use of HIP as the solution (or as some component or upgrade path of another solution). I do agree with Iljitsch that a "light weight HIP" approach might be something to think about. I believe HIP with ESP replaced by a flow id (like in some of the other multi6 proposals?) should be doable. --Jari From owner-multi6@ops.ietf.org Mon Jul 5 02:49: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 CAA10203 for ; Mon, 5 Jul 2004 02:49:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhNHq-000IBr-Bz for multi6-data@psg.com; Mon, 05 Jul 2004 06:49:10 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhNHp-000IBd-EQ for multi6@ops.ietf.org; Mon, 05 Jul 2004 06:49:09 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id A76BC8983C; Mon, 5 Jul 2004 09:49:08 +0300 (EEST) Message-ID: <40E8F8C4.8040804@piuha.net> Date: Mon, 05 Jul 2004 09:44:20 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Cc: Multi6 List Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <778E1EDC-CDA1-11D8-9011-000A95CD987A@muada.com> In-Reply-To: <778E1EDC-CDA1-11D8-9011-000A95CD987A@muada.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.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 Iljitsch van Beijnum wrote: > Unless I'm mistaken HIP is still work in progress so that doesn't help. Is your intent to choose the multi6 protocol from only those solution candidates which have already been defined and completed? Please point me to the RFCs ;-) --Jari From owner-multi6@ops.ietf.org Mon Jul 5 04:33: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 EAA14457 for ; Mon, 5 Jul 2004 04:33:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhOtL-0003Kx-Vv for multi6-data@psg.com; Mon, 05 Jul 2004 08:31:59 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhOtI-0003KW-7A for multi6@ops.ietf.org; Mon, 05 Jul 2004 08:31:56 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i658VsGP044032; Mon, 5 Jul 2004 08:31:55 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i658Vsbh218152; Mon, 5 Jul 2004 10:31:54 +0200 Received: from zurich.ibm.com (sig-9-145-175-28.de.ibm.com [9.145.175.28]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA37428; Mon, 5 Jul 2004 10:31:53 +0200 Message-ID: <40E911CC.5070703@zurich.ibm.com> Date: Mon, 05 Jul 2004 10:31:08 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: jari.arkko@piuha.net CC: Christian Huitema , Multi6 List Subject: Re: Advantages and disadvantages of using CB64 type of identifiers References: <40E8F61C.90200@piuha.net> In-Reply-To: <40E8F61C.90200@piuha.net> 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.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 Jari Arkko wrote: ... > But on the other hand, if we choose a multi6 > mechanism that mandates the same interface ID to be used, then > that choice is taken away from the managers: they can either > give up multihoming or privacy.) Let's be clear that all they are giving up is the small amount of privacy that is optionally available in IPv6 by using temporary values in the IID. They are not giving up privacy in any general sense, which is mainly an applications layer issue. We have to be very careful about this to avoid any risk of misinformed urban legends about multi6 and privacy. If multi6, for example, extends the scope of a temporary IID from one to several interfaces or even from one to several sessions, we don't have a privacy problem. If it *only* works with an Ethernet- derived IID, we might have a problem. Brian From owner-multi6@ops.ietf.org Mon Jul 5 04:37:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14620 for ; Mon, 5 Jul 2004 04:37:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhOyO-0003nK-5u for multi6-data@psg.com; Mon, 05 Jul 2004 08:37:12 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhOyN-0003n6-60 for multi6@ops.ietf.org; Mon, 05 Jul 2004 08:37:11 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i658cQ2r043395; Mon, 5 Jul 2004 10:38:29 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7ACCED29-CE5E-11D8-B0FB-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Advantages and disadvantages of using CB64 type of identifiers Date: Mon, 5 Jul 2004 10:36:58 +0200 To: "Christian Huitema" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 5-jul-04, at 8:12, Christian Huitema wrote: > In IPv4, the addresses are often dynamically affected; Don't forget we're talking about SITE multihoming. Current multihoming requires registration in various whois databases. I don't see how something equivalent for a multi6 solution would be problematic. > When a host > configures addresses from multiple prefixes on the same interface, the > 802 identifier will often be the same, but the random identifiers will > be different. This is true for SEND, but not necessarily so for RFC 3041. The only implementation of RFC 3041 that I've worked with (Windows XP) uses the same random identifier for all advertised prefixes. From owner-multi6@ops.ietf.org Mon Jul 5 04:40: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 EAA14724 for ; Mon, 5 Jul 2004 04:40:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhP1V-00047m-0p for multi6-data@psg.com; Mon, 05 Jul 2004 08:40:25 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhP1T-000477-O2 for multi6@ops.ietf.org; Mon, 05 Jul 2004 08:40:24 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i658eHgB044600; Mon, 5 Jul 2004 08:40:17 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i658eGMS186498; Mon, 5 Jul 2004 10:40:16 +0200 Received: from zurich.ibm.com (sig-9-145-175-28.de.ibm.com [9.145.175.28]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA73302; Mon, 5 Jul 2004 10:40:14 +0200 Message-ID: <40E913C2.2010608@zurich.ibm.com> Date: Mon, 05 Jul 2004 10:39:30 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: jari.arkko@piuha.net CC: Iljitsch van Beijnum , Multi6 List Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <778E1EDC-CDA1-11D8-9011-000A95CD987A@muada.com> <40E8F8C4.8040804@piuha.net> In-Reply-To: <40E8F8C4.8040804@piuha.net> 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.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 Jari, (This also responds to your other message.) We're not voting on solutions; my question was about dependencies. Building on an undeployed dependency is a serious decision for any WG to take, especially one in the Operations Area. Brian Jari Arkko wrote: > Iljitsch van Beijnum wrote: > >> Unless I'm mistaken HIP is still work in progress so that doesn't help. > > > Is your intent to choose the multi6 protocol from only those > solution candidates which have already been defined and > completed? Please point me to the RFCs ;-) > > --Jari > From owner-multi6@ops.ietf.org Mon Jul 5 06:03: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 GAA17668 for ; Mon, 5 Jul 2004 06:03:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhQIn-000CAR-7B for multi6-data@psg.com; Mon, 05 Jul 2004 10:02:21 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhQIm-000CAA-CG for multi6@ops.ietf.org; Mon, 05 Jul 2004 10:02:20 +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 i65A2BJ6020613; Mon, 5 Jul 2004 03:02:11 -0700 (PDT) Received: from localhost (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 i65A26213347; Mon, 5 Jul 2004 12:02:06 +0200 (MEST) Date: Mon, 5 Jul 2004 02:13:36 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] To: Iljitsch van Beijnum Cc: Brian E Carpenter , Multi6 List In-Reply-To: "Your message with ID" <778E1EDC-CDA1-11D8-9011-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.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 > > Question to the WG: given the current state of HIP, do we > > want to consider dependency on HIP as > > > a) acceptable > > b) unacceptable? > > Unless I'm mistaken HIP is still work in progress so that doesn't help. > Apart from that I have two concerns: the identifier space is flat, > which can create problems such as with referrals, and HIP as it is > today requires the use of IPsec, which adds processing and bandwidth > overhead whether or not this is desired or appropriate for a certain > communication session. > > This leads me to believe that using HIP as-is isn't a very good idea > for multi6, but it's certainly conceivable that a good multihoming > solution could be created based largely on HIP. Agree fully. HIP does provide worked out pieces for some of the components that might be needed, hence I certainly look at it very closely. But for the two technical reasons Iljitsch mentions, I don't think HIP as currently specified fits what we need. I want a multihoming solution that can allow existing applications to do referrals, and I don't want to require that every packet be encrypted. Erik Erik From owner-multi6@ops.ietf.org Mon Jul 5 06:03: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 GAA17669 for ; Mon, 5 Jul 2004 06:03:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhQIK-000C7z-Im for multi6-data@psg.com; Mon, 05 Jul 2004 10:01:52 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhQIJ-000C7j-ML for multi6@ops.ietf.org; Mon, 05 Jul 2004 10:01:51 +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 i65A1jJ6020467; Mon, 5 Jul 2004 03:01:46 -0700 (PDT) Received: from localhost (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 i65A1e213326; Mon, 5 Jul 2004 12:01:41 +0200 (MEST) Date: Mon, 5 Jul 2004 01:49:47 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: 2nd part Re: revision of architecture draft is now published To: Geoff Huston Cc: marcelo bagnulo braun , multi6@ops.ietf.org In-Reply-To: "Your message with ID" <6.0.1.1.2.20040703080325.02123e38@localhost> 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.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 > What I was attempting to point out is that packet header rewriting by > _remote_ network elements is effectively a description of a session > hijacking technique. In order to allow locator rewriting in a manner that > is resilient to hijacking there needs to be some element of > visible authorization of the locator substitution. A session hijack is an > unauthorized and undetected rewriting of packet headers, while a path > switch is in effect a authorized rewrite of the packet headers. If this is > performed within the host then the authority issues are somewhat different > than when such a header rewrite is performed at some point in the network > path. This is a discussion comment - I don't think it has any impact on the text that Marcelo suggested for the architecture draft. You don't necessarily need to authorize the locator rewriting itself. The constraintis that you need to verify that the use of the new locator is propertly authenticated and authorized. One way to perform this without authorizing the routers is to treat the locator rewritten by the router as a hint (due to reachability or policy) to use a different locator and have the endpoints do their e2e handshake before they take action on the hint. Erik From owner-multi6@ops.ietf.org Mon Jul 5 06:03: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 GAA17705 for ; Mon, 5 Jul 2004 06:03:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhQIr-000CB1-QK for multi6-data@psg.com; Mon, 05 Jul 2004 10:02:25 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhQIq-000CAj-Os for multi6@ops.ietf.org; Mon, 05 Jul 2004 10:02:24 +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 i65A2K0R024748; Mon, 5 Jul 2004 03:02:21 -0700 (PDT) Received: from localhost (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 i65A2E213353; Mon, 5 Jul 2004 12:02:14 +0200 (MEST) Date: Mon, 5 Jul 2004 02:41:18 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Advantages and disadvantages of using CB64 type of identifiers To: Christian Huitema Cc: Erik Nordmark , marcelo bagnulo braun , 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.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 > There are two issues: catalog attacks and privacy implications. I have > already expressed my reservations about the privacy effects of having > unique identifiers in addresses. I would certainly not recommend that my > company ships anything like that. We definitely need to take the privacy concerns into account. But those concerns might imply the need to change the identifier periodically, for instance every 24 hours, for some type of communication such as web browsing client. If we need that, the same approach can be used when the prefixes change without requiring that the IID is different for every prefix. > You do not need to compute 2^64 keys to start having an effect. Suppose > that there are N users in the system, and that the bad guys have > computed a catalog of M keys. The average number of hits that a catalog > of size N will achieve is approximately NxM/2^64. There are currently at > least 500M Internet users, it is reasonable to expect some growth, so we > can set N to about 1 billion -- 2^30. This means you need M=2^34 to get > at least one hit. That is probably less than a Terabyte of data, i.e. > pretty soon a single hard disk. But how would an attacker make use of these precompleted keys? A possibility is that the attacker knows that all hosts connect to some well-known http server and the attacker launches a pre-meditated attack against that web server for all 2^34 prefixes; presumably the attacker would also need to maintain the state at that server until one of the hosts try to connect. If we assume that the server discards the multihoming state after 5 minutes this presumably implies that the attacker would need to send at least one packet per identity every 5 minutes i.e. about 50 million packets per second. And if not every host on the planet connects to a single server then this isn't sufficient to impact even one host on average. To use the keys to lauch an attack against communication in progress the attacker would need to predict when one of the hosts for which it has a key would communicate with another host with a particular IP address. And solution which use some context ID would make it even harder for off-path attackers to take advantage of the keys they've gathered. > Everybody should be convinced that, when it comes to cryptography, 2^64 > is actually a small number. SEND alleviates this risk by > cryptographically link a public key to the entire 128 bits of the > address. This is NOT overkill. For crypto in general, I agree. But I'm not convinced it is required to require the inclusion the prefix in a CB64 scheme. The hash extension in the send-cga spec is probably a better approach to make it harder to brute force CGAs. Erik From owner-multi6@ops.ietf.org Mon Jul 5 09:27: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 JAA26107 for ; Mon, 5 Jul 2004 09:27:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhTTc-0005F4-IV for multi6-data@psg.com; Mon, 05 Jul 2004 13:25:44 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhTTL-0005Cc-T7 for multi6@ops.ietf.org; Mon, 05 Jul 2004 13:25:28 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A8E8339639; Mon, 5 Jul 2004 15:25:26 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 91D3939623; Mon, 5 Jul 2004 15:25:26 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: "Multi6 List" , "Erik Nordmark" From: marcelo bagnulo braun Subject: Re: Advantages and disadvantages of using CB64 type of identifiers Date: Mon, 5 Jul 2004 15:26:33 +0200 To: "Christian Huitema" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: quoted-printable El 05/07/2004, a las 8:12, Christian Huitema escribi=F3: > >> i don't fully understand why do you think that having an identifier = in >> the address is worse than current IPv4 situation (where the id and >> locator are one, and multihomed sites have a single address) or the >> current IPv6 situation (i guess that something similar to privacy >> extensions could be achieved by periodically creating new keys hence >> new identifiers) > > First, I don't believe in arguments such as "this is not worse than=20 > what > we did in the past" when it comes to security and privacy. We should = be > on a path to improvement, not a soft descent into complacency. imho it is not the goal of multi6 to improve current security. i do agree that if it is possible to provide an enhanced security, it=20 would be nice. But i don't see the fact that a solution does not improve current=20 security as a compelling argument to discard a solution > Second, > having a unique 64 bit identifier in the addresses is actually worse > than the current situation in either IPv4 or IPv6. > > In IPv4, the addresses are often dynamically affected; it is possible, > if a site manager so chooses, to give nodes a different address at = each > session. Hosts using dial-up connections receive new addresses for = each > connection. Hosts using broadband connections often receive new > addresses every 24 hours. When a host is multi-homed to several > networks, it will indeed receive different IPv4 addresses on each of > these networks. > The current IPv6 practice is to have the 64 bit identifier be either = an > IEEE 802 identifier (default) or a random number (temporary addresses, > SEND). When a host is multi-homed through several interfaces, the > different identifiers are used on different interfaces. When a host > configures addresses from multiple prefixes on the same interface, the > 802 identifier will often be the same, but the random identifiers will > be different. The current ND spec allows for using the same identifier > with different prefixes, but it certainly does not mandate it. > Do you think that generating a new identifier every day would do the=20 trick? i mean it would be possible, as Erik mentions, to create a new crypto=20 based id every day, i guess regards, marcelo > -- Christian Huitema > From owner-multi6@ops.ietf.org Mon Jul 5 09:28:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26125 for ; Mon, 5 Jul 2004 09:28:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhTVn-0005QF-Ap for multi6-data@psg.com; Mon, 05 Jul 2004 13:27:59 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhTVm-0005Pn-6s for multi6@ops.ietf.org; Mon, 05 Jul 2004 13:27:58 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7338D395D2; Mon, 5 Jul 2004 15:27:57 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 59378395A0; Mon, 5 Jul 2004 15:27:57 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <48A54B4B-CE87-11D8-A131-000D93ACD0FE@ing.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: "Brian E Carpenter" , "Multi6 List" , "Erik Nordmark" From: marcelo bagnulo braun Subject: Re: Is 80 bits enough? [Re: Advantages and disadvantages of using CB64 type of identifiers] Date: Mon, 5 Jul 2004 15:29:04 +0200 To: "Christian Huitema" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: quoted-printable El 05/07/2004, a las 8:14, Christian Huitema escribi=F3: > >>> Everybody should be convinced that, when it comes to cryptography, > 2^64 >>> is actually a small number. SEND alleviates this risk by >>> cryptographically link a public key to the entire 128 bits of the >>> address. This is NOT overkill. >> >> But is 2^80 big enough? Omitting the /48 prefix from the crypto would >> avoid the hash changing when rehoming to a different prefix. > > Not really. The 16 bit subnet identifier is not very random in=20 > practice. > In many cases, the value is 0 or 1, and you get only 1 additional bit, > not 16... > Well, i guess this would be the site's responsability to use more=20 creative subnet prefixes, especially if this provides an additional=20 protection to some attacks Bottom line is that with Brian's suggestion the data base will have to=20= consider 2^80 different ids, which imho is a clear improvement to the=20 protection from dictionary attacks. regards, marcelo > -- Christian Huitema > From owner-multi6@ops.ietf.org Mon Jul 5 11:27: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 LAA03238 for ; Mon, 5 Jul 2004 11:27:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhVM0-000Hax-E2 for multi6-data@psg.com; Mon, 05 Jul 2004 15:26:00 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhVLy-000Hae-8a for multi6@ops.ietf.org; Mon, 05 Jul 2004 15:25:58 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i65FPuFA070342; Mon, 5 Jul 2004 15:25:56 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i65FPtMS178650; Mon, 5 Jul 2004 17:25:56 +0200 Received: from zurich.ibm.com (sig-9-145-169-47.de.ibm.com [9.145.169.47]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA43554; Mon, 5 Jul 2004 17:25:54 +0200 Message-ID: <40E972F9.6040501@zurich.ibm.com> Date: Mon, 05 Jul 2004 17:25:45 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: marcelo bagnulo braun CC: Christian Huitema , Multi6 List , Erik Nordmark Subject: Re: Advantages and disadvantages of using CB64 type of identifiers References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: 8bit marcelo bagnulo braun wrote: > > El 05/07/2004, a las 8:12, Christian Huitema escribió: > >> >>> i don't fully understand why do you think that having an identifier in >>> the address is worse than current IPv4 situation (where the id and >>> locator are one, and multihomed sites have a single address) or the >>> current IPv6 situation (i guess that something similar to privacy >>> extensions could be achieved by periodically creating new keys hence >>> new identifiers) >> >> >> First, I don't believe in arguments such as "this is not worse than what >> we did in the past" when it comes to security and privacy. We should be >> on a path to improvement, not a soft descent into complacency. If we were on that track, we would not have just adopted the threats draft as a WG document. > > imho it is not the goal of multi6 to improve current security. Our baseline is "first do no harm", i.e. not create new exposures. > i do agree that if it is possible to provide an enhanced security, it > would be nice. > But i don't see the fact that a solution does not improve current > security as a compelling argument to discard a solution It isn't, but demonstrating that there are no new exposures is proving a negative, which is always hard work. > >> Second, >> having a unique 64 bit identifier in the addresses is actually worse >> than the current situation in either IPv4 or IPv6. For people who believe that such a thing is a privacy issue, yes. But it may or may not be a security issue - that requires threat analysis of a specific solution. >> >> In IPv4, the addresses are often dynamically affected; it is possible, >> if a site manager so chooses, to give nodes a different address at each >> session. Hosts using dial-up connections receive new addresses for each >> connection. Hosts using broadband connections often receive new >> addresses every 24 hours. When a host is multi-homed to several >> networks, it will indeed receive different IPv4 addresses on each of >> these networks. > > >> The current IPv6 practice is to have the 64 bit identifier be either an >> IEEE 802 identifier (default) or a random number (temporary addresses, >> SEND). When a host is multi-homed through several interfaces, the >> different identifiers are used on different interfaces. When a host >> configures addresses from multiple prefixes on the same interface, the >> 802 identifier will often be the same, but the random identifiers will >> be different. The current ND spec allows for using the same identifier >> with different prefixes, but it certainly does not mandate it. >> > > Do you think that generating a new identifier every day would do the trick? It depends what trick you think is needed. If you mean: defeating some spyware that tracks usage of a given IID, then presumably yes. But if you are talking about a specific security attack (for example replay) - I don't know in the abstract. > > i mean it would be possible, as Erik mentions, to create a new crypto > based id every day, i guess Or at whatever frequency you like... every DHCP refresh for example. The question for us is whether such a mechanism would set bounds on multihoming sessions. What happens to TCP sessions that live longer than the IID? Brian From owner-multi6@ops.ietf.org Mon Jul 5 11:41: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 LAA03734 for ; Mon, 5 Jul 2004 11:41:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhVan-000Iye-1k for multi6-data@psg.com; Mon, 05 Jul 2004 15:41:17 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhVae-000IxO-7W for multi6@ops.ietf.org; Mon, 05 Jul 2004 15:41:08 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Mon, 5 Jul 2004 08:40:03 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Jul 2004 08:41:11 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 5 Jul 2004 08:41:05 -0700 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, 5 Jul 2004 08:41:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Advantages and disadvantages of using CB64 type of identifiers Date: Mon, 5 Jul 2004 08:41:08 -0700 Message-ID: Thread-Topic: Advantages and disadvantages of using CB64 type of identifiers thread-index: AcRik6n+pFicWFHESXamn6E6JMwIrgADNQLQ From: "Christian Huitema" To: "marcelo bagnulo braun" Cc: "Multi6 List" , "Erik Nordmark" X-OriginalArrivalTime: 05 Jul 2004 15:41:20.0401 (UTC) FILETIME=[84B8C010:01C462A6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > Do you think that generating a new identifier every day would do the > trick? No, I don't think so. It would break correlation in time, but it would still enable correlation in space, as in "these two locators lead to the same location". That may or may not be a problem for *site* multihoming, but it definitely is a problem for *host* multihoming, e.g. a host with a WiFi and a GPRS connection. Come to think of it, the only way to not disclose these relations to third parties is to (1) make sure that the identifier is not disclosed as part of the IPv6 address and (2) make sure that the identifier is only exchanged over an encrypted channel between the corresponding hosts. -- Christian Huitema From owner-multi6@ops.ietf.org Mon Jul 5 11:41: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 LAA03789 for ; Mon, 5 Jul 2004 11:41:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhVag-000Ixd-I0 for multi6-data@psg.com; Mon, 05 Jul 2004 15:41:10 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhVad-000IxC-OB for multi6@ops.ietf.org; Mon, 05 Jul 2004 15:41:07 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Mon, 5 Jul 2004 08:41:08 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 5 Jul 2004 08:41:11 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 5 Jul 2004 08:41:04 -0700 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, 5 Jul 2004 08:41:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: Advantages and disadvantages of using CB64 type of identifiers Date: Mon, 5 Jul 2004 08:41:07 -0700 Message-ID: Thread-Topic: Advantages and disadvantages of using CB64 type of identifiers thread-index: AcRiazNtC1PHP8msSMaiIWK80/bDMwANRMQQ From: "Christian Huitema" To: "Iljitsch van Beijnum" Cc: "Multi6 List" X-OriginalArrivalTime: 05 Jul 2004 15:41:20.0120 (UTC) FILETIME=[848DDF80:01C462A6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > This is true for SEND, but not necessarily so for RFC 3041. The only > implementation of RFC 3041 that I've worked with (Windows XP) uses the > same random identifier for all advertised prefixes. I guess I need to get that one fixed asap... -- Christian Huitema From owner-multi6@ops.ietf.org Mon Jul 5 16:43: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 QAA16683 for ; Mon, 5 Jul 2004 16:43:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhaHE-000OvP-Vn for multi6-data@psg.com; Mon, 05 Jul 2004 20:41:24 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhaHD-000Ov0-Hf for multi6@ops.ietf.org; Mon, 05 Jul 2004 20:41:24 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i65Kgi2r055496; Mon, 5 Jul 2004 22:42:45 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Advantages and disadvantages of using CB64 type of identifiers Date: Mon, 5 Jul 2004 22:41:19 +0200 To: "Christian Huitema" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 5-jul-04, at 17:41, Christian Huitema wrote: > but it definitely is a problem for *host* multihoming, e.g. a host with > a WiFi and a GPRS connection. So what about a solution like NOID where this information is in the DNS? I don't understand why you find it objectionable that someone would see which two IP addresses belong to the same host. I mean, what does this tell the third party? As I understand it, the reason that RFC 3041 exists is because having a MAC-derived IP address allows a third party to follow a host's movement from one link to another. I can see why people wouldn't want that to happen. But I don't see how disclosure of a fixed relationship between two addresses or prefixes is similar. That is, unless multihoming is combined with some sort of mobility. > Come to think of it, the only way to not disclose these relations to > third parties is to (1) make sure that the identifier is not disclosed > as part of the IPv6 address and (2) make sure that the identifier is > only exchanged over an encrypted channel between the corresponding > hosts. But you pretty much always need to inform the correspondent, and an attacker who can snoop a link will often be in the position to become a correspondent and thus learn the information. If there is no snooping there is no reason for encryption. From owner-multi6@ops.ietf.org Tue Jul 6 03:13: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 DAA25911 for ; Tue, 6 Jul 2004 03:13:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bhk74-000I6I-G9 for multi6-data@psg.com; Tue, 06 Jul 2004 07:11:34 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bhk73-000I60-0K for multi6@ops.ietf.org; Tue, 06 Jul 2004 07:11:33 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i667BWFA117640 for ; Tue, 6 Jul 2004 07:11:32 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i667BV0H278588 for ; Tue, 6 Jul 2004 09:11:31 +0200 Received: from zurich.ibm.com (sig-9-145-169-130.de.ibm.com [9.145.169.130]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA32632 for ; Tue, 6 Jul 2004 09:11:31 +0200 Message-ID: <40EA5099.3030503@zurich.ibm.com> Date: Tue, 06 Jul 2004 09:11:21 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Re: Advantages and disadvantages of using CB64 type of identifiers 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.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 Iljitsch van Beijnum wrote: > On 5-jul-04, at 17:41, Christian Huitema wrote: > >> but it definitely is a problem for *host* multihoming, e.g. a host with >> a WiFi and a GPRS connection. > > > So what about a solution like NOID where this information is in the DNS? > > I don't understand why you find it objectionable that someone would see > which two IP addresses belong to the same host. I mean, what does this > tell the third party? > > As I understand it, the reason that RFC 3041 exists is because having a > MAC-derived IP address allows a third party to follow a host's movement > from one link to another. I can see why people wouldn't want that to > happen. But I don't see how disclosure of a fixed relationship between > two addresses or prefixes is similar. That is, unless multihoming is > combined with some sort of mobility. > >> Come to think of it, the only way to not disclose these relations to >> third parties is to (1) make sure that the identifier is not disclosed >> as part of the IPv6 address and (2) make sure that the identifier is >> only exchanged over an encrypted channel between the corresponding >> hosts. > > > But you pretty much always need to inform the correspondent, and an > attacker who can snoop a link will often be in the position to become a > correspondent and thus learn the information. If there is no snooping > there is no reason for encryption. Also, in the case of referrals, disclosure to a third party is necessary and desirable. In any case, the current state of the Internet is that IP addresses are public knowledge, and we are not under any obligation to change that as part of multi6. Brian From owner-multi6@ops.ietf.org Tue Jul 6 03:15:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25995 for ; Tue, 6 Jul 2004 03:15:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhkAz-000ISM-NH for multi6-data@psg.com; Tue, 06 Jul 2004 07:15:37 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhkAy-000IS4-Kk for multi6@ops.ietf.org; Tue, 06 Jul 2004 07:15:36 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i667FZFA101908 for ; Tue, 6 Jul 2004 07:15:35 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i667FZ0H255762 for ; Tue, 6 Jul 2004 09:15:35 +0200 Received: from zurich.ibm.com (sig-9-145-169-130.de.ibm.com [9.145.169.130]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA39732 for ; Tue, 6 Jul 2004 09:15:34 +0200 Message-ID: <40EA518E.7070502@zurich.ibm.com> Date: Tue, 06 Jul 2004 09:15:26 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Re: Advantages and disadvantages of using CB64 type of identifiers 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.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 Christian Huitema wrote: >>Do you think that generating a new identifier every day would do the >>trick? > > > No, I don't think so. It would break correlation in time, but it would > still enable correlation in space, as in "these two locators lead to the > same location". That may or may not be a problem for *site* multihoming, > but it definitely is a problem for *host* multihoming, e.g. a host with > a WiFi and a GPRS connection. Some might consider it a solution, not a problem. For example I can imagine it helping to meet "911" requirements (an emergency VoIP call arrives via WiFi, but back-tracking to GPRS gives better automatic geolocation). Brian From owner-multi6@ops.ietf.org Tue Jul 6 05:52: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 FAA01655 for ; Tue, 6 Jul 2004 05:52:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhmaR-0009S5-J0 for multi6-data@psg.com; Tue, 06 Jul 2004 09:50:03 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhmaQ-0009RC-6f for multi6@ops.ietf.org; Tue, 06 Jul 2004 09:50:02 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 74CFC4A9E39; Tue, 6 Jul 2004 11:50:01 +0200 (CEST) In-Reply-To: <40E7CAE6.5060503@zurich.ibm.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] Date: Tue, 6 Jul 2004 11:49:48 +0200 To: Brian E Carpenter X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 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 (co-chair hat off) On 2004-07-04, at 11.16, Brian E Carpenter wrote: > Some discussion on this thread refers to dependency on HIP. > > Question to the WG: given the current state of HIP, do we > want to consider dependency on HIP as > > a) acceptable > b) unacceptable? I have always been under the impression that HIP is aiming for experimental. In that case, I think it would be in-appropriate to depend on HIP. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQOp1x6arNKXTPFCVEQKYgACgzud5A+raLfvY5TVUGSK9Ry6w9jYAoJqQ q69P76ZZRHlff5/yJ1ANFNBk =I3sW -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 6 15: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 PAA16675 for ; Tue, 6 Jul 2004 15:40:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhvlK-0006dm-8Y for multi6-data@psg.com; Tue, 06 Jul 2004 19:37:54 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhvlI-0006dD-Mc for multi6@ops.ietf.org; Tue, 06 Jul 2004 19:37:53 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16586; Tue, 6 Jul 2004 15:37:50 -0400 (EDT) Message-Id: <200407061937.PAA16586@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-multihoming-threats-00.txt Date: Tue, 06 Jul 2004 15:37:49 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Threats relating to IPv6 multihoming solutions Author(s) : E. Nordmark Filename : draft-ietf-multi6-multihoming-threats-00.txt Pages : 30 Date : 2004-7-6 This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-threats-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-multihoming-threats-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-ietf-multi6-multihoming-threats-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-7-6152046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-threats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-threats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-6152046.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Tue Jul 6 19:44: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 TAA04471 for ; Tue, 6 Jul 2004 19:44:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BhzaI-000FZL-Pg for multi6-data@psg.com; Tue, 06 Jul 2004 23:42:46 +0000 Received: from [203.50.0.6] (helo=kahuna.telstra.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BhzaG-000FYr-Ew for multi6@ops.ietf.org; Tue, 06 Jul 2004 23:42:45 +0000 Received: from gihz1.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id i66NgXrA062811; Wed, 7 Jul 2004 09:42:34 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <6.0.1.1.2.20040707081922.01d74ec0@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 Date: Wed, 07 Jul 2004 08:20:37 +1000 To: marcelo bagnulo braun From: Geoff Huston Subject: Re: 2nd part Re: revision of architecture draft is now published Cc: multi6@ops.ietf.org In-Reply-To: <2ABC09C2-CAB6-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <2ABC09C2-CAB6-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 (still working through your comments...) - in section 5.3.3 >when considering opportunistic identifiers to initiate the communication. >note that non of the proposals AFAIK, use opportunistic identifiers for >the server side. imho this is very difficult, because, the client side >needs to know the identifier in order to initiate the communication. It >would be possible that the client side would select the servers identity >beforehand, but this may imply collisions if the server is already using >it. imho opportunistic ids are only suitable for clients (if any), but not >for servers. Hi Marcelo, I'm unsure of what you are saying here. Could you describe in a bit more detail the point so that I can understand what changes may be necessary for the draft? thanks, Geoff From owner-multi6@ops.ietf.org Wed Jul 7 02:57: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 CAA26401 for ; Wed, 7 Jul 2004 02:57:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bi6LJ-000JQ6-Ic for multi6-data@psg.com; Wed, 07 Jul 2004 06:55:45 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bi6LI-000JPn-FB for multi6@ops.ietf.org; Wed, 07 Jul 2004 06:55:44 +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 i676tg0R006016 for ; Tue, 6 Jul 2004 23:55:43 -0700 (PDT) Received: from localhost (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 i676tcx14704 for ; Wed, 7 Jul 2004 08:55:39 +0200 (MEST) Date: Tue, 6 Jul 2004 23:55:36 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: I-D ACTION:draft-ylitalo-multi6-wimp-01.txt (Fwd) To: multi6@ops.ietf.org In-Reply-To: "Your message with ID" <200407061937.PAA16519@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.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 >----------------Begin Forwarded Message----------------< Date: Tue, 06 Jul 2004 15:37:22 -0400 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ylitalo-multi6-wimp-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Weak Identifier Multihoming Protocol (WIMP) Author(s) : J. Ylitalo, et al. Filename : draft-ylitalo-multi6-wimp-01.txt Pages : 43 Date : 2004-7-6 Weak Identifier Multihoming Protocol Framework (WIMP-F) is a wedge layer 3.5 framework to be applied with different kind of routable application layer identifiers (AIDs) and layer 3.5 context identifiers (CIDs) presented in Group-F. WIMP-F consists of context establishment and re-addressing exchanges that are protected with one-way hash chains and a technique called as secret splitting. The hash chain protects a host from re-direction attacks, but not directly from an CID or AID theft. The ownerships can be provided in variable ways presented in other Multi6 drafts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ylitalo-multi6-wimp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ylitalo-multi6-wimp-01.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-ylitalo-multi6-wimp-01.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. >----------------End Forwarded Message----------------< From owner-multi6@ops.ietf.org Wed Jul 7 05:11: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 FAA05402 for ; Wed, 7 Jul 2004 05:11:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bi8RF-0008Be-8W for multi6-data@psg.com; Wed, 07 Jul 2004 09:10:01 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bi8RD-0008AG-CD for multi6@ops.ietf.org; Wed, 07 Jul 2004 09:09:59 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7249539E19; Wed, 7 Jul 2004 11:09:58 +0200 (CEST) Received: from [163.117.252.29] (unknown [163.117.252.29]) by smtp01.uc3m.es (Postfix) with ESMTP id B856439E11; Wed, 7 Jul 2004 11:09:56 +0200 (CEST) In-Reply-To: <6.0.1.1.2.20040707081922.01d74ec0@localhost> References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <2ABC09C2-CAB6-11D8-A131-000D93ACD0FE@it.uc3m.es> <6.0.1.1.2.20040707081922.01d74ec0@localhost> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <53E6EA5A-CFF5-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org From: marcelo bagnulo braun Subject: Re: 2nd part Re: revision of architecture draft is now published Date: Wed, 7 Jul 2004 11:09:18 +0200 To: Geoff Huston X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Geoff, sorry for being unclear, El 07/07/2004, a las 0:20, Geoff Huston escribi=F3: > (still working through your comments...) > > - in section 5.3.3 > >> when considering opportunistic identifiers to initiate the=20 >> communication. >> note that non of the proposals AFAIK, use opportunistic identifiers=20= >> for the server side. imho this is very difficult, because, the client=20= >> side needs to know the identifier in order to initiate the=20 >> communication. It would be possible that the client side would select=20= >> the servers identity beforehand, but this may imply collisions if the=20= >> server is already using it. imho opportunistic ids are only suitable=20= >> for clients (if any), but not for servers. > > Hi Marcelo, > > I'm unsure of what you are saying here. Could you describe in a bit=20 > more detail the point so that I can understand what changes may be=20 > necessary for the draft? > In section 5.3.3. it is stated that "If opportunistic identities are used, where the identity is not a fixed discoverable value but one that is generated in the context of a session then additional actions must be performed at session startup. In this case there is still the need for defined locators that are used to establish a session, but then an additional step is required to generate session keys and exchange these values in order to support the identity equivalence of multiple locators within the ensuing session. This may take the form of a capability exchange = and an additional handshake and associated token value exchange within the transport protocol if an in-band approach is being used, or it may take the form of a distinct protocol exchange at the level of = the identity protocol element, performed out-of-band from the transport session." Now, i wonder how such a solution would be, in the case that both=20 initiator and responder use ephemeral ids. The case where the initiator uses ephemeral ids is clear to me, and=20 wimp_v1 is a example of how this would work. However, if the receiver wants to use an ephemeral id, things get less=20= clear (at least to me) In this case, the app at the initiator's end needs to use a stable=20 identifier to indicate the end that it wants to communicate with. It could be possible to say that the apps will try to communicate with=20= a fqdn. If this is the case, i guess that the resolver at the initiators end=20 will have to negotiate with the receiver the ephemeral id that the=20 receiver will use, so that the initiator's resolver can return the=20 ephemeral id back to the app, so that the app can use it to initiate=20 the communication. However, if this is the case, i would say that the=20 fqdn is the identifier really being used for initial contact, perhaps=20 in this scenario we are using two identifiers, the fqdn and the=20 ephemeral one? bottom line is that the receiver always needs a stable identifier that=20= the initiator can refer to, if not the initiator won't be able to=20 indicate the target of the communication. regards, marcelo > thanks, > > Geoff > > > From owner-multi6@ops.ietf.org Wed Jul 7 13:43: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 NAA03461 for ; Wed, 7 Jul 2004 13:43:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiGQr-000EdW-TA for multi6-data@psg.com; Wed, 07 Jul 2004 17:42:09 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiGQp-000EdB-RE for multi6@ops.ietf.org; Wed, 07 Jul 2004 17:42:08 +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 i67Hg1il015072; Wed, 7 Jul 2004 11:42:02 -0600 (MDT) Received: from localhost (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 i67Hftx08899; Wed, 7 Jul 2004 19:41:55 +0200 (MEST) Date: Wed, 7 Jul 2004 10:35:49 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Advantages and disadvantages of using CB64 type of identifiers To: Brian E Carpenter , huitema@windows.microsoft.com Cc: marcelo bagnulo braun , Multi6 List , Erik Nordmark In-Reply-To: "Your message with ID" <40E972F9.6040501@zurich.ibm.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.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 Brian wrote: > > i mean it would be possible, as Erik mentions, to create a new crypto > > based id every day, i guess > > Or at whatever frequency you like... every DHCP refresh for example. > > The question for us is whether such a mechanism would set bounds on > multihoming sessions. What happens to TCP sessions that live longer > than the IID? A reasonable approach would be to apply the RFC 3041 way, but for the identifiers instead of the addresses, that is an identifier would become deprecated and not used for some outbound communication at time T1, but packets to that identifier would be accepted until time T2 >> T1. If you want sessions that survive longer than T2 you'd need to use an identifier that has longer stability. Christian wrote: > No, I don't think so. It would break correlation in time, but it would > still enable correlation in space, as in "these two locators lead to the > same location". That may or may not be a problem for *site* multihoming, > but it definitely is a problem for *host* multihoming, e.g. a host with > a WiFi and a GPRS connection. > > Come to think of it, the only way to not disclose these relations to > third parties is to (1) make sure that the identifier is not disclosed > as part of the IPv6 address and (2) make sure that the identifier is > only exchanged over an encrypted channel between the corresponding > hosts. I guess there is a difference between making the correlation discoverable from a publicly available infrastructure (e.g., the DNS) and requiring that the node, malicious or not, that wants to discover the correlation has to communicate with the host in question. But in any case, to be able to prove to a peer that some communcation can fail over to use different locators, the host will need to disclose the correlation between those locators to the peer. I don't think we can argue that all peers with which a host communications (based on URLs embedded in whatever web pages the host might access, for instance for ad insertion) are uninterested in discovering such correlation. So I don't see how you can have your cake an eat it too; if the host doesn't want the correlation between its locator on WiFi and GPRS to be discoverable then it must not enable multihoming support which allows rehoming between those locators. Erik From owner-multi6@ops.ietf.org Wed Jul 7 15:40:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13029 for ; Wed, 7 Jul 2004 15:40:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiIGZ-0006bO-9n for multi6-data@psg.com; Wed, 07 Jul 2004 19:39:39 +0000 Received: from [216.140.57.248] (helo=ausspam02.ixc-comm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiIGX-0006ak-Vs for multi6@ops.ietf.org; Wed, 07 Jul 2004 19:39:38 +0000 Received: from mail pickup service by ausspam02.ixc-comm.com with Microsoft SMTPSVC; Wed, 7 Jul 2004 13:24:21 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by ausspam02.ixc-comm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 6 Jul 2004 19:03:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhwIy-0001Wh-6f; Tue, 06 Jul 2004 16:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhvlI-0002XV-69 for i-d-announce@megatron.ietf.org; Tue, 06 Jul 2004 15:37:52 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16586; Tue, 6 Jul 2004 15:37:50 -0400 (EDT) Message-Id: <200407061937.PAA16586@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 06 Jul 2004 15:37:49 -0400 CC: multi6@ops.ietf.org Subject: I-D ACTION:draft-ietf-multi6-multihoming-threats-00.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , X-OriginalArrivalTime: 07 Jul 2004 00:03:23.0484 (UTC) FILETIME=[D1E431C0:01C463B5] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Threats relating to IPv6 multihoming solutions Author(s) : E. Nordmark Filename : draft-ietf-multi6-multihoming-threats-00.txt Pages : 30 Date : 2004-7-6 This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-threats-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-multihoming-threats-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-ietf-multi6-multihoming-threats-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-7-6152046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-threats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-threats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-6152046.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- From owner-multi6@ops.ietf.org Wed Jul 7 17:27: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 RAA18352 for ; Wed, 7 Jul 2004 17:27:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiJvl-000Pk7-7X for multi6-data@psg.com; Wed, 07 Jul 2004 21:26:17 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiJvi-000PjI-Mt; Wed, 07 Jul 2004 21:26:15 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i67LP82r006561; Wed, 7 Jul 2004 23:25:08 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <6.1.1.1.2.20040707133134.059e6df0@mira-sjc5-b.cisco.com> References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <6.1.1.1.2.20040707133134.059e6df0@mira-sjc5-b.cisco.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 , Pekka Savola From: Iljitsch van Beijnum Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Date: Wed, 7 Jul 2004 23:23:44 +0200 To: Fred Baker X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 7-jul-04, at 22:39, Fred Baker wrote: > When a company changes providers, it is common to institute an > overlap period, during which it is served by both providers. By > definition, the network is multihomed during such a period. While > this document is not about multihoming per se, problems can arise as > a result of ingress filtering policies applied by the upstream > provider or one of its upstream providers, so the user of this > document need also be cognizant of these issues. This is discussed > in detail, and approaches to dealing with it are described, in > [RFC2827] and [RFC3704]. These references outline ingress filtering, but there is only about half a page in the second one about how to route traffic with certain addresses to a certain provider, and this half page provides very little actual guidance. A few paragraphs along the lines of "ask one ISP to temporarily accept packets with the other's addresses and use that one for outgoing traffic or use policy routing to match ISPs to the source addresses in outgoing packets, or if these approaches aren't possible, implement a flag-day type of transition" would be very helpful, I think. From owner-multi6@ops.ietf.org Wed Jul 7 17:47: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 RAA19098 for ; Wed, 7 Jul 2004 17:47:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiKFs-00046I-To for multi6-data@psg.com; Wed, 07 Jul 2004 21:47:04 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiKFr-00045n-R5 for multi6@ops.ietf.org; Wed, 07 Jul 2004 21:47:04 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i67LmP2r006917; Wed, 7 Jul 2004 23:48:25 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2E074F83-D05F-11D8-A513-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Advantages and disadvantages of using CB64 type of identifiers Date: Wed, 7 Jul 2004 23:47:02 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 7-jul-04, at 19:35, Erik Nordmark wrote: >> The question for us is whether such a mechanism would set bounds on >> multihoming sessions. What happens to TCP sessions that live longer >> than the IID? > A reasonable approach would be to apply the RFC 3041 way, but for > the identifiers instead of the addresses, that is an identifier > would become deprecated and not used for some outbound communication > at time T1, but packets to that identifier would be accepted until > time T2 >> > T1. Actually this is more an RFC 246x thing. > I guess there is a difference between making the correlation > discoverable > from a publicly available infrastructure (e.g., the DNS) and requiring > that the node, malicious or not, that wants to discover the correlation > has to communicate with the host in question. > But in any case, to be able to prove to a peer that some communcation > can fail over to use different locators, the host will need to disclose > the correlation between those locators to the peer. :-) Note that there are very different requirements for servers, clients and participants in peer-to-peer communication. I'm going to assume that there are few privacy issues for servers as they need to be known to do their job. For clients there are privacy issues but they don't need long-lived ids so it's not too bad. For peer-to-peer participants it's harder because they can't switch ids as easily. Also, for clients it should be possible to hide any additional locators and just send over auth info. Then, if there is loss of connectivity, the client switches locators and says "hi, it's me, remember my hash chain?" or something similar. Obviously this way it's still fairly trivial for an adversarial correspondent to find out additional locators. From owner-multi6@ops.ietf.org Thu Jul 8 00:31:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11573 for ; Thu, 8 Jul 2004 00:31:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiQXs-000Eir-NB for multi6-data@psg.com; Thu, 08 Jul 2004 04:30:04 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiQXq-000Eh4-5H; Thu, 08 Jul 2004 04:30:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i684Tiq18246; Thu, 8 Jul 2004 07:29:44 +0300 Date: Thu, 8 Jul 2004 07:29:43 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: Iljitsch van Beijnum , Ralph Droms , , Eliot Lear , Multi6 Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) In-Reply-To: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.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.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk On Wed, 7 Jul 2004, Fred Baker wrote: > >A few paragraphs along the lines of "ask one ISP to temporarily accept > >packets with the other's addresses and use that one for outgoing traffic > >or use policy routing to match ISPs to the source addresses in outgoing > >packets, or if these approaches aren't possible, implement a flag-day type > >of transition" would be very helpful, I think. > > In a word, no. [...] A possible compromise here could be putting RFC3704 in as a *normative* reference (btw, some of those other ones might be as well because they're required for understanding), implying that it's a MUST read.. which could be interpreted as not having to summarize or repeats its contents here. -- 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 Jul 8 04:06: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 EAA05350 for ; Thu, 8 Jul 2004 04:06:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiTuW-0009dq-Hj for multi6-data@psg.com; Thu, 08 Jul 2004 08:05:40 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiLJJ-000FzS-Sm; Wed, 07 Jul 2004 22:54:41 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2004 15:55:42 -0700 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i67MscgI023629; Wed, 7 Jul 2004 15:54:39 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVD86035; Wed, 7 Jul 2004 15:53:27 -0700 (PDT) Message-Id: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 07 Jul 2004 15:27:34 -0700 To: Iljitsch van Beijnum From: Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Cc: Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 , Pekka Savola In-Reply-To: References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> <6.1.1.1.2.20040707133134.059e6df0@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 At 11:23 PM 07/07/04 +0200, Iljitsch van Beijnum wrote: >On 7-jul-04, at 22:39, Fred Baker wrote: >>When a company changes providers, it is common to institute an overlap >>period, during which it is served by both providers. By definition, the >>network is multihomed during such a period. While this document is not >>about multihoming per se, problems can arise as a result of ingress >>filtering policies applied by the upstream provider or one of its >>upstream providers, so the user of this document need also be cognizant >>of these issues. This is discussed in detail, and approaches to dealing >>with it are described, in [RFC2827] and [RFC3704]. > >These references outline ingress filtering, but there is only about half a >page in the second one about how to route traffic with certain addresses >to a certain provider, and this half page provides very little actual guidance. > >A few paragraphs along the lines of "ask one ISP to temporarily accept >packets with the other's addresses and use that one for outgoing traffic >or use policy routing to match ISPs to the source addresses in outgoing >packets, or if these approaches aren't possible, implement a flag-day type >of transition" would be very helpful, I think. In a word, no. There was a serious attempt last fall to turn this document, which is about "how to renumber a network", into "how to configure ingress filtering and route traffic within multihomed networks". the problem is, there exist a lot of multihomed networks that are not periodically renumbered, and the issues of multihoming apply in them, and (believe it or not) not all networks that get renumbered are multihomed. Yes, a network might be multihomed temporarily while being renumbered, but that doesn't make renumbering==multihoming. They are in fact very different discussions. In the interest of ever getting a chance to actually do anything useful with "how to renumber a network", Pekka and I put the entire BCP 38 discussion into a separate document, which is now RFC 3704. This working group looked at that document, decided it was sufficient to describe those issues, and published it as an RFC. If it is not sufficient, fixing RFC 3704 is the task of the day, and should be part of the recharter effort that is currently under discussion. Alternatively, Multi6 could produce something useful on the topic. May I suggest that, by 12 July, you post an updated version of RFC 3704? From owner-multi6@ops.ietf.org Thu Jul 8 04:06:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05368 for ; Thu, 8 Jul 2004 04:06:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiTty-0009YS-Qd for multi6-data@psg.com; Thu, 08 Jul 2004 08:05:06 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiJFt-000H96-He; Wed, 07 Jul 2004 20:43:01 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2004 13:43:33 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i67Kgv4N006532; Wed, 7 Jul 2004 13:42:58 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVD72928; Wed, 7 Jul 2004 13:41:46 -0700 (PDT) Message-Id: <6.1.1.1.2.20040707133134.059e6df0@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Wed, 07 Jul 2004 13:39:23 -0700 To: Iljitsch van Beijnum From: Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Cc: Pekka Savola , Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 In-Reply-To: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> References: <5159CC99-C2FE-11D8-96AB-000A95CD987A@muada.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk The working group last call has closed, and the only issue that I saw was the issue of ingress filtering affecting a temporarily homed network. Personally, I'm not sure that was not covered in section 3.3: 3.3 Ingress Filtering An important consideration in Section 2.3, in the case where the network being renumbered is connected to an external provider, the network's ingress filtering policy and its provider's ingress filtering policy. Both the network firewall's ingress filter and the provider's ingress filter on the access link to the network should be configured to prevent attacks that use source address spoofing. Ingress filtering is considered in detail in "Ingress Filtering for Multihomed Networks" [RFC3704]. but I have added the following to the introduction: 1.4 Multihoming Issues In addition to the considerations presented, the operational matters of multihoming may need to be addressed. Networks are generally renumbered for one of three reasons: the network itself is changing its addressing policy and must renumber to implement the new policy (for example, a company has been acquired and is changing addresses to those used by its new owner), an upstream provider has changed its prefixes and its customers are forced to do so at the same time, or a company is changing providers and must perforce use addresses assigned by the new provider. The third case is common. When a company changes providers, it is common to institute an overlap period, during which it is served by both providers. By definition, the network is multihomed during such a period. While this document is not about multihoming per se, problems can arise as a result of ingress filtering policies applied by the upstream provider or one of its upstream providers, so the user of this document need also be cognizant of these issues. This is discussed in detail, and approaches to dealing with it are described, in [RFC2827] and [RFC3704]. If this is deemed a sufficient change, I think the documents at ftp://ftpeng.cisco.com/fred/v6ops/renumber.html ftp://ftpeng.cisco.com/fred/v6ops/renumber.txt ftp://ftpeng.cisco.com/fred/v6ops/renumber.xml may be considered responsive to the WG last call. I will put in a note to internet-drafts to post them on Monday barring further comment, and request the chairs to forward them to the IESG. From owner-multi6@ops.ietf.org Thu Jul 8 04:06: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 EAA05386 for ; Thu, 8 Jul 2004 04:06:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiTuy-0009hs-Hp for multi6-data@psg.com; Thu, 08 Jul 2004 08:06:08 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiThn-00087G-S5; Thu, 08 Jul 2004 07:52:32 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 08 Jul 2004 00:58:54 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i687qSgI027660; Thu, 8 Jul 2004 00:52:29 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVE14751; Thu, 8 Jul 2004 00:51:17 -0700 (PDT) Message-Id: <6.1.1.1.2.20040708004104.0593ddb8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 08 Jul 2004 00:41:47 -0700 To: Pekka Savola From: Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Cc: Iljitsch van Beijnum , Ralph Droms , , Eliot Lear , Multi6 In-Reply-To: References: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 At 07:29 AM 07/08/04 +0300, Pekka Savola wrote: >A possible compromise here could be putting RFC3704 in as a *normative* >reference (btw, some of those other ones might be as well because they're >required for understanding), implying that it's a MUST read.. which could >be interpreted as not having to summarize or repeats its contents here. I'm perfectly willing to do that. Will that address the issues? Glancing through, I at the moment have all references as informational. It occurs to me that this is probably not right. Would you suggest the following, or would you also make others normative? There is probably an argument for making all or almost all of the RFCs normative, but my sense is not to take quite that expansive of a view. [Clausewitz] von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, "On War, Chapter VII, 'Friction in War'", June 1989. [I-D.ietf-dhc-dhcpv6-opt-prefix-delegation] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in progress), October 2003. [I-D.ietf-dnsop-ipv6-dns-issues] Durand, A., Ihren, J. and P. Savola, "Operational Considerations and Issues with IPv6 DNS", draft-ietf-dnsop-ipv6-dns-issues-07 (work in progress), May 2004. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996. [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000. [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. From owner-multi6@ops.ietf.org Thu Jul 8 06:03: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 GAA10511 for ; Thu, 8 Jul 2004 06:03:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiViC-000MAi-Nj for multi6-data@psg.com; Thu, 08 Jul 2004 10:01:04 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiVi8-000MA8-9b for multi6@ops.ietf.org; Thu, 08 Jul 2004 10:01:01 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i68A0cGP079996; Thu, 8 Jul 2004 10:00:38 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i68A0bMj174178; Thu, 8 Jul 2004 12:00:38 +0200 Received: from zurich.ibm.com (sig-9-145-174-72.de.ibm.com [9.145.174.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA59372; Thu, 8 Jul 2004 12:00:35 +0200 Message-ID: <40ED1B39.5050204@zurich.ibm.com> Date: Thu, 08 Jul 2004 12:00:25 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Fred Baker CC: Pekka Savola , Iljitsch van Beijnum , Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) References: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> <6.1.1.1.2.20040708004104.0593ddb8@mira-sjc5-b.cisco.com> In-Reply-To: <6.1.1.1.2.20040708004104.0593ddb8@mira-sjc5-b.cisco.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.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 I's suggest that at this point in the discussion you can drop the cross-posting to multi6. While you are tweaking, it might be worth adding a note that the eventual multi6 solution(s) may add new issues to the renumbering recipe, or alternatively may simplify it. Brian Fred Baker wrote: > At 07:29 AM 07/08/04 +0300, Pekka Savola wrote: > >> A possible compromise here could be putting RFC3704 in as a >> *normative* reference (btw, some of those other ones might be as well >> because they're required for understanding), implying that it's a MUST >> read.. which could be interpreted as not having to summarize or >> repeats its contents here. > > > I'm perfectly willing to do that. Will that address the issues? > > Glancing through, I at the moment have all references as informational. > It occurs to me that this is probably not right. Would you suggest the > following, or would you also make others normative? There is probably an > argument for making all or almost all of the RFCs normative, but my > sense is not to take quite that expansive of a view. > > > > > > > > > > > > > > > > > > > > > > > include="reference.I-D.ietf-dhc-dhcpv6-opt-prefix-delegation"?> > include="reference.I-D.ietf-dnsop-ipv6-dns-issues"?> > > > [Clausewitz] > von Clausewitz, C., Howard, M., Paret, P. and D. Brodie, > "On War, Chapter VII, 'Friction in War'", June 1989. > > [I-D.ietf-dhc-dhcpv6-opt-prefix-delegation] > Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", > draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in > progress), October 2003. > > [I-D.ietf-dnsop-ipv6-dns-issues] > Durand, A., Ihren, J. and P. Savola, "Operational > Considerations and Issues with IPv6 DNS", > draft-ietf-dnsop-ipv6-dns-issues-07 (work in progress), > May 2004. > > [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", > STD 13, RFC 1034, November 1987. > > [RFC1035] Mockapetris, P., "Domain names - implementation and > specification", STD 13, RFC 1035, November 1987. > > [RFC1305] Mills, D., "Network Time Protocol (Version 3) > Specification, Implementation", RFC 1305, March 1992. > > [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, > August 1996. > > [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone > Changes (DNS NOTIFY)", RFC 1996, August 1996. > > [RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, > January 1997. > > [RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic > Updates in the Domain Name System (DNS UPDATE)", RFC 2136, > April 1997. > > [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 > (IPv6) Specification", RFC 2460, December 1998. > > [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor > Discovery for IP Version 6 (IPv6)", RFC 2461, December > 1998. > > [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address > Autoconfiguration", RFC 2462, December 1998. > > [RFC2535] Eastlake, D., "Domain Name System Security Extensions", > RFC 2535, March 1999. > > [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: > Defeating Denial of Service Attacks which employ IP Source > Address Spoofing", BCP 38, RFC 2827, May 2000. > > [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. > Wellington, "Secret Key Transaction Authentication for DNS > (TSIG)", RFC 2845, May 2000. > > [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( > SIG(0)s)", RFC 2931, September 2000. > > [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic > Update", RFC 3007, November 2000. > > [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address > Allocations to Sites", RFC 3177, September 2001. > > [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and > M. Carney, "Dynamic Host Configuration Protocol for IPv6 > (DHCPv6)", RFC 3315, July 2003. > > [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed > Networks", BCP 84, RFC 3704, March 2004. > > > From owner-multi6@ops.ietf.org Thu Jul 8 11:18: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 LAA00854 for ; Thu, 8 Jul 2004 11:18:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Biada-0002DE-5w for multi6-data@psg.com; Thu, 08 Jul 2004 15:16:38 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiadY-0002Cs-9p for multi6@ops.ietf.org; Thu, 08 Jul 2004 15:16:37 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00362; Thu, 8 Jul 2004 11:16:32 -0400 (EDT) Message-Id: <200407081516.LAA00362@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-multihoming-threats-00.txt Date: Thu, 08 Jul 2004 11:16:32 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : Threats relating to IPv6 multihoming solutions Author(s) : E. Nordmark Filename : draft-ietf-multi6-multihoming-threats-00.txt Pages : 30 Date : 2004-7-6 This document lists security threats related to IPv6 multihoming. Multihoming can introduce new opportunities to redirect packets to different, unintended IP addresses. The intent is to look at how IPv6 multihoming solutions might make the Internet less secure than the current Internet, without studying any proposed solution but instead looking at threats that are inherent in the problem itself. The threats in this document build upon the threats discovered and discussed as part of the Mobile IPv6 work. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-multihoming-threats-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-multihoming-threats-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-ietf-multi6-multihoming-threats-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-7-6152046.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-multihoming-threats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-multihoming-threats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-6152046.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Thu Jul 8 15:47: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 PAA23647 for ; Thu, 8 Jul 2004 15:47:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BieqT-000CiU-UU for multi6-data@psg.com; Thu, 08 Jul 2004 19:46:13 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BieqS-000CiH-US for multi6@ops.ietf.org; Thu, 08 Jul 2004 19:46:13 +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 i68Jk9il006300; Thu, 8 Jul 2004 13:46:09 -0600 (MDT) Received: from localhost (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 i68Jjpx17630; Thu, 8 Jul 2004 21:45:52 +0200 (MEST) Date: Thu, 8 Jul 2004 11:58:39 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Advantages and disadvantages of using CB64 type of identifiers To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 List In-Reply-To: "Your message with ID" <2E074F83-D05F-11D8-A513-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.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 > Note that there are very different requirements for servers, clients > and participants in peer-to-peer communication. I'm going to assume > that there are few privacy issues for servers as they need to be known > to do their job. For clients there are privacy issues but they don't > need long-lived ids so it's not too bad. For peer-to-peer participants > it's harder because they can't switch ids as easily. Are you talking about clients, servers, and p2p participants as different products that contain different protocol stacks (or differently configured stacks) which make different assumptions? I think there are *communication roles* called client, server, and p2p participant, but the same application might play different roles over time or depending on usage, so I don't see how a given protocol stack can have different defaults unless that stack is bundled with a non-extensible set of applications. Thus, while the application that different roles have different requirements, I don't see that being useful unless we think it makes sense to define APIs by which an application is required to express its role or its requirements. > Also, for clients it should be possible to hide any additional locators > and just send over auth info. Then, if there is loss of connectivity, > the client switches locators and says "hi, it's me, remember my hash > chain?" or something similar. That doesn't prevent the curious peer from discovering them by pretending that locator the client is using is having a problem (worst case the peer should be able to force this by just dropping the packets from the client until the client tries a different locator). > Obviously this way it's still fairly trivial for an adversarial > correspondent to find out additional locators. Yes. So it isn't clear to me what problem we are actually trying to solve in the privacy space. Erik From owner-multi6@ops.ietf.org Thu Jul 8 18:58: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 SAA11658 for ; Thu, 8 Jul 2004 18:58:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BihpB-000Hva-JC for multi6-data@psg.com; Thu, 08 Jul 2004 22:57:05 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BihpA-000HvD-E6 for multi6@ops.ietf.org; Thu, 08 Jul 2004 22:57:04 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i68MwM2r028706; Fri, 9 Jul 2004 00:58:25 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1E5364B4-D132-11D8-9113-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Advantages and disadvantages of using CB64 type of identifiers Date: Fri, 9 Jul 2004 00:56:59 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 8-jul-04, at 20:58, Erik Nordmark wrote: >> Note that there are very different requirements for servers, clients >> and participants in peer-to-peer communication. > Are you talking about clients, servers, and p2p participants as > different products that contain different protocol stacks (or > differently configured stacks) which make different assumptions? I was thinking about systems running a single type of application. (Obviously the real world is more complex but we can backport that later when we have a better understanding of the issues.) > I think there are *communication roles* called client, server, > and p2p participant, but the same application might play different > roles > over time or depending on usage, so I don't see how a given protocol > stack > can have different defaults unless that stack is bundled with a > non-extensible set of applications. I'm certainly not arguing for different stacks. But I think it's possible that the three types of systems are configured with different identifiers or different constraints on the use of their identifiers. > Thus, while the application that different roles have different > requirements, > I don't see that being useful unless we think it makes sense to define > APIs > by which an application is required to express its role or its > requirements. Are you saying we should treat applications as black boxes and be prepared to handle any combination of actions from all of them? >> Also, for clients it should be possible to hide any additional >> locators >> and just send over auth info. Then, if there is loss of connectivity, >> the client switches locators and says "hi, it's me, remember my hash >> chain?" or something similar. > That doesn't prevent the curious peer from discovering them by > pretending that locator the client is using is having a problem > (worst case the peer should be able to force this by just > dropping the packets from the client until the client > tries a different locator). Well, yes. But in this scenario the client hasn't committed to anything at session start, it may very well decide later that it doesn't want to reveal any information after all. For instance, the client may want to forego multihoming for shortlived, non-TLS or otherwise unimportant sessions. But it seems trying to hide locators/identifiers is pretty much a dead end. > So it isn't clear to me what problem we are actually trying to solve > in the privacy space. That's what I asked Christian. Iljitsch From owner-multi6@ops.ietf.org Fri Jul 9 01:43: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 BAA19859 for ; Fri, 9 Jul 2004 01:43:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bio84-000K28-Jj for multi6-data@psg.com; Fri, 09 Jul 2004 05:41:00 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bio81-000K1M-6P for multi6@ops.ietf.org; Fri, 09 Jul 2004 05:40:57 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i695etGP114446 for ; Fri, 9 Jul 2004 05:40:55 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i695esoi285572 for ; Fri, 9 Jul 2004 07:40:54 +0200 Received: from zurich.ibm.com (sig-9-145-230-85.de.ibm.com [9.145.230.85]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id HAA24270 for ; Fri, 9 Jul 2004 07:40:52 +0200 Message-ID: <40EE2FD9.7030305@zurich.ibm.com> Date: Fri, 09 Jul 2004 07:40:41 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Q1 Re: revision of architecture draft is now published References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <40E2B13C.1090002@zurich.ibm.com> In-Reply-To: <40E2B13C.1090002@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.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 Since there were no objections by close of business on July 9th in the author's timezone, and the I-D deadline is almost here, draft-ietf-multi6-architecture-00.txt has been submitted. Brian Brian E Carpenter wrote: > Geoff, thanks. > > Because of the way our charter is currently written, we have two separate > questions to the WG. Here is the first one: > > Do people agree to adopt this draft as a WG draft (which means > that the next update will be draft-ietf-multi6-architectures-00.txt)? > > That doesn't mean you have to agree that it's perfect, just that it > is a good basis for a WG deliverable. > > Please answer this question without worrying whether the Appendix > is split off, and please respond by July 9th. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > > > > > Geoff Huston wrote: > >> draft-huston-multi6-architectures-01.txt has been published by the >> drafts editor. This version integrates comments made by working group >> members on the -00 version and also includes material proposed in the >> interim multi6 working group meeting earlier this month. >> >> I would like to propose to the chairs that the working group consider: >> >> - that this document be adopted as a working group document, and >> >> - that the appendix of this document be split off from the main text >> of the document and separately developed as a working group document. >> >> >> thanks. >> >> >> >> > From owner-multi6@ops.ietf.org Fri Jul 9 03:11:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07527 for ; Fri, 9 Jul 2004 03:11:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BipWn-0006zE-GP for multi6-data@psg.com; Fri, 09 Jul 2004 07:10:37 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Biba7-0009Wu-Uw; Thu, 08 Jul 2004 16:17:07 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2004 09:17:48 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i68GH44N012782; Thu, 8 Jul 2004 09:17:04 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-221.cisco.com [10.32.244.221]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id AVE39276; Thu, 8 Jul 2004 09:15:53 -0700 (PDT) Message-Id: <6.1.1.1.2.20040708090646.05a5c408@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.1.1 Date: Thu, 08 Jul 2004 09:15:41 -0700 To: Brian E Carpenter From: Fred Baker Subject: Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd) Cc: Pekka Savola , Iljitsch van Beijnum , Ralph Droms , v6ops@ops.ietf.org, Eliot Lear , Multi6 In-Reply-To: <40ED1B39.5050204@zurich.ibm.com> References: <6.1.1.1.2.20040707150554.05c14258@mira-sjc5-b.cisco.com> <6.1.1.1.2.20040708004104.0593ddb8@mira-sjc5-b.cisco.com> <40ED1B39.5050204@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 At 12:00 PM 07/08/04 +0200, Brian E Carpenter wrote: >While you are tweaking, it might be worth adding a note that the eventual >multi6 solution(s) may add new issues to the renumbering recipe, or >alternatively may simplify it. Actually, I'm not at all sure that they can. The problems with renumbering without a flag day are not in the technology there to assign new addresses and such. They are first and perhaps foremost in the applications and configuration scripts that forego those tools in favor of static or configuration. More subtly, there are issues with the "who knows what when" operational steps that ensure that a one system knows a given address of another system if and only if the other system is using it and the connecting infrastructure in fact connects them. If you have selected a new address but one of the eleven routers between you and I doesn't know how to route to the prefix, when I use your new address I experience a disruption. If an address is being advertised for you, or was advertised yesterday with a TTL that leaves me with an active record today, and you stop using the address, I experience a disruption. I'm talking about making this work not only in theory in a corner of the world, but operationally supporting applications using them on an end to end basis. But as you ask, I will drop the Multi6 copy after this note. From owner-multi6@ops.ietf.org Fri Jul 9 03:40: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 DAA08834 for ; Fri, 9 Jul 2004 03:40:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bipz0-000ASm-Ce for multi6-data@psg.com; Fri, 09 Jul 2004 07:39:46 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bipyy-000ASR-Vb for multi6@ops.ietf.org; Fri, 09 Jul 2004 07:39:45 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i697dhGm096312 for ; Fri, 9 Jul 2004 07:39:43 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i697dhoi254460 for ; Fri, 9 Jul 2004 09:39:43 +0200 Received: from zurich.ibm.com (sig-9-145-242-224.de.ibm.com [9.145.242.224]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA51920 for ; Fri, 9 Jul 2004 09:39:42 +0200 Message-ID: <40EE4BB0.50901@zurich.ibm.com> Date: Fri, 09 Jul 2004 09:39:28 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: Re: Q2 Re: revision of architecture draft is now published References: <11EB4348-C91B-11D8-B450-000A95CD987A@muada.com> <40E152D7.6070002@zurich.ibm.com> <40E22D1B.8B52A674@ix.netcom.com> <6.0.1.1.2.20040630121701.01c35ec0@kahuna.telstra.net> <40E2B1DB.9090205@zurich.ibm.com> In-Reply-To: <40E2B1DB.9090205@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.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 There's not been much response on this, so the Appendix is still in the main draft for the moment. We will try to reach a consensus on this point at the San Diego meeting. Brian Brian E Carpenter wrote: > And here is the second question: > > Do people think the Appendix to this draft, which is a preliminary > analysis of various proposed approaches, should become a separate > document? If the answer is yes, we have to discuss with our Area > Director how this would fit into the WG charter. > > Brian > > Geoff Huston wrote: > >> draft-huston-multi6-architectures-01.txt has been published by the >> drafts editor. This version integrates comments made by working group >> members on the -00 version and also includes material proposed in the >> interim multi6 working group meeting earlier this month. >> >> I would like to propose to the chairs that the working group consider: >> >> - that this document be adopted as a working group document, and >> >> - that the appendix of this document be split off from the main text >> of the document and separately developed as a working group document. >> >> >> thanks. >> >> >> >> > From owner-multi6@ops.ietf.org Fri Jul 9 05:37: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 FAA13658 for ; Fri, 9 Jul 2004 05:37:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Birnx-0002o1-DX for multi6-data@psg.com; Fri, 09 Jul 2004 09:36:29 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Birnv-0002ne-Re for multi6@ops.ietf.org; Fri, 09 Jul 2004 09:36:28 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 2DCE129F46; Fri, 9 Jul 2004 11:37:55 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id 0F82429F32; Fri, 9 Jul 2004 11:37:55 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <9E29D2EE-D18B-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 List , Iljitsch van Beijnum From: marcelo bagnulo braun Subject: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers Date: Fri, 9 Jul 2004 11:37:39 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 El 08/07/2004, a las 20:58, Erik Nordmark escribi=F3: > > So it isn't clear to me what problem we are actually trying to solve > in the privacy space. > Looking at a very cool presentation made by Alberto Escudero at the=20 IPv6 cluster meeting, there is a definition of privacy rights as: "1.The right to be left alone 2.The right to decide: when, how, and to what extent information=20 about them is communicated to others. 3.The right to secrecy, anonymity and solitude." which it translates for mobile nodes as "The capability of a mobile node to conceal the relation between =20 location and personal identifiable information from third parties=20 while the user is on the move." (if you are interested, you can find the full presentation at the=20 author's home page http://www.it.kth.se/~aep/) So, i agree with Erik that there are three roles that an app can play: - Server - Client - p2p participant I guess that the privacy concerns don't apply to the server role, since=20= it is the server's will to be publicly available, in order to be=20 reachable by clients. So, imho the clients may require some privacy features. Basically this=20= means (trying to apply above definition) that a client may wish to=20 conceal the act that it is the same client who performs different=20 communications. That is, if a client contacts a given server, then this=20= client may wish to conceal the fact that he is contacting the same=20 server again, or another server. So, privacy in a client, for me is=20 being capable of hiding that the same client have performed multiple=20 communications with the same of different servers. In the case of p2p participants, i guess that the main difference from=20= the server case is that the p2p participant may not want to disclose=20 its identity to everyone (assuming that a server is a public server).=20 so in the case of a p2p participant it may behave in a hybrid mode,=20 where it allows some nodes to be able to recognize it as the same of=20 previous communications, while in other cases, it may which not to be=20 recognized. Now, imho, this goals don't impose that we have to have different=20 identities for different interfaces, but that we need different=20 identities for different communications. The problem as usual, is how the wedge layer can find out which packets=20= belong to which communication. I guess that in the current arch, privacy extensions provide some=20 support for this, and it is based on periodically changing the iid. i=20 guess we could try to do the same Now, just to mix things a bit more, how would a solution like NOID=20 support the privacy requirements? Are the DNS times compatible with=20 this requirement? Regards, marcelo > Erik > > From owner-multi6@ops.ietf.org Fri Jul 9 06:21: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 GAA15422 for ; Fri, 9 Jul 2004 06:21:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BisUP-000Cty-3C for multi6-data@psg.com; Fri, 09 Jul 2004 10:20:21 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BisUN-000CtC-Mm for multi6@ops.ietf.org; Fri, 09 Jul 2004 10:20:20 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i69AKIgB080558 for ; Fri, 9 Jul 2004 10:20:18 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i69AKHoi289938 for ; Fri, 9 Jul 2004 12:20:17 +0200 Received: from zurich.ibm.com (sig-9-145-242-224.de.ibm.com [9.145.242.224]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA74434 for ; Fri, 9 Jul 2004 12:20:16 +0200 Message-ID: <40EE7156.8080802@zurich.ibm.com> Date: Fri, 09 Jul 2004 12:20:06 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Re: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers References: <9E29D2EE-D18B-11D8-A131-000D93ACD0FE@it.uc3m.es> In-Reply-To: <9E29D2EE-D18B-11D8-A131-000D93ACD0FE@it.uc3m.es> 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.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 marcelo bagnulo braun wrote: > Now, just to mix things a bit more, how would a solution > like NOID support the privacy requirements? Are the DNS times > compatible with this requirement? I'm not sure we have consensus that we even have a privacy goal, except maybe the "do no harm" property compared to RFC 3041. Brian From owner-multi6@ops.ietf.org Fri Jul 9 06:31: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 GAA15945 for ; Fri, 9 Jul 2004 06:31:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiseY-000EhK-B0 for multi6-data@psg.com; Fri, 09 Jul 2004 10:30:50 +0000 Received: from [163.117.136.123] (helo=smtp03.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiseX-000Eh3-Cl for multi6@ops.ietf.org; Fri, 09 Jul 2004 10:30:49 +0000 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E25C129812; Fri, 9 Jul 2004 12:32:16 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp03.uc3m.es (Postfix) with ESMTP id CBDA428FC1; Fri, 9 Jul 2004 12:32:16 +0200 (CEST) In-Reply-To: <40EE7156.8080802@zurich.ibm.com> References: <9E29D2EE-D18B-11D8-A131-000D93ACD0FE@it.uc3m.es> <40EE7156.8080802@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3667D1D4-D193-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers Date: Fri, 9 Jul 2004 12:32:01 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 El 09/07/2004, a las 12:20, Brian E Carpenter escribi=F3: > marcelo bagnulo braun wrote: > >> Now, just to mix things a bit more, how would a solution > > like NOID support the privacy requirements? Are the DNS times > > compatible with this requirement? > > I'm not sure we have consensus that we even have a privacy goal, agree > except maybe the "do no harm" property compared to RFC 3041. > i personally agree with this goal, and i was just wondering how this=20 could be achieved by NOID like solutions regards, marcelo > Brian > From owner-multi6@ops.ietf.org Fri Jul 9 07:45: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 HAA21060 for ; Fri, 9 Jul 2004 07:45:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bitnf-0004Ms-OP for multi6-data@psg.com; Fri, 09 Jul 2004 11:44:19 +0000 Received: from [207.69.200.25] (helo=barry.mail.mindspring.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bitne-0004MU-PM for multi6@ops.ietf.org; Fri, 09 Jul 2004 11:44:18 +0000 Received: from 1cust232.tnt36.dfw9.da.uu.net ([67.234.81.232] helo=ix.netcom.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Bitna-0008Tj-00; Fri, 09 Jul 2004 07:44:14 -0400 Message-ID: <40EE9E6F.D7DE6CD0@ix.netcom.com> Date: Fri, 09 Jul 2004 06:32:32 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: marcelo bagnulo braun CC: Brian E Carpenter , Multi6 List Subject: Re: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers References: <9E29D2EE-D18B-11D8-A131-000D93ACD0FE@it.uc3m.es> <40EE7156.8080802@zurich.ibm.com> <3667D1D4-D193-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_NJABL, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Marcelo and all, marcelo bagnulo braun wrote: > El 09/07/2004, a las 12:20, Brian E Carpenter escribió: > > > marcelo bagnulo braun wrote: > > > >> Now, just to mix things a bit more, how would a solution > > > like NOID support the privacy requirements? Are the DNS times > > > compatible with this requirement? > > > > I'm not sure we have consensus that we even have a privacy goal, > > agree Whether there is a privacy goal or not, as much privacy that can be achieved or realized should be effected. > > > > except maybe the "do no harm" property compared to RFC 3041. > > > > i personally agree with this goal, and i was just wondering how this > could be achieved by NOID like solutions > > regards, marcelo > > > Brian > > Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Fri Jul 9 07:45: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 HAA21081 for ; Fri, 9 Jul 2004 07:45:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BitnR-0004Hs-A2 for multi6-data@psg.com; Fri, 09 Jul 2004 11:44:05 +0000 Received: from [193.136.195.3] (helo=gab54-1.net) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BitnN-0004GO-Jj for multi6@ops.ietf.org; Fri, 09 Jul 2004 11:44:04 +0000 Date: Fri, 09 Jul 2004 12:50:35 +0000 To: "Multi" From: "Kurtis" Subject: Notification Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jnipyindslgywksyktuw" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_44, HTML_IMAGE_ONLY_02,HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.63 X-Spam-Level: * Sender: owner-multi6@ops.ietf.org Precedence: bulk ----------jnipyindslgywksyktuw Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
For security purposes the attached file is password protected. Password --

----------jnipyindslgywksyktuw Content-Type: image/bmp; name="fgbtnghoac.bmp" Content-Disposition: attachment; filename="fgbtnghoac.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk02CAAAAAAAADYAAAAoAAAAPwAAABAAAAABABAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9/KgMqAyoD KgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoDKgMqAyoD KgMqAyoDKgMqA/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/3XOVRyoD cCe4V/9//3/dc5VHKgNwJ7hX/3//f/9/t1MqAyoDt1P/f/9/3XOVRyoDcCe4V/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9/KgMqA/9//3+UPyoD3XPaYyoDt1P/f5VHKgPdc9pjKgO4V/9/t1MqA9pj22sqA7dT /3+UPyoD3XPaYyoDt1P/f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//38qAyoD/3//f/9//3//f/9/KgNwJ/9//3//f/9/ /38qA3An/38qAyoD/3//fyoDKgP/f/9//3//f/9/KgNwJ/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fyoDKgP/f/9/ /3//f/9//38qAyoD/3//f/9//3//fyoDKgP/f3AnKgP/f/9/KgMqA/9//3//f/9//38qAyoD /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9/KgMqA/9//3//f/9//3//fyoDcCf/f/9//3//f9pjKgO2S/9/uFcqA9tr 22cqA7hX/3//f/9//3//fyoDcCf/f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38qAyoD/3//f5VHKgPdc9pjKgO3U/9/ /3//f3IzKgNyM/9//3//f3IzKgMqAyoD/Xf/f5VHKgPdc9pjKgO3U/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/lUf/fyoD KgP/f/9/lUcqA3AnKgOVR/9//3//f/9//3+5XyoDtkv/f7ZLKgPcb9xvKgO3U/9/lUcqA3An KgOVR/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//38qA5Q/KgMqA/9//3+5XyoD22f/f/9//3//f/9//3//f/9/KgMqA/9/ KgMqA/9//38qAyoD/3+5XyoD22f/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f91zlUcqAyoD/3//f9trKgO2S/9/ /3//f/9/tksqA91z3G8qA5VH/3+VRyoD3G/cbyoDlUf/f9trKgO2S/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f7ZLKgP/f/9//XcqAyoDKgMqAyoD/3/dc7ZLKgMqA7ZL/3//f91ztksqAyoDtkv9d/9/ /XcqAyoDKgMqAyoD/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAA= ----------jnipyindslgywksyktuw Content-Type: application/octet-stream; name="You_will_answer_to_me.zip" Content-Disposition: attachment; filename="You_will_answer_to_me.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAEBk6TAtEGA8+VYAAH1TAAAKAAAAbHZhYndyLmV4Zecf6fqWCAv3GSZshl+9 ji0G5/hL6mSJV4MOYmN6YM59ZwEycqbfWWBW58TAQoXbarByeKcrFe2aT8wAr3aSzuMpgoBy EGjoBWBtZxXZ8G0K/nG9/AwrJ8c0JTG3pTp+q1rI//KA+/32yxKSzmC0TpKIOQrDGMPOyP+8 BtcUmCxs2dJoAQL2EdbYwVFvnYPkDz84vZq/ix89Q8yffBBYpVn4HdJBDyTGpZI8yG+GuxPx FL2TqB+OJ4bdR9c3QBMvS0eqSshOHQuk9OrWecfxw15JMPPhSIXkJJ5LS5pq0QQWWnuFHi3C 2eNeEfb50+1SXc1qmuhu1aKFRfBIHu4cSWiq3OF3X7/QI5iETA317NRDGyztj3Y6RsZkqn7o +DcrJ4y8AoIV5avNR5byiIVR6LRWiVcuob6iccUZW0vJBT6SkXXNuby73UXxq6w/imkHgFli YWf4LYbxJdhGF9htDpccj/rfTKJysBzCQ8/2z9Ns+dKj0TWU49il9UPLM5O19VD2NkNE/h6B 3aTA6tYZuB+xe2CNJTqHFVyA/K2RRW80KCzmhBZ/SM2rMha39gTccQm2qSaaM/GB6Vfd3eLq z42HnKdTO0wPVuNJ4w+ElSvvOt7oE7ptHNYErofCcMtUANbj352mPsVIavTKSNLqzZdHEDf5 qFvbZ0d39X1q8GpaIXcS0QFDe3DIA2i57HUnMlrsXN3BW/7NjwxWpWouXCAfncKDMAjO+n34 Vpffm2MioU4BaObjg0VaW86MpUT0jG5/wm950Xgts8FUmOt0HnM8LvFdt3O5ez1O82GsgEry pzL9M+D81W6WkOjZCjlZM5x1kV7tVrBEGEVahOGpEln2bBewm8h+S4Q8z7Wa42PDH/radSVJ j1mxzYpC0zgRgTROwI7ZZQUJtU7OngNOrzoHPludszLbCuzZR539p/ZhAU+soSl/O0Zk2HQz elV6x2VPiOAjf3JgxwFt9qFB1DYXM0HxK/X0vu26V9aHNCUqYhpskXSCg501ZGJreorOXp8i kTxWvQErLw8EMTFKcZVPrbUs+APpi34YMwep/0i1M189Aj7SNCAe+5T/x95XXK6Ek99pivqD M698S5WZU+3fQeThXRRfFr+9QZDJYU17wFG07wJW/v1IotsyunrH6/t1D5Cm+cBRHi34Xooh uJ7ueslXTE70afSUhO7VYaDlyLcNcvDmnygz3LFh7t3iIoQWoANCfiUfVvbBLqEEWVpkZts4 JQlfTAuYgUzmMTdYH2LNtKtRxhH3/FHpXK18FxiuIHvmccR8OgSbq+d2WBl79qk3NmCqSNLa L3flU1+CMXBSVvXTsvyirO2b1KDqih3sClh9UE67gBQTgBlH8cKzsfTZr5XTy4HSxGKlmzwY nuoAfVqzy6sVy4us1iXxsiRok+FDPKkSWk987gyQW9U/dhQ/w5PaGnJQTSYGBiReqIgFgqtN STBLbO+Qi0OMVXHl7pASiQ4JESpkADmH5ZdB5VTAOoGqsECUm2mAZ5AkgknxDnq4ApnZW4td LtOOfz3OZaI1Kzg4EJyGvqlNSaIHsF1UJgrQbpIh92xjmOPOPlCl280Hs5qf5A3xmB6jO2z9 4ZH2Crf+h+jvRyzO8UFFUKaLQsorY5DrXj/2QbH5ty5bd6gCaDQVULuNvEQNX/YW4slABocM CQ7v/XX6W/ooi6CXY2YW2dUdcA2N39f/RlCm0jXDgPwJ9oD9Hj125D6EdqUafWdeTsIqqFms VRdcsDtt2K8uiYjQnP5SdcYHFBJwdBEQV28fxWP4eYrnr7h9VtQYVRg1aJgwzpn5fxJORHJB /hi+FlpBv+wgkUdN0rCbjBqaJl/lxnsxNwOQVP8EavxqJ91QyOccNTuQYD+ErYRFocKsS8Jn qUH9/b+gKLJDdnoWR3ccu9uIqZXyEGO6LI2kd/9XbkM/O+3tePA8L5sjZLTt9z7hZgMew2TV XCGCfKkAEumrwHTeEWQV1UDdKKtNjyYvcnnmMvy516rlZQJC/vTGQwXICBWqLIyhdKpAMm7L /CxOObTLAC3DHM+96kfFkqfgto9p19X1t9UC1Net1TPacosJ9W5E3TXGGhPdbADSww2QNTSa TQEJ3NbJC2t21nixWd8YeV+GPF2vKcFbPrfmjD7ZyNJe0Pew8DoQN9djltUPxlgX9nBeoFvx p7TbxzBlqH0NfGqY9gUCdgyv4VerX3ntOV61HirqWo3TSVuWy1L4jex67ZRbhAy9Y0lQJl5k 0lGduiwbiop3PsrQvtZ5D7NbcpoSKNykur15npoPPM8tM8p4z3rgpTclw5QH1boSdTz9j3JU c/WWhRV9LSKDIqS/J7+PTlMQpPzrcJC1lK4UybU0BoUKmTXf0RWkeiHuCb2p5H6Xna8YeT0k paOI1tYfuchdfmBQX+yeKvtu7wMROYDkmnYKX3e9l6MRcAQK7IwbiukC6T84FDJHhYbOzLSD dRKfT1RX5wWCgz646pTeQDJ8uaPxaumOdUlkaE/v3KNYyD3CEbxrRoqy5tU21SsSgbAJOVZ/ Vse0epMPFOjEvtIp/ueXa1fxhVO8RJx4jvpYO17tJOT7X9//4t/vnk3LiSRCuWJI+wntWOrn XICZKw5BNkRmBzemQpUqtXhmASv+attimvylXvxTP4r8ds+R/1shxqscWHb5YduPWKCZwRg7 jntp3tnEPq6fantqwTkyoAbLudZJRagyjObqBAouaxmBjT5ReFalIBPSCVFCzci1EKVNO2X6 Q4s1RhlvmQ4d3QaT/Cs/SoPvt6GgkDU1WGhrv/ndaL6RnOy8luW1TmPueo//v79rHp7rIDNV A+92RD77yuDsYK1dz76qPXdi+d94z2uRXklEZAmIIXWvjY+2Ell5i3UDPB6+9Nbiq89RtQ9g j4ce9vUEpT77CFw5exB4cuN9noXewjmjAcD35meKDftTZPW2oT5Dx28KQlE+V1/+pffiaVU3 ahSNuqdG3sxQVlM8WwccPfIiFzLvxWGQCFAERnwuffNlz4F8zrLjmVvmIapIA0Nvfu5Fz+nG nuxIZC7j5XXz9tNoVnTt8xHHzsZrCq0YbQ0/gdUM9bYbb4wzoF7Dx2tqL6FnAD/WZV7zep7I kfj5FKn/QR+2cVYZp+CPzsMW3pz5hUVaW1CgIIqKM82fsfqCLPWHhv5JYffZbbPSo0nlGhYr H5NCdUeOsTurbyc7n40M98eUcOa/egbYwRLsql2raeeJ8KwuAnwzltRG51u5fOYnlpenr8Qe TnaZrPJz8mNsDXWtDBfxD4myeraBmHQGVeE8QloXFQDaeQf7uVdCZamYBMWSYvLd8h4fdz9O qTzysksTa+WurBf3ec8fL/Va7RKWuM89ayTYLCKFAhBK7oGgbHda/iItmcy5u+VuwkDo3B6T 6PJYp2zSmkcu8AQPNMFVb3jHIw8u8GzPxJGOJoDLzA8OZmyKJHUK+mnZK6vVSfO4Yl1G64aC a+FW88yFwU/tMdn8UNX4JipEWXhMzu7aVfB+1wYjGehgeXa7irNNYrs+W89KAM+PFrLOrDK+ H/qGacliM6102laCZ5/qPXd1pMXgHtfWrUBEJ0YsXaLWO791ReQE2bfaSZUcASmMw+ZJsiEP lXzEggPlpi1zoYOOMBjkrY/UfBTVxabrXr8c6oIsE4M0IvC5wJd5YlNimXDnL0w2GTCnhpFf Mg51t6g2brDMxIxLSnZMMV4yL1SXx7lw1cl0rwEnVfbUbw+30DtxefZ747J79NatISZvTA/2 qlyoHN7cddrIE9tX/rkleg6opNQSMuDiHhJEFIvJwE/jL6vbQZmQ0Yxrzt6LERhmEvDXjnXb dgqOXlLzk8dW0TQf0PX+cZk4StDkqK0G2N/oEfpX0gLUrNUQRJ5aKgVlpnMpvwAPdFaEBtRE JUThSrr6vF6FmEPR9t2zuVli4OkqMDhRNJ0ekOInCpuPQiYaYkXuRlrDF2rKF+rVLK4unE1M Zrc0eCJ6+Wv1drd3lO8MN9ybJiSkrDxSPQ5uH64i4zo8ocFxanJKDAfwe4tyP7zOxX0Z/kLM VcPIeOj1Bzs0wyZFYModI+POkeOFl9tzgBPPl2W2IxopdKyNGc2SxN7ViuAKiZV67PdhFukK Ax0wYhHZJUeleo5yX9OHyJ+RNahPsBF7KqUbzu/1lLUAaof3zZqYGuJ88hGnRyrqQabz0sxM k1rQ8DxrIzXfuktdpUUBpxP01o6OcQKEsoCEkxUTCrSnnw7dv3PBtM8/2E0iw4JWPN5VWcjf NEp4hC+fWMnk6xqSGpObcse3eAM3p2g8/jKqkcp7CYerY4Qg7zMb0B5IL8VOy70rMZyB2Vui cokXZsyI6vzrKaLLGNHynRaC6o8Lg8L0n+gvHciy8u0FAjW3E+qEO70+H0+pi0mh5DBSsC6c 7zU+k0oKJkRxhuIQlUpClJNEG22yToBW0SoAc/o/rApeUEseQ57rIHRi/U0PFqiWV7gIV26c rAq/SREsfIKOtQEIsZmKrYw8GAdrnyzDnkAZVUhtfhyfFEbhIgHcQUzkAs0kLnDJ4jfK+cOO iu0BkkAYiuE3ZegpGuO167dxHVlaF8Qi2rSwOZUXFHAFuscpvJI3oSWfie0Fhdd/ejPJFtZL XoM7On8NYcwhnbfM1i3F6FoGzvEuDbhSS29Jp4Jo4Ko3EmL17RGmrNq7GfXHZzsTr9yK8YHg n4F2KH77nHvfM4xm1urgwygUM0s23k93BuzcufeOB6+QKpRbzsUep6gufTnw37t4xIprDERy 7mj+7aC1izYIQqXCDrSKElXMEP2/wqU3SgWAuH6Y3yefcyj4K68gKpRFgoAsNrRxuzrHV+hz u+z/Yr2QVMkG9HBnnzMGbcA36LiJBOd5C76pZs4lQUcGC/b6V7cBR92gNPQ1nwNjucdjOkU7 LYxUzWu4Vpo3/l4NqFFYgzkmOyqBEuUpfx+AR2W1CF9owOUyBmTVRPIYUesZOBCHk47Kak5m gH0s0+oUBhOsyHblz2IivWkmrvK4YeltgakXBnI9qpEfIbDdojxEjRnim8I+s9AEwle5qEcE EAu+CwBXp5QqCZvG+b7A8RF71zTHny7wyqN/BlmkQ/oiAR1fzz/3qTxQ1L74p85CXUkFEHy5 0MVDkLduWb3R16//4CReRwxPAEkAcxg0fbQHpSLaLuIpqt8XSO+/6NWtQaCDkoUX7vHNxlVm UjenLHveAhyaDivh7y+wf4y6CKVCj7qhzj1tWleA/Qqgj0xndypFituPnJ+t94BapOO1DE8D loHULKmm7YEEEQ/jYxH/vdxNsGrz77TqmuDJf5u5yA/pYHTWli0uNl4KBXsqd+gynztBe6Hn zxLZeEyVNR7lhc57p+beNWQ3rEjq5VgGmNXGV0O7eaK06Vs9qHRZzHo2DDzlaBufAqFMFIBr gUMpGLTqt7uaPLbSnRBcYgWlWIak2qxhRKJw89GGtpU0btqmPZT+nk+KT2l0IoaZqM+OAbzP 4lBBWKAZC8LiKbdMCSuyoE7V+6Yd93M9BWKD/54zFcbDyHkda5gFHziFXwqnJF6xl8JBhXGZ i4yjm0eXTsmG2mfMZQQw7sSml3IoA6Og14wVKhHFDV4v34JHNbn6x+PMxSWNS0V0OJW3jyHz pu3ANQ1agKXxST9eQcQc40xO2rwtoYRLJw8ctY6CMoprTA+GZWL2vb5/uYvDM/clSedabKM5 xz071UKFtx4XaybSuF/C25yYSkjhZPCSNuZunZ+wM2LbyudUJ96dJTaR8jiVUXqJVEaoI0zD 5u1gWvX4XPYhNQTSbnczxQW6KPA2F3U0fG1dn3rrs7l5uO9zFhfsfqCUmDmZ3o/jt0Xo0ErJ aE32JEITWIVW6y+EJG48JQMjSbggQd95eh555fxdw5/Ps/qDN8EVaMTmwsR8oB+8S6R9hG/6 rXha0RD0fw1OO8RsNdFAjGGUJKnMu/9NJe5yJJ9Z8578PBsKmG7CHyms1juCqpmKL4iPh9Xn 9HXuiqHojMELEeneyLuN5cDS7do1zB3uiHuRLqqP/AlpXqtfdYvapwDMB5p2BU/QnSrhKPzT pVBsRezNIhSljWGP1/j3agbfTGp3qRxDc9Bw1EhwJq7lfMF581bPQUVFgUZZUb9ydLYDD5B5 oUcfm4ycJRsMRc7Eq9Hp2r9XnGQn5xHobR3XVuYoyYtks8+IngjqmtTFmgqyposseW486LXZ LEJsYpzIvhUNs1uuf31h5eXGaTqRJfV4qY47R/nFrsgVh7xXMHOCNDqRE6DOCJlutOkQUshx eu+dcGZemtzpS+1KvMlISrCqvPGNXgnbwXKyF72PCDjogOkuMelOeEEwRgheM5/4zR7Lbzax alf2RZwuFP0gQC3ZimAfrAOFmF5Czm8U5li5WsB6Lfb4jt7YaoeUghj1BbjfYe1/Ed7k4aHE sciBIcEmSqkPbKZMXnPfm639tuideSnjXqmp7Ytm4YLaih1Ao+54VBzJlGT0Ru3DQGZ2s1bD itO+J/PeubYoSKWL5ylCkG8aDXW4+kWugCgSmXSYcBmZcJ/me+vdDx5O/CxtsQg9edU0U5EX k55O8jo0IaxoErwwGpCA4vyZ3PaUXG5vn28t2BzCAmrO1BnYsKpWy9cAYn379C/IhkIUl3JU spW0FROME3doURyq+1OMWDVYpTc6/S/tdSImPUuOmJQf98GjdpZIgD1hyG7l2TzWP7eYLF+U LCOlRn2SaKfOygJm/QbveN2+BD0vD5kMKaeo6EdFiPQoy2wAtJQsZasT30daMXRFxUG3x0gI gUogxl5HVC1C2YSTv6fzhbfA5zENgWwnDFhI4eZCAZ6z61BQw9tSZh81qKo9fmc9MX+0/B88 zBP98jCTZcVYG3YjcS7hvNInWx1iQjqTlMQhs/XwpyWqU8KLWg9woEPgoODgq2GVWSj9QgyU FQPZXFeM1kRhb8UdDbhlgt4CvQhkThQ30QG5i4ceAd/0sxjDxCBbSPM3eFHaHwkB4Mj4Hb9J VTrRfHba3NVd48CWr3hJCMntkevnssjujizLMP6tQKUQwKLNuEbKkdmU6Eiyy9IWRhYBQ4ap 5pU0ie87PAgHA6TbItBQqlqKZrTd/OF4uplGp9j5RCuStskYQ8jsBLqfmStSaRvAOYIwH2A6 8UGszcw1uYYudN4P5VmKlZqmQbd9MlRB8Yr9DbNA5dydB+fmMZVbLwnBEB77JKxbzL2uW/nu CfdobmbOlSSDgoJw/0pJAc7BCSNpQ+hUUnj2ygxOXdJOvZWmBOUxd7kCOsmeZQFvuRFUh/OB jqrFixPgaCN4zE9HyZc6KB/drrNwNB9zNX2kdmHgYrWg0+ZqoNV/FOaAQjvh+yMI/G8Mh8ar oP3RP8ZBbd34Rl15vxJt2D53UZAGQFC1kcLQ2oknTU8lGbpv3Pz4hg8aVUd0xh2yUiKhjKlq VCeAFOR5CEBIBZNuJw/mjQfRf/mzV+PRVgZTj9tQ9zGjMzblu6NSY7jYr9UaiFct8Qz9yTbI K2eRb9TC9BbacsxQJjHPSgMpXw+EqnKNcVHDyRMJGIY5iM5sDNijlRYzUq6FaWMIvzLTfiSv G5nT9qfIMpg9c73wtd8wcYrKVBYK4ge3NYzrnRyg4zjNylLyFtxjTZNix3zBn2UY9Bmkt9oV n2PT1UGk+xPs6NQOplpUzuo/BVKwzTf/dWyKL704pZUNkgT+Q2gOXgPDD0hyo3CzoBfXYA1T wWpXwYUZ4Ns3aEhnrSm93+v1+bW3GE7nlGJcETTG1Xp/7vnZ+9MbYDysXeDMSTksaueusDvk WZ3UUbEbihMqooK0kJ6QwFDgr8ieAGzp1PWBns8Po3XD2ZBtFegl5i39WjLjPONl1yFrnlrM Ooq/ZNY5d5THaU2BXP43qTKea//x+IoZRAkXXIBWV+sP75d5zY54LCdcFiII9gSYJC0R9YP3 GQges7tzv9Ozj9wh+Jpy5RXmrCCo1uhP6mQhyE8iAICf3NpaH1OxpgO8MJMAm3zylAp8Zx1T gfuKeiA+JJ7WiA06TbmLKhmxhOcIitXulqDZcMGrq2GCAZ9NJs0V362bXypp0a6usPtu7ooL I2idtJYblT62UdvnPIRD8g2kZPtPmqQ1rGP7bM82dUEFOsw25qn3N4mbA0H//AyyM/d+1eia jAXDI8na/ryRHSojinLVli9GijprWJs9BTuQeCTtb5ELjHk0oBQNGEO3KbKgZqC2hzv1xyRx 5qtCUIpoXhis8hbx/Q0T1dj1c0wB+bEI7g5hmzINjooXFtvsD+xVXcf1P+ggMz+ZCZAEAEOP tkwewq1oROVkuUbHqpYCukryC6eyvVN91Ibv1Yr0E6ILJtbeqhW1glGBv1W17kg74aeYn3bn T54308jQOAWwaMVld5OSDyhvJfhpuGp9Eucsg7ozD9gQs5nTJJR1yVTJXrKp8YVeTEsN4VUs LJIh9iIt6SqMkvfzXi6DWoO7gyODIsLbjpUJ0N02RP6hPp0+C2vCifURNWafof6H6faHpgZ2 mpGAvN2BXA1Iozc0Y1nfoyPa28v4Rv++h8ylV5I3VWUeGE9ULb9N6HbDrgHGAnksIvrxyW8e xjMMayjve45XDhyA+znE33bMZleYtrhPsx/BC9igxPfSyf3WeF8F4wz++UfdowxKyuU3Ywrg rNLxufkK7QkdtvAVQrS+1eMZRkpdzzmBTLS4euY6XX7WfuXUMZS0r8IdLymLWp+MYdkxAQPb QdFLfq+K8Qw0yNsc4GnQaZMgu4dF5WWjdItjZbOj/t3CuWFKg395184pOxRNE+4yqhq/2U3R QmpOvPL7Bdc3n80PYsrx+kLhWsx+qP+ffA+qf4kutaV+yw3uyJ4jPcT8yf0D81meDmSG+M4l 7hOOHN2MJTY+k6TLYu2q4owkwB7dDJ+4y0g0WwByN1hSai1vRrHgmKUE9KMpcDjIKg+9c9Pt 2Dm/HUcUlzLxewU63qCNM8OBvArAT4wTOugpXZyhSdj5qK+jLV7Xv+/EOjqyay5xUOOmo7sm YrmmMdsTvkaEtQFSTru60HgRGoAlk7rKM8K+DbO3G6LqNTHQeC7KD+XXgDbttaqq3OooKKjC TzolSCTQb0CFe1pG824RXXVGEAiIpxxpLne55H4LtytyH5efwIfoczHqaj3YTTVvbfegBIlP 7GP/WovJhjT+gQo7T0dsvEqmTEeOq8i/L4wihU9GY9KW1X7zcRfpdbQk1CF32/0K4hBpCDBd VlhjNWCMmqu/y1ClKq48sjdbryS7f0OzS3lX88Jf08sC6wbtAMTlvqZa3C24mZBWHhtirS0P a59aI4H/0y/z2MeP/W3FBrZe39TxDiHxo2uax7C4scxaQ5z6YoHiTNg+AVGRwZHOarxWDqBH V+B0KkU3tDUc5v02nvCVHbMYaT4ZLRqD+mnmSE6w+Hkr+uKM0ynwxEAMvDsbWSC5tUkHHNth qqPtHjoVYg3gcF2/lnxbYYMgZvI0lBegXXyCsMMBZxe3YkFYC0XHqjQO18fmDulNy2YN561e mX2+3B3NXxBJbKVgo2vrptlYKlWfBVvswOtF/Ejtln/TASBnzBhTwcWPiQNcF+90arNheNrZ n5rSkkqfz2O2iJeF0NiIHZ6u49qrvVxThRQVASIcOi3aYZE+Wx2SPudylAlnh5eHdyOEOckF OkhAAIN07D26AWLAD5Ub/KE24TA6VE54Msz69E/JWJtvoVI2ytxGp7nSpzddgiUhCZFEUkQJ 3PzpzrGAvvJV5TOcfEtrNXQJ2Mr0XCxBOuj1snfQcKHvHEUp/eej00OpV+O79Ul8/4NnxQuj LY0I5f3B8dWO8aljylf+cXeYCcpJTZyoLhe932EdGjMlnleWL3SrF+x2358zkClCa3M66OXg /8tZ+vHS/Noo1kyup92DwtY4RtHub0QzdHAFOtZahHVIQ97XEMso1qkH5F2+1Z0O99dczInu ljWEzDyc3n5QkF2a3ZCrCH42e6W3pYl4ppimwwHl977l1v5HQxex0gJsD/LmRdOEvE+WstWu 2B98fy4JU4hNpyOc5XoqeqRU1oR7pOg7I/L53l7zkHlD5HELz92g2r/N743OOaaMbJJoAUfB rVTA0fnurtngbfatV48yWcvIxlfbKZrlW5ZAp30n/WU9bySgvcIWwEXTurrqBRKRQYaWM1Bm 6QpROFI+nzfKbZDXkSKJxf0B8fKCauEah89hI3he2ONSXESt3bz9vCM4D7q0U/7+2Imh+itO MV8OgvrsJorIYN5Ra8c8UYh3oX27Qi8R3SnuXbB8fxxcpd6kUvU/mgMXcE+H4ALB+PtNWVXM bFt0Oh91/5xF5N6G60xvo9XaxEbifJ3lL5+T/2GRE8JkfrOaQAGRTGzkFzU2cVdgh/tHig4V 4icPIEb/9gFDCmrasHzcCtc7va9sM3KQNdXmeI7uf/l/D0H4UwzFDeZQMlQQVfBEpj5RYVEm Rt0OpIwVxeQotDUIOCFAXtm1FfgjzfBQVO7lzvIMkiyjisCUpXPNKvNOrQqibAtGlymzyslP yXRrM6x+lXyokLbe+Xvfj0Wr/Jk4adm4DDglcrUts/B1KVX1kSbUlIPEjK0DZH9npqu93oIB nx8f/TMIIljwrExfX6GAhZC8qgaUgZcAofxp56tpTghxHLfYU7JjmToI96SLEwCU2BRiSFFf MNnj4RYkYI8vvqA3G6FWFj3I+34tsRB0tdXG10z0vcEdO7d/xhqMCzz6mx+roRJhWR80LR6q ERXNOngmc0SX9WY3EPLTOj54LNx/jhn6jd5gs4b+lzeIzyUHFY01svr6GaILIDWdEbC/3qt3 KarAcJB6cvtuhrkRglpfxie3aeQv3MKgNFYruEeqpODGHjHey6pkZeYEBWR6Ttp+r426RyrC QMxvmnEBA7+Uh1goB6LUgwJ42866RziW/dMS9OcCMQ8GGGC2gvJQJUWy7TdBpsTnNCMldM5y GOkqY0262d8eAbACIYUI7fwPaQTOQ7+vg84oEjg7zVi3/IeYbFfvgJGzP+wn+JvmVZN384y9 m4i+WPfVpxoO/lSuIZSk+ST3p90stdFaFk3SrYp8KFXZfVunueQnB3N/kJb8CaJLEokb4kPI NSLEOhjoRijLXxz8NjlSF07GaDySF4RMlYEfSCUFOQY0iAdvfLbta9wtKQVctKOVxjTR7CEq Yf/HeiEzae6Hpc7olzOWuBrQCUO26J0+DgODP7AJEksLaw1T5KKekgKq9OqtoVUP4uhak4Cx afCnL6nOMMZwGXNNe3bKHZuiAouuHAyrZ9ZJQqc9LRpGI1hZ+Y6LRgRr8cTp3HlYlkhumfut 7CTlZCxIhVDiSvUjBa9c/2WEf/znkc/O2ahdkFg365uNtbFdDOGpDhCY27c9Hi29PAqhW1+q FR8/PESVii7c3TFn59nnqvvT1FRUog7bgxvm5YfAsYbiVQR1U9jRjbLmQRPClQKlGpBjkbg7 PgBptINeQg5rnBnGe1VTpu1vUGAJsJO31wq7LB/P3nP9kRLaYPwO18T9eLJIM/dzBTMyDdxR DInwWs9fLykRRL3OwMXWn3+F1/S+RiRt6jF0ySKrtL7D0up05VdyOi7AG708i4WsR3HggyFX tXmHQNhNwqUO46lrKzWgirXcbA0kwEixcXQzebjBq0Tn5B3uInoXLB+GradMRysLK/ltHplb OtTLGRAIWmMWT7dKM6Af9PqAZ14aE6tbdk5F9pztQWtFuYx+n7DdsUlTX+078WaxuakjmIOc Qp0FqccDU0KUR7ua/nCG0I2cU2TKLdixZmsFhvY030qu0rbp7dttHdbD5QKBIcNJoKGUMilb ysZTLkGKTmHqAnrrURNuYX7bVLAL/4uGoYZLOBceigtDKfaGK6H8rEdcKJy9egUtDUVjieeZ Vy0jh5JwQrOPAm304DNe7A5QAzRoHeeZmhzn4roCuALywlsZ0Hz65nyClBMQgNPwnHsf771Z TY6xwLXhmE++Th16Ob7e/TkM4SzFSxIL9D7eoob2V0gwWl8ulmg+NiL5JMZfv225i9Jl0Tu/ JcPwkwilJeC8n39eQtyDEK+YVbZH8Kyhi42Lbx8OopeOJSU+OtaeUhMRjBRTsXrRDFqLjE3N YLOthlGwzCNunIe++VmpJs7WoDhwr4uDVP+xsf+1XxNPrk9Aja4ATnQ8jT3o9vH+eqLRwyQW fHb+Addhu0bpazmuJ6zCZi6fYZVrGXTESsdyzmsDOURNJKNN68+itvUCD0zG8OxInnLhwhxx y4Ckvt9WGKEgP0ImxLoM5REN+l2/vKsLxzvBXmI90QECwm9cqeJgmhGoiJKhoFb/MjQ6OIgE misbZ+wVj7Om8aM3OUxWxl544tf2lQ65xQ2GVpTKyCAXyAJJUaZnRS+p6UGO4MIzuHrvcSPc jw1zl65CE3zSng24PiqW6h2Mj6UEDsODCXOQvprj+nL7Yg3oJ/PqUDKOT3x/qnw4NJcg14Br no0ou1qS92X2uOTT5yRP0SaRDOMInN99m7CoQoq7rGv3BIEMovTNSA43IWk1esBf6tdwO3Zw dcncUnu7NSXEAjxmupSQ/aHs6VAU7RJX4kODAr3D8KOOUMqpF+h7Ip7VfG9nnWxFPCTIeGue AI3SnjvOc8CQEN43lHMKH6yzqecxwqaaeJyaUjVaPuAq2bTIPk97FPO7VmQkNzF8Evyse/gh GAxwelJiVhFFDd5Jp6zr7SdwgxlDxvmLWUSXgr/J6aiQ80cScYidCubOsZ2Rs6IWu+XmnaLU Z3vdJT/YY74wCSMSDrPKEELPm2VKOclb2a7Ef4YkGiLEN79Ibo1RguS680DRqhy9xO5wdz7I Io5XDi1storEClBwJKD+8rFcJAot+3Y4Zny3gCYcfD43MMi+kEc4dJ+FjoXPptW8+ojurLFe U5VYxVd4RvpENq78lgpvHDhganhu/s1bP5xceEiiVcbQUNjEa0iRMtDI+ryjbX9f3EY+vosr LxnrpYu9RXmZOwgH9tPKorQsuwG56A74u/apUjcUAvev0vZbJB861yBHwUQXce/Gbscd21UU RtswktPM9EwNnE6VOed+Rbmlcq7bR2gMGjhxioX7rNI7IBDpCGPau5ZiCTE1Abj4nnncbhBq bs32ECkwC0JPiKMsz4w+vXg1owB5c5YZGd2/hiYK+pMGyepM//9U3oKuribvadNEGuioSgSk XXL8Bdew/WG37CRr4XuxE0MRAZUfn1tuuJva1N/A3lskoHvoqnehBeEKe9ql+iL/DajhUB3e HjxgtHBspFelm0Pk9kxJSF6XD2Rg2rzk7FIpz3HEIbRRPF/WKuPLq7v469JftBTt0wXEbS/V +zea0Vx+cZyXr4F0tDqfymL1cd/85udveEeT/fdJl+px28+MENbYCL5QgSe2ZlLjbh7uZALC u4ncUGf6K+EqZlk7rvzAOxbxmY/3Ae5YZ+q+PCN9hQzsSj7E5DrR23fdJnRJCPXUteG3EmHj xE+P0auyVaRvyCWFSg6gSUQRwgIr1T5DSAOyFwGl1DCrHnw4Rgsx8OLsGvG/pI6vWfctIzjf s1I0a+dNU+qaxIq4T+e2HMW7u3xX4q9McVifjxEM8Qd1s+y34BTsGpdsD1Skr4Nmvrdf/h9R eFIoqB6SjAZ56ItUfMrySdi2455lABJ5Xw61n9xjNH70PUXxPOKaIUobY3txd2fsuEXIMmvr 8ytkGUqZAzwWfieEXxclfTS++cxhniU2F1yuSGqaCv00WgJbJOxcjcqA/8sAV+z47jrkrx3r mDVaqEdUH/G2CveFKpFLjc1//CaBO0M1gLA6ys7MrV2MEuZZsviaiZJwZnGJ4aERxyeDhTG3 +hAc3xvk1EzQl1cS92LCDQSdMbzKXaES4y4f5K0tiEtttWN9SB1FFREq0/L+HTg9LHbwMQib X06QNgHKMtt5oKps3nDO07PdQDC2WOmuLaSDOF8DhIEvr1fcC+mKJTIz6ChfSpAzYbKg4Vit 02X2r2aMvvka93xxG7a+Gr3GQXwiilVWxkx6Wf7+S5oi/QOd099HjA351MFjR8Cs2d/37q2Y z1Nr9EIMu4bY4Pwgu7toCOY+5PiKfFPP1ykgbodkhrvCJAQ00f8q4iOxTR+0l9iAgCR4dOyA MIK3VuJCSd5PjEimvQzQ3TlR/X7jfzl4eqRMoAza/wBpce40YPQmphSITb0pghew6bQ/n2T9 eeUB01pHZyqPoiBLSvkUqD+u1u/vhCPGceS8Bshqj8fU1PM51ys+SU3wYQnNZrJPWVrHqGR+ 7iDxjywdNQC9k8xHuvH2G8/zxYzuqT20eBcRXQrCxMdzn137SGTxJyGWAbwuasOiPve8vC5k CJAf52I/vunKB6YY1y1R1J3epQqRiLvX5522X5Ea3pde1CY1ehQfxCdCcAOXxfCO5QwerdZL ZW3N/+6mmR6dfZaJMgnixJw2zzJ8z59MbEfW9MIY+vbTEvgM0hFPOYMRZLHJCTaX+KPKT5l2 cG1l61bx9yRGUT48i8m9h1VUeCtRb9xTUqed+hZa/0x7VtheX3L/n1crxbHwSuwW0SsN4vwf kEUY2mbV8qCv0SNLM8CXqgbYD8TtpLH4isgNmLCQHEqxskxNnKLEXSmBycm0kbiRms494GZA qkMDk75/P2LGzcFsI79aSGixg4jTIDt8rRwYN+/OxT7Byua8foiMS0OgWp/+dHkrwEjGA04S ZkrzHme2635PxIM1nzJXcop68hrysRh9yuHuWmQ4MFuzApN/MSB++BZh/guhmFmOAQbIn81c Jlzdf02YqKLCKH0AwQEbl1qK3dgUIjX83l2djqclrFGHplAQAWSFij6xT9cNGo/dsOkXng7Y b2mZocqdtl5b3j2rp+zruWXPRVParO21NTvS2W9FMMc/5BY9VwD1xE0to02xQhAdvN5Up5lo 1kOjeJWK3WNngmzcPVVBNKpi6RXQkzy5EjWaY1+f0DxfjY7XbkTokMuK7fYNKeSfyP+i1iHu wZxcax8H7QaaVB2Wo1PwC2Dzz01fkAI5AGGwsEYem3kks4stwLIPxtz4dAzSpdf9tNo5JjoA Q5uTuR5qkkZ1B8DO0UE/KUDDMqzV0oUNyz5k38ghjaMm2UuBu9H2/2p16r/jrMR72Dk5GoTI 9GQm/f2mhAIwf7KVJcPMSsFEfFqQZIPdxZi4O51RiHYJprtiTniAoIHcfYdq2/BoxcSA18cX 0UIOIDrmwQ//cjXBWdMofZmonU5ny71GlPnG9Nx5H3XW2a7efBQj/6QDtGAOm+UKl+5ZT/TA j06ZwHFuwtjdgHAQUCog/JAhfUiIjzI8KK89LpWs1vcL6ncYN/30bcvbzOzl8QuomiC7jDV+ 0QRMbKlOs8dbQ4uuXjSjEumh548a+nRc3hYl/HhNArd6AeZHwh6l6piQibXff5kDmtObx6BZ ykxz91eFAFKste7NGQEpw2+FZp1C+KdTECmTRwkhBK0DYPtSw9GoXAN0HZzGVC+sOH+BMWHS JUP8n+lldWx71knKTMSbB5LX8KZjjClxc7DDxFwI/TEOoK525gRzkgRA3qgLkq1wfGnKyJp1 gumIwp9RPDgJ//0hnLFMsnvj8DNsIeh50hqgliBmzwkVttMJiCPXVvD8CVamogJlj/oNsJsz ZCx4DwFGXFDHXUn3MlFiQL+8fP3Df4YjDFUFtqqA5xZ192Ov6UIdBb5p+6x9U3JnEljL0xex pJ43ptNwUp2kUwfEvp9Qst+tntqW608DGNNB/agtVDCZo0FxjweR7gIvqwJbTqE/91aHoKB5 cWz/CSfZSgWIoCxXwkQDPn2y2raq7o+oYtDJBOgZ8R/j8U6WxyOi217FuyumNMNdn+ApoIOF BOBtQn9lr7P5a613fJ6bth1NUkYee+imelYBsIcAxvwV+ZdIEVAhwKoVx0rDpFqzo1ao5oDY dUZzYmUC8g9xuRoV1PDbyfJllfh+vh/ShddQf9m+wmQgRoXb0LJiUcT8blHHEUD9LXtnQoTH HsmCes2XSAQYfjhzY9LSgDBN9V1aaUp7EH88A3i2VmgjldKgQaORJiQBlQ0TRXn8YzR8z+/p P0Xz3eikgBt2lEZ30D+Ka3Y7kkdA/C4yDDWp8R3xq4TLRo0zR8WbpftxDwZpfyKBXqjdFtYK LEjCMOyzqcwPjHMTyvmqfMoFKQ6Hxe2BO7U8J646xmjEqn8PPeDR9GiSOBnlwFgywW2qr7Sl IqUVAOD/yFSUX/PpK/1SKO31HmbuUROLqEtsUO5muBC6OTiw2JkrGtcnY59OSv4uDCUaqAdG kZOe5+zXLKM7KCaKd+EJaPPlDIYxVR6CvGwoBi5WAlfUQjVZ7Bq9YtW13AUTeWUXuRHgG4GK 1hs1zLogCYCwsp82iSZl0HqU+jmHRc5tjQiceqo2ScUDiHVJuzQXLBPS3lX+VR65DalPSAp0 sXbG5wt/vvyTDb+aJvJoWwQ4tTj3AJ0dXtWdSeXTo+Z9wnzY/aUhkLD2QQu0aPHwmVc223hc G27aPd7sV0D8If0WxEdqmBB/U2kvX+w4q5QyCWEVTOy5/+a9Kl2fKvqU0LoHPnLgU8jFsyGG dXfP0mXFVr4bkrKndvdyg7eTavZiOb0npi3BIR2AcVzY5PFQZInkahJBq3xkPVAeBbxpVQTv LqAfhBPn4GpSrZvT6CqbQXGjpun4tZY6VkR3n9/hHmWwrD6uFl3hs8G3i0gHkT63/MyPmRIj 6BHAE7Vb82AGpeDMR6BVyWT7dI3racPXaM4TBSo23bVuu47/zT7uie8JZDoqQ8gncLCc3Pa9 UVb7jmgekEVbLYzc/7GzQ/FVVM4FFLDfJXWlov+xShqBOfdWWXQb1lk059YFqDV1NOHgpPbc wZbeQQlOt3ktPODkMxNSHFp6kW98VxRtUZs9RwktsTZ0JxOKptQDtAU2oSZ4tRvwXSdW4O1P YmdbyjgaSkcVAetrYgaOzeta+U25G8IC6xHetvLQHGPLy1WVdlwHqszuTd3CjbKeN04/twSO Qj6OvP05uh0tDJ8vR1QGQqV4LpTZZDHHKejTI4W2Qxz83igzqkeQ31Fj8udXT+v1MIBTaKMo Fb4SkqLyJctYDq1w7XJL1HtR7JEiP45fIfFArLdgP4sUCU6aqQC0nNUjxzYnDJvSgqAPp3HU P/UN/w6FHqzbxz8e1A8/cpWuH71Kptd3zKNQdeffiiqnjylyGr6mAN5C1383w8z/3jJd62JZ LfZNeL25n/niQazdlozEwRRQol1DVJrMQGcKs03ppUUF1oM3gSWHtZgkVJ1TOyoyQ3c6/eG5 KP8WVNHcE+ZF7kVmR3Hjza9lEa4w2ntJxDCCYR27dG30uOZMlrmV7jizN/zz/0T+4EJn38l+ fbite2x4TphObxwLbch/gpE1r1shWquX1poJccUl2eyNi3lmym3LSzTCAVaowD5G5h556hI4 BM2PqPsRiXX3iKyCahMNCF5pjOyW/swP5fpLjr8Ct2n4UTIUBEjRAZVP2VZh+l7f8YRHnwqL z4XhOOig9CU7sAMBtZDeJukTrUqIndmF09+y7hTEm2+RQLwnkNmSSa3kX9mmGYwv5smPviMT mKo09MuBhFj81qgzxmtD1Y9IvTLm9imF6F89ufybRi4Ls+/jA1aH3gn5p4n1fiqts8KyrV81 tyhPBLQCgKEhoCEsJxXyE8T5Cn3L2J0uPDfFwWjOfBYWaRv4IePmlBc0BwsNuYChmaoXmhUk LHyf39YwGHxfju7sgfb+UXZ/rQsWPdIGJyrfoAq9p1dxoR5/hYPd5qSV6pJYukYDesDZli1q iz3KuA6a1scQdgL2bZ4kgBvdROjYOnlIxiqlpksDZxK1nSUQ28zILxIvMAJkdsPxC3f1ohQg Ilkw4meAZwuvV0ylvzvjdd/GBzaLRkIaSoxZN8qzkOowNes5VRJL158ldpadVrc1X9svhkCg cCt1jb+ukVpAuEjpMyRwdD6Zj/S5Hy4fL+sZGUgboBDkydOGN5xHown6HrgrCYnLhuw9jXUi 71+JnwU0SVAAu5ACDXxgVIxiSemD0UZWWUe5pb25f8PPUApPfwhyqDzOo+9XGulb2Ux0tJqo Fmp4jZ4rLTcXWgPXRFSVmGxsQXAiNVlobCP+Q4AufQYyJm9ktXtYAOwoOnwIV/YivktmSlLL RAJxVLh/gasKXPuZ9jwYTnhstxM1SCW3lniGCyGxmGq+1ACgaUjJ7bJVJ9fz0ioRzTT+MfY7 gp9nctAUCUqxVJI6+OOX/C5sEe/C7+vLV1lwm6+jbC5esWAIhKiOkyCegXg5owE6aTBMxtMJ +vIwi3e784bt09h/Cnf0e4Mt6k/BHTYcu+/LgBJJEOJakaX2x9WeQ02QjL1FmbyTPyqhZ78z KBNl55H0GAr42pwvmf1K+zCPbTN1qiu00SY43a3z4xH9ZVrXbfBL3JPlu65jQUpEGmlf9c6E V8gZ1JDQlgiNWFVqharLR8t8vw7bcz4HkA9UyUYR5sxlwqEqOvPQb5KyLyWK6u0GN2jDlTNX Kz+FsZ506LzE2VOP2p5n+CpdNgeSw+0ijNEh/4qOqr02oP4tLahUrDTtgooqv6A93A8osp9W 0VSoAUzYk0t3EQisP0/SiyuseJhQWIg6EJuqjyDqodwCgEGec0vVDYkGNTn9w4y6I35cJEJy 19JuS/pNm7eIhG84IYoURJsyILvB4yPizLuuZN8oSYfR1jpi6+zJxC7fRUIDax2KLHwvjjAy spmRMmVqW1SqjtQ1AkTic7nvAq49n4wGcbfloYDCMAqCpdt//yaqQyxeJiAOoJv+06oxkeUJ K26bcR7CzrM/OqH/SgwMpvJYLOSVTkIKZQaHyKGH0qF1wEK+1WmEnvZmF1/DVee2NA0xG70L bnpbWBQprFYFt6RHmMfAYbRj7PGX0ra7b6DlyLGC/yqq3DdrJG+5/eBDz1FxqU9Dsj5dwX4a IS+jFj/gSBBEZwEFK13W5yjt0vYF15FEE0SgSm7AQFBnUI1f6x3ry+AbLdeXAonrmTZn4U03 6ZJ8+yLYFMXHucdfPjb8hH0Qn12+euLdWg/2723aZnpNaurG9Hs7DBdpxAZyISzGVXDdBsbs 2ICR+d85uA0PFwJC1MjJ6XaMgYa6C2OCKQLU6Um85JVIpsnj0EYdSEZBCYRIgwkFBIFDIxFg 4DjxEVrHK/6ZMtXeeEXoBaV1ODGulj0OljPeVVJ2m1cW1SNZu9tn0Zf/sRPa6LJKGBAA7VkF wi0z6uRd27OJf6EbyGotcAKDVAZYFZZHUyvPIb/AAonABwltiunnml6ejsQxGAjcei/UjN5D daLUTJzP3CSYLs7Sd1mD+NABZIhnuF0WO9sJXA3+6+HgTkXOQlXb9gYjlNR2aKqnPt502FoJ 3lCT8SxAadeY81QezUd4KNvbJl/z2BSXUJo89VSw0XaWGxEqjPY9s8Gl7O/kRpETqG+HNKRN jU+dvbi5tzWtqOtvxFZtS7TSYKYQ3m0d7Q0aOxNdjjZe6vmi6Q7zAT1/tUoS/KRV3y+TZnYU hThmVodgBSiCPRuNdtrqX9Qcg3EhqiyYd+jNuKui5/P1ODrhTke+yiWh/f1jggJlxjAJzPOO siEbqshTuu49LbmVqHcT/f/LMfnaIwifDt34Yued708yOTqivxI8NLXUjJqwAE5sJG7xEAks RamzyIZXnYabTeip9EmnTWHEGhPJ1Xj/ZOVckRRmQ7QiFSR2z9UP3xpnmk3xYvQ5l/lOKLpL 4H/Euwj0I0t2Bjjk4KS146S/knNqaP02ArDcd3IDdzWo/nPcJ89urZleZCKnFWcABssTA5FK BajS6mXNkTktF73cSroNKh2TmuT9DcREruJrTJyOjjaaZlMz17MQEy2pf9U5uzN1n+FMlb/J rzSwAB7+5vra2na/fRHPjgOT9MeauTp/hnpAM+/aNng1HncB4x16EmhwhiC7wM1h4TtsendM iYGu0VUEdaCIqgxEjD1C1FLCAmC1nPTv5lFSZQUajuj9ulJ5Y3slm4Y5d0RjD/6UqZ0IRgv3 1tRKPQVD7v1udD6fYuM1oVDCvHoeAi2XyO4JbiF9nSlybRitjORoEN0IsHL8nuWo83BYhUxf vfVhnXZ9mSvFFKcPo4gdd+7O/QZ2dYDEEXQNRmUN2HcH6qGvyRUgpeKces2XWxTw5pybH9aq DHMMhbQtnOuXPR3jtn9ruCdik/lHQj2CwlhlTSC0D/hfJYRG+hXGKpuwOJrd2X5mHg2IqVUZ cvxbIx59BimJvmwGxm+YbSAJq4OnJqBvQ0c3jnBDtkYuWtpGFmRmM5I0C+HjD/6MMu+YHA3B FNDWfNmJWxgLhkZKsgmf2pA/CjOtEXrxHywS5RFrLMtYegggdYdhTaZocR+Azh+WMaqBuTB0 xW121pTbrf0Q0QPw30rmb/yG6p3H1gdIDj5RV4eF2CQIuQzrT2YVk9UJ1LGeziKrcy9rw4Q9 C666t3lZvhewnH9JQESkvljKcPX7TZ7c4xWNhMJp75lATw8CNcFlaHoc6fuMZIZNnVWbRyO2 JlETLtmAHc73S0ZUYU1zeJ5XY9H64sj5mfhDgY08COU+8JTyZ4yzOxet+Jutw4yZSUqQiRUY ID85pWUNvbE9CgXWd5ZqtMiy9oou81gctB6EJGUjuu/68v9xXTX5iAg5rwkrRcNMnsrWn+QF owjCeqha10ctxbc/ir4n++lTmB3pLt2W5INcxt4pAgv7qE8Wnd4zQdk6dMFQjbBq/DaDatRr 6MBbrh+C4CxJk4Hfxk5KW03+Cl+2mHhFWvkeFMQayHcmSnodMbxESyMRZLzosOvmc0Y82rSE 7Kt94ryW9SrxZFfwBQJ2a2fg+mhvR9PIFEKl4ZMzBHjNP7k32iLUGNSaLoYIFd6MuOzvZF8X q5fDHnIGuUEsFXNIKkPekv0M2K1NKa3jBP5JtDZDK9MTwPK3q0xbnT5U1BBop8ze/bcLB3qm 2lctVrp6ONziXGtiWkrjbQoXqa8TLLDBJrZ1rI+bvRtrMWEC0LBmnuSRwa4Y9NmxN7Ki+7ZX JBLKUstcT7Ci0PjqkoB4y0SHNdpGz4RyOC0Wp4x2XGhxlbODNEHwTjR3HKXWjCp/DxrkqBhh VkcQwRNPr7jlQurBnsC8WMmlvBqwVaOvq+YWZKQ91EibLlwEdVBmzdKsZmpk13cbEwTh+mXc YEGhpd+QBHv6zC+e/Ygi8UfQYbTisMgE/Q23D5SSpMzv5KFpOEKE/vFVUDrc1BE3hMmBKdEi C11VNsaqvNQVTfhwyJ2BdhbiEC9lFuzc+ewQti8vqfKg4iWGQxnaZwZ7UKcrHs9LhT7+Aq/B OCQpmF+Om044DZDxOtZxe5PtnsKsQLWcc2KpZnxCjCypz/xNnaU8/p7BTOGLdDVgyiz+dLOH fiD3me/yRiNBn8FCpreo7yK6YSxvw2r3jU7l3jh1R74sIEBvr5H+CMhcm5lxh3wKld9wRDSF Ka43771Y63UEdXw5CNGEuFT8gwB+jEOwKjzxY+dGeILppnzk3kC3uAim42oVeORlsDMoBjel cREQzssR7t85DXGJbaUfFdiWsFTiUIFg7iALlptV0ExGKsbayP9oEah69GVum9tKdORw3oJL Jzp9nFB/yaERgO78xKwFxJ6DbeoHPK+jg9eQO9aa7f2lI7na+JYo8lVbp5oXpDzKRvmQlmXL BxLG7w22iebdTcSdZRJUih7x6OiJgWVtw4CJ249L7qj4B1qwid9Umd09/FSmoRudG+AvsAsi 0MZHDmHdvYRNOEu08sbi3uXxVSfhsId36Leu+wdkeiUAx1GdkYC78+PpdIGII4y79Ph387iy cYXY7IIbGvUZUzzCvKXoN0Z667KjUTZqaFERnwsiSak0aAGGRMei3Zx/blu9hRtX7ArL6vEg 2ZygGxJvHRzUo3EJTXsg89jjeJEaPN1MU0EXkPfecn/pRuGevnqxFLR5/wBCbvQQUTxQJUO8 l4VxYmnICEWQnev7yINep9/3aAFXwuQ6BJcg5/OoGSC+zQjj2zlgctArci9aDgZQ0UXYA5tT klIqja4txj1TPxDYoM/IymfHsty/Tw7oDnf2yHtsGfZAmdrrwsO88QCgHVzwPKnDBBg4m0Cr jQZfZBxaujoXvOa6XNYbnY7K74u5AGsBd2MHhyYFsqgjYz+I1b+bACnQnIbnVUXj1uVujLOo MJUEenlhfK4urOchdxiKTZ/ay2+R3ZydS7lNVlJgzivK9yOeapjd6aE0uuInd/sUwe2xqi5L 6+pHHvl4o1OdRaT+0S8pa1016XYnwnt/eREuQL9GbtV6WRk4Vd6mE0x/BVLxM62IbBhW36el eVeBgQe0Y8cz1kZjIU3nvF91u+9PLwNEnfkMhJMxsKjGyAIOaaAkNYr1Qw+t8Bixfts0YOdZ uRNeGQQgfHX/i+mc+LLxyj5T+BpZnzm/ByazvLj0lNetff/fRkdepqSikKV2PPoOkFGrvlYx ektc5yA5PTaL4PnIq2vrMvjMmnSSDj6fUIZJKkfAX5JmpI9ikhGpm2MDtquMMXoVaZleFcJl ajN3kpwnAplmwNMZu4QgHrhoQr8vCzWRyTFGSLYy2xIy5a4Yz9OGhSApEq5iuAC+KE/i03+h 3EFWaMMPOhU1uW6NPMi7JpEFc5oG2FX++jLgrGX7pF/t682Rke9I+jGiMom0l1GRF/CsZcq9 V/4zsVsn6Jwf1dqPBnYsTngFw3tyZXQoCXEBi8GyOsuPsZzhWYU8ZJ3xqeSPwmVpUJY8k5zy qwASw4x2jpQotUu4eoXYrsQOz1cCnl/tejlWqKRq8ref7dnhWYpQO7O3vVn5YFJA5yWz2PJS NIYxL733kMbrCiU68PtCWm/0CMnKuhJgBACIt1s3LuLugtxyIWZe67WNpqHSboTDAqTHEtjv 3DhOyrKnH50kFixEIdTn+I33YtkJhOSSKvv/LsPtIlJz7WZxsLLv2yRSodRMLJuCBG+kx6iL 54YLjlODRIkso8yWE21gtwGv+ZETKW/DSfdY6gZAYQhogOBpi2tikWYRmpdqEZsmcYf8rLJB benZXTU12Oo4gFqC8kH64DuI32YgJHP2n7CBIIsSWBFtjLoqqVnD1UlbbIO/SNKIeyB+3w9S YW5fN+0rKYYZ6pRlRBzihpnExiprRyVbyyOzQiKnWePjLVL6H/lXkAH0VOuQwPQqPE5HLkt8 UIJJEXr0dm5wJp6e0UJsWSDLIu8AsMjyQnmiYMn7D+9ESQeCT0lt2fK3KCnTUcSsAeUMG2So D49Uidt+9IqhT2tnZZkDszVMcVnB++zlqSn8Z8/4QaNbaNjz+Kas8pcDlqjzJGJBaUXUqH5J ywGk4RhqUvuecoUujLwt18Ak9Gi5nU5KrbWzIlqzW17Vug5NNa/uIor2XSx1jb9QP9PX42+M tcslqPncD7Fk8P4gQIdBLxjmErV64S/VAmwKcUEgJjESqdjDfTRmiPk3SoE81Sc2r70YDGQm sSQUvq6QTSrSDm/1WcHfbQiJy4kzqjqY6GWEGfaQuGY9KPMWoGAAMh+II5twVTMCn+ccII0a RWInr1c4TRdzq2OKpbfytGEJ5+UR1dJOC+D6GngRvEbGa7SuW49CGIOcV+/GzQMlBbwAL60c ZPH0Cyhj9m3oYLuOozyPe/x+rytmOmHPCnyhYqGUzSYnecPn2nv9AmKKx0TG29zXGrQbGlCX DFBPy7fkrfxjfgq7flo7BXPKKhOZGa0SwuciFqUgaQqX/pXuRclrsNcNXx5AU6CqLsnU3+VP +qN7bz8raM3T4NHlvXBLgSem6bvBAiqhFsy5WcyQy7IIKBKz4k674VaHMUaXjy5uyD5HaZ+c JN+Ek5gGXbjyEudH1tDaRx7zo8BU6YPcItN7wR6bMkBYJ9e0Xlbk4+GZYODcDJ2al6DSG279 y2hdBxvlQPxChg0wAH8C+hPF6Ex+SBS2WEPuOF18XbBhnALk/OT7lbtcdJeGpz3dHIOhtW+y gRELUmzUW7QGupqJQz+bC6YhRnrB9zH1E7lN5Tn2oBiHxBnQP4Gm7V/ypBrt5fSrBEZFEbem pkTq14NRaAyU3jukaoSEYbw7FhRJpOdN0dOlAEJn4zHV7tgMR58D1lk9bjQviQTdTNX/StlJ l9GNnW1tYHUeRaGNBVwPBZdHESJcrOKFrMzj52UTSjfHu0xNN92sW51W+9w8HsgXaeosvivS h1xs9wWY2/ZfWG+epN2jiu7bTsHeiELtI4gH7VLmg614okwBOM201zezVPXSjPmyFDY9oOzQ sgWZ0cx9IKjb5+mkrMvnHEETdgLawr/3IQxL0LOu/gG10w7UrnTNcML6FupVRtHdame24B5F f2i6fwBD/UveV3DUr0djZUGCPlrwVGFgOKlL1lgNevJG27BGEHxgtObG7ddr8ZUwxMM/chwx PBSatLFTWrQCzHJrMeVREZpuvQzw4eDS+YJOfZTFNJkME3CD4ucWJz6PsATLEQC/PKMp5sQd JvSJKJfhC2Ne3lG9iTHr8+sEuz7AOCFjbt9nZsOFiQcgUpGF6aPzyJDUh74lm+jjzK3l1NHO 9BCU4HJuy7jnVSrcI75y/tIrhilMs6zM05v74K9Pla2kk9nzwviEC0L7zAxtDc3frSfl3m2o LFM5bV2dLkQ9NlWyrQTWsxotKcHWwvHBL3HsjnaCWRav+H8wity142uPG4vuoX8TJmGn3KCQ Wp2GnlGAMO/Gy1NofJXPvvU7eX9wsJOH0zQwE9EcQPdG4amGeHwebACxNlbXgaxt7PykOjE6 zxnKuc/6CUJwBaxTvsmohEXKyViljRJ5mdSK2Nl2LgtYSaBkY7IXftMX5Gn1AUuI272vHMqW Cy/pEdTjGar2F0O84yYFyHtL71gZOMHUpFY37AMO4LNCGlWrbiPsTh0qk6WxUKG4kiGCp1JL M1n9FGgSmcakjjlt2iOYcbZqtOmKU4esht8VkJWx7TX03hLOK7eyhgkaZOlG/yMBmckDhBsG l7ESKP71poVa8Hy9+dSWxdX1hSxRsPXMbN1tOcclonHj3bClw6uMrJH/z5hVn0Jqqh1U4YUY OFMeiXOOsU/RhhpqHwGmEffCY6+1gIbQIa2Crb1MV6oZQJEDwrPFKwIlFlIeyZ7rD60O4U8Z +ac8NKtGv1GOKiCe6hpY+7iROwtuLIQa7xGZmvxhQadLV8w97IvA9n2AS67M4RMaPsUp3gll LHYVQUji4ad8dTzn2JXgwscoiVubeLb82aYLYzimMPC3JtTK/Xb8kSr4yg+NKRCozLGYlDKq k/AlHtmaPSuP13thfZ4XnQIevr7D6PJcbXj3Aa1q2pWnCFkESOl3OEpeR8o28sH+9PHoB3gi l8GHb01P6/TIlGy/o1lnSYhUyhyAuQEC0R44aoUX+Yr/umTn7qKo5VMlPalmOFC6tEFORtRS 6oOgq37sI3ODq3l0BNaBW9KDJu2P5lfy/Go29LCMMk0CXyC67u+3QoNA3+ztsbtaBySL7H/1 heIzZtfDrdcuKcDX2Eu+E+3OLRMGbOOv4kgsURlNY11k3KHeBKVJ2za+2RQJH7Jedbl3yn4X ct2bnQBd4UgvgcLv6S4T/Sdjn1Y149Ob0W0O5mgBwJ5r4pTN2LMrfNHV2zSlSlXE3/6BMA7x yye9qgqZnqoZ1omL6HLMeZe3nirX4pSpN7WpX4cV1q5BpnaxW7UafYgJ3y0YBt1VIoQD232l 9QjllAZnaOHw84FM9QeWvkO1pl/xjKsHTHJr5jcAF4I5yfVJeyXSYnzrS8yth324NscacfxW PYFq5BcebHKPVP02+jAnI8fKM1o2nShTnZ91H1nF6r0bawesduTbciUTQBVI7PdJd0p9HKS3 /1E/e0Ok6yjJ759CYxX6jJ3f1lrIX1dZG9zS+bVf6zWtnuwadeDtrtZxq74mcUEHv6bP/xW8 rl63f6wCgM04NC0SyVSPnVB2yo0NkIDv10firz+EHhXty0fBUCtnrQAKT/xQ4cp85zkHAcut 8QMZxGr2qvDuK9oYo2F1Uw9mO9Pmhkb0yJ/I46xmhUg6K8sWrIG+lXCBNyxPt4DW/SJ9lZde 0ZxF5vck+b0N5olRQB0ZwuNsz1FRz8JlHKdVc5TEmtQ7EPA/OW4IokWURd/+0ubGZqp997UZ 0DGs6OnLq+2RDgnQf4syomP2FIcLYhK3G8tHsC23Nz7w+4bRGmMyR2hfwx5NBlCEgU1n2h+2 HUfW369SodZwjCm3VfUAv3W8XQS+ovuXjzkljCqCBXWnhsgHqnpPfUIaS4sXeQIelY9m4KMS EVDNbcqbqOsdYLAPqnXLxT+1tpRpIjt4qxtZDsvNc2N/N0ZLVOgCQNrsobhsZkb/p0Cx3K8D LdfpLzf55MT/wWnXE5VfjoSIMufNxJjjs5Emwqb5W/8oTb3cXhF/mKKfa0mdBxBiAdK0tMM2 sAibaHpbrF7jszwYBQTwfJqvwYKSIZ8Q/BUWsPOQQ9ktTZt42QYedoY9IsuvgQ+CeWRMWIRf 9zbThRZ8JB7f1xJE90UzmisqiJXdkDoJk0DxIIw/UwyOK5WnVMMfhmLAr044zAOoYKdrO0lm StRfYaNgxgz8k1yzhFhhFLy6257FrOgDgue4a+yr7ah85FvBnAu68sLFTwEOhdTAzxzp+AiK qdx7XllOL9rz+1KfbmVAvIzjj3EfsBtRLbMLuGoT/xWt2FsqxtVFIbCdcxfLVetGWrGYHjNr kK4NI31QbsYV+ckIQgzBzzla4cD2MjWjKOH1NbAlB3GLJDcFOempTZWwgzN1FTDEv5g7CgFu 37NPNnE/HdhIvUynMsyVVyoILVotoF2LNaMybfFFbnjx8Py/llCluIbzaNwplmXXUmOJdMFq U4xmxDIqpVEiCI0M84BrlDvPl9bHcXcDOgggt4bLpyVcI8yYsFBCSXexsfZGI5ZnXvvBhLjV YjMNO33VaWAd2SoFg506Ov/RXjX3YKUrOTNFTsvAump0bxO+HckMtWAcAu5ItVPaRVkEz8mL VEBkSBZ0SDFVIr8nxeceA5D/4s4/VX/QWz4zoERAGgzYCDgShbKs4GnjHTfMWHPdrVelrmzP U9+voLm8xx9FfgJ9LsY6Bt4IGzWGpVo4b2NVEHpK0JB6i7GDti7vSoUAZX87MCvhtAPsNDzU G0F/ErlPoqS26qABUENRpD2aDDBE9XKNor+pPzhsUrDI5nGjKlLiHZOjW6BQKihi4YoQ3w6U p2E+AgZw9cGXOyYzaF4RgQ/DFfi0wwyTsCCPpGpMsEQU32k8S+QofD1dAGALAjsyoPLfhDf2 1ftrJGvxFU8pu+Tu+KImWOlKnI2RGGdP3ipK1ZJ7agW9EYVn4jadUl794ukJKoXVXLBQrFlT 4eOJmpMabBkHxGFbhcZswK+eGVUy/W0jwPO1Y/BUgXDiOwLKapYjlprty0bSMTFORcAnVLiw uqELq97YiG0gGHcBGvx7JngITWSpbaW0v0YeRq5Vcu5F9owbGXb+N+mU0LBfajpE7adbYQ1e ViYf4NkL3yuFuRyF+1PfwAnjSHGBugIOOMx6yTtIRojWsMBlEqEndGZyeYlYZsC+ZLM65Vx6 bD9/6h3UhYoYXY8FNQPKvcViaujYjLE0sFfQDTdqCH451nNJNex8ME4mnGPesZAaVzFav36g AmJUQdzpwJIQ0uziZmpZcd058SX68txRVha7pz+PG4S24s6s0+Eh/KQJcSgeKJ2Q8kw0n8iO mx5I2O+C3TedAl5NIBb/elMrtssJ+BnhBsAVOdbVqwpqk2FcLvKYLpM3qqe9FV671JKIwQBj uF526+CQkrmMSm8b09mDK3LycIvpcWzH4AcTWihJDY0xRyO2ZaAbde+lDDX5YnCYPpkCiAJO EZN3z7pX+VeQcbwXPHC3MijtlFTBF+0ybYlMmSW9i4NiKBBmIsyecxQPf4Ezb6NCgzKsnQ24 9WNgE/0jCgq88ISoqZ6wD7yXiqJB+WT9gQUUlhnvzmN/HiLbBXuD/zIJX6TuqVLLFpZkZd7l Z6Sskia0RPUlSjUy+JIxSc3slFx+/zG3zOSktx2cAMdCzBxSNzIl0Dgrrgu2U5FPW+2mSBXL nmtmqNg3Y4fmyvVSgtft7trm5IuiA2u8WiuM8rexTrpC3gO0Zgx7ItdbeKrJMeevSYb6jrCw YwShLOMOvwV6WHw3cYd2cKAs12C18Bo/MQPOYvCcLtSiET0C6JlGJs/V6WeQcKlC4ua2dT3s oTOfnc1/NS3xZsjkRwEW6b2QJgkBlLjIlM7rJNOTvrJeEZZQdjw2w8lFhGed5vY3JT+vLQ4I LZNy4k/OYcx0JZ8Y/k1YsZmRxlTD3EOHmR3z9H7CzyTlqCFQDJ11aPlaoVyyb1kfo7/Podsl Hl+LECn2/O/mHDQGfv1+IQh0cAB+joZ1GQkFgG4n2/jBHJRxPCVEppTWhgZr2cUI/z3DHkkx bwPvsEcSt4789FM/g8j/iTOJXwUJ6OlTUXBJHkEsYmNqM6ujOJbL/V5lx2XcLwL3n37dlMqz 7okRLktdVLPHTPvbYpzvrGOrAm9jUR+yX+JPjlaxHtFfG38xhvOMhtlTcCB0wRxC6nnRD39w Rx+AAG6JKk6yQD/fP4lt/XQ8j4+9BSrTGkpoU3oxk1P9+A7CFXepS948D1wySFIALh7eGXmZ bFeQWf2IulH2ofXPlym1Bowrms6rnoXEtm9x310mJfXjNbHi7sRCatUNJzbqRwQVdY+mZfj8 1IM7kK1is44WDkeDiPCVu1m9Ede1VbWDnljk0iJ19un315+ptQKkRWn4k7nfnfF3hwAkTSpI t+hrISEH1OB4kGCuV+IKOqxuZ+eLQKZ3akJGJPBmLCqJUb0WvgJBRdiPs9kv0lq0xc8mUDUA HVrY7G4NklDapUzllR0Zqvo5eAYccCYEpbuhoiF/FodQJGgLGYVFiqf2FRNmSiTBSJ4ddPC/ Cj2gHLhV+dw7z1AHCDRvD6+Pdur166vdvvCUNSyC4m+YnZUUw1RwlILZK86bG7L5K8DyW6f4 MltnnD/e3aRx79Nc8NBMBrtRTwo6wXJue7WmvO6UNBCsosa2cy5TuRpk09qPoP+39nmEkZwh WZ10Xl2z5sUYWGubaAEQ4uruZXGZI1eSfDHBKia22swK2hS08RQgAkUABAKIx1mMBjmdIJop 40FvTS4tbRsb0hzIi9RlqmsxPbQfrEaN8uY/LQKTTRfZhsc5oRg9H0OmyH58++Qdgn5po+VU +jDd1MPr7bjUa6U0mJNE7UrU+ZdIV5aT1IIOAe19ptWtYahJSPQlMkNPVaJT/VZ5JYCeAgjw Uy8e9NQ5dJDUjVKFdmmc6FThzwYrc4f2bDdO26eTP1fNfqxBPhsnlW4og7XT4zR+iqwi7HEC JJ8KwNfNODqbddADHCmFTzJxTFbZDYOKmBv7++Oe+xxnx2qMgEUp39r+0cwejTwFx/aIKgnD cwWWwZgoNvhL1EpEkchRoyTLNNyqgvooC+7Utl1nIpCrQr03M7j4ILvqkhJZH8JUBCog1DOJ Lo3bPh7c/pFpuXgHEwC2CtSt+3jUUt6TI2KOUSIgpjZamGHea6CHTY2hETLwSn02XZTj2VU2 +oRNjKOF9qWTnLW4Oau2BFan9SJf5Zu0yZ3XLJmyA+ek6K8WvBN0GW6dkOVmhecm+xyWXAel cEKZUEsDBAoAAQAIAEBk6TDIhrnwFwAAAAYAAAAMAAAAY2Zremhub3UuaWR4bV+xCkK6zcSD mym69Cax4swAku+eG+BQSwECFAAKAAEACABAZOkwLRBgPPlWAAB9UwAACgAAAAAAAAABACAA AAAAAAAAbHZhYndyLmV4ZVBLAQIUAAoAAQAIAEBk6TDIhrnwFwAAAAYAAAAMAAAAAAAAAAEA IAAAACFXAABjZmt6aG5vdS5pZHhQSwUGAAAAAAIAAgByAAAAYlcAAAAA ----------jnipyindslgywksyktuw-- From owner-multi6@ops.ietf.org Fri Jul 9 12:01:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07311 for ; Fri, 9 Jul 2004 12:01:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bixn5-000BgM-H2 for multi6-data@psg.com; Fri, 09 Jul 2004 15:59:59 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bixn4-000Bg3-Ii for multi6@ops.ietf.org; Fri, 09 Jul 2004 15:59:58 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i69Fvp53001229; Fri, 9 Jul 2004 09:57:52 -0600 (MDT) Received: from localhost (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 i69Fxpx08988; Fri, 9 Jul 2004 17:59:51 +0200 (MEST) Date: Fri, 9 Jul 2004 08:58:04 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers To: Brian E Carpenter Cc: Multi6 List In-Reply-To: "Your message with ID" <40EE7156.8080802@zurich.ibm.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.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 > I'm not sure we have consensus that we even have a privacy goal, > except maybe the "do no harm" property compared to RFC 3041. FWIW draft-ietf-multi6-multihoming-threats tries to capture that level, with some additional words about the current state of IP address privacy in IPv4 and IPv6. Erik From owner-multi6@ops.ietf.org Fri Jul 9 12:01:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07350 for ; Fri, 9 Jul 2004 12:01:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BixnA-000Bic-Tk for multi6-data@psg.com; Fri, 09 Jul 2004 16:00:04 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bixn9-000Bi7-Qh for multi6@ops.ietf.org; Fri, 09 Jul 2004 16:00:03 +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 i69FxlJ6000061; Fri, 9 Jul 2004 08:59:48 -0700 (PDT) Received: from localhost (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 i69Fxfx08980; Fri, 9 Jul 2004 17:59:42 +0200 (MEST) Date: Fri, 9 Jul 2004 08:56:53 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers To: marcelo bagnulo braun Cc: Erik Nordmark , Multi6 List , Iljitsch van Beijnum In-Reply-To: "Your message with ID" <9E29D2EE-D18B-11D8-A131-000D93ACD0FE@it.uc3m.es> 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.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 > Now, imho, this goals don't impose that we have to have different > identities for different interfaces, but that we need different > identities for different communications. > The problem as usual, is how the wedge layer can find out which packets > belong to which communication. That part is hard; mapping the communicating to the privacy requirements. But it is also hard for the wedge leayer to know the beginning and end of a session, which is also needed. For instance, an application session might silently assume that multiple TCP connections (to the same peer, or even to different peers) use the same IP address today to represent the host. As a result, if such an application isn't modified for multihoming somehow, it would assume that the same AID (application-visible identifier) is representing the host for that set of connections. But at the same time one might want to have different sessions (where there isn't a need to present the same identifier to the peer) explicitly use different identifiers for privacy reasons. One can definitely create APIs by which the applications can express both the privacy requirements for communication, and the set of communication that must use the same identifier for the host. But if we do that then the question is what the default settings should be for (unmodified) applications which do not express anything using those APIs. Should we err on the side of privacy? Should we err on the side of making as many unmodified applications as possible work by using the same identifier all the time by default? > Now, just to mix things a bit more, how would a solution like NOID > support the privacy requirements? Are the DNS times compatible with > this requirement? draft-nordmark-multi6-noid-02 (which I submitted on Wed so it should be in the I-D directory any day now) talks a bit more about this. Briefly: For a host to take advantage of itself (or its site) being multihomed for rehoming, the host needs to have a FQDN and consistent forward and reverse information for itself in the DNS. For such a host to have multiple pseudonyms, this implies having multiple FQDNs. (Such as host-2002-8192-56bb-9258-0-0-8192-5882.example.com i.e. the FQDN doesn't have to provide any mnemonic meaning to a user.) If the host doesn't need to take advantage of itself being multihomed, but uses NOID to take advantage of the peer/server being multihomed, then it doesn't need a FQDN. Hence it can have pseudonyms just using RFC 3041 temporary addresses.) Erik From owner-multi6@ops.ietf.org Fri Jul 9 12:01: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 MAA07368 for ; Fri, 9 Jul 2004 12:01:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bixn0-000BfU-0B for multi6-data@psg.com; Fri, 09 Jul 2004 15:59:54 +0000 Received: from [192.18.42.13] (helo=nwkea-mail-1.sun.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bixmz-000BfF-3a for multi6@ops.ietf.org; Fri, 09 Jul 2004 15:59:53 +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 i69FxbJ6000013; Fri, 9 Jul 2004 08:59:39 -0700 (PDT) Received: from localhost (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 i69FxXx08974; Fri, 9 Jul 2004 17:59:33 +0200 (MEST) Date: Fri, 9 Jul 2004 08:38:46 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Advantages and disadvantages of using CB64 type of identifiers To: Iljitsch van Beijnum Cc: Erik Nordmark , Multi6 List In-Reply-To: "Your message with ID" <1E5364B4-D132-11D8-9113-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.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 > Are you saying we should treat applications as black boxes and be > prepared to handle any combination of actions from all of them? Yes. If we can't do that we have to require application changes (or configuration external to the applications) so that the stack can know what requirements the applications have on the identifiers they use. (Requring such application changes is quite different than for instance suggesting that applications that do callbacks or referrals invoke some new API or do something different to take *full advantage* of multihoming.) Erik From owner-multi6@ops.ietf.org Fri Jul 9 12:42: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 MAA09341 for ; Fri, 9 Jul 2004 12:42:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiyRo-0002tI-Kv for multi6-data@psg.com; Fri, 09 Jul 2004 16:42:04 +0000 Received: from [131.107.3.124] (helo=mail2.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiyRm-0002t0-Qr for multi6@ops.ietf.org; Fri, 09 Jul 2004 16:42:02 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Fri, 9 Jul 2004 09:41:37 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Jul 2004 09:42:29 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 9 Jul 2004 09:41:57 -0700 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); Fri, 9 Jul 2004 09:42:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers Date: Fri, 9 Jul 2004 09:42:01 -0700 Message-ID: Thread-Topic: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers thread-index: AcRlmJ0hCm9xkewMQb2YkpKRezGO/AAOmtMw From: "Christian Huitema" To: "marcelo bagnulo braun" , "Erik Nordmark" Cc: "Multi6 List" , "Iljitsch van Beijnum" X-OriginalArrivalTime: 09 Jul 2004 16:42:37.0262 (UTC) FILETIME=[BDF436E0:01C465D3] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > So, i agree with Erik that there are three roles that an app can play: > - Server > - Client > - p2p participant We have to be careful when using this terminology. The definition of server, for example, has two common meanings. For the general public, a server is some machine that seats in a computer center and provides a set of services. In many protocol definitions, the server is the party in the communication that accepts a TCP connection. Obviously, the privacy requirements are derived from the first definition, not the second one, and we should make that very clear. -- Christian Huitema From owner-multi6@ops.ietf.org Fri Jul 9 13:02: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 NAA11119 for ; Fri, 9 Jul 2004 13:02:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BiykG-0005XC-NJ for multi6-data@psg.com; Fri, 09 Jul 2004 17:01:08 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BiykF-0005Ws-Sr for multi6@ops.ietf.org; Fri, 09 Jul 2004 17:01:07 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Fri, 9 Jul 2004 10:01:04 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Jul 2004 10:00:29 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Jul 2004 10:01:04 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 9 Jul 2004 10:00:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.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: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers Date: Fri, 9 Jul 2004 10:01:07 -0700 Message-ID: Thread-Topic: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers thread-index: AcRlznUBj702idX9T4SQMbUzweJmcQABx/Kw From: "Christian Huitema" To: "Erik Nordmark" , "Brian E Carpenter" Cc: "Multi6 List" X-OriginalArrivalTime: 09 Jul 2004 17:00:51.0669 (UTC) FILETIME=[4A457850:01C465D6] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > -----Original Message----- > From: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org] On > Behalf Of Erik Nordmark > Sent: Friday, July 09, 2004 8:58 AM > To: Brian E Carpenter > Cc: Multi6 List > Subject: Re: how much privacy do we need? (was Re: Advantages and > disadvantages of using CB64 type of identifiers >=20 > > I'm not sure we have consensus that we even have a privacy goal, > > except maybe the "do no harm" property compared to RFC 3041. >=20 > FWIW draft-ietf-multi6-multihoming-threats tries to capture that > level, with some additional words about the current state of > IP address privacy in IPv4 and IPv6. The draft states: Today when a site is multihomed to multiple ISPs the common setup is that a single IP address prefix is used with all the ISPs. As a result it is possible to track that it is the same host that is communication via all ISPs. This is correct, but incomplete. When a *host* is multi-homed to several ISP, e.g. through a GPRS connection and a wireless hot spot, the host is provided with different IP addresses on each interface. I know that multi6 studies "site" multi-homing, but I also know that the various wedge solutions can potentially be used for host multi-homing scenarios as well, and I am worried about that. We may also observe that a common practice in site multi-homing in IPv4 is to use some form of address translation, effectively hiding the identity of the specific host within a site. -- Christian Huitema From owner-multi6@ops.ietf.org Fri Jul 9 14:33: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 OAA18219 for ; Fri, 9 Jul 2004 14:33:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bj0AB-000OTx-Mo for multi6-data@psg.com; Fri, 09 Jul 2004 18:31:59 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bj0AA-000OTM-Mm for multi6@ops.ietf.org; Fri, 09 Jul 2004 18:31:58 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Fri, 9 Jul 2004 11:31:54 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 Jul 2004 11:32:01 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 9 Jul 2004 11:31:53 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 9 Jul 2004 11:31:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Unique identifiers and privacy Date: Fri, 9 Jul 2004 11:31:58 -0700 Message-ID: Thread-Topic: Unique identifiers and privacy thread-index: AcRlznUBj702idX9T4SQMbUzweJmcQAB/j5g From: "Christian Huitema" To: "Erik Nordmark" , "Brian E Carpenter" Cc: "Multi6 List" X-OriginalArrivalTime: 09 Jul 2004 18:31:42.0978 (UTC) FILETIME=[FB813620:01C465E2] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 I am concerned with the general statement that we should merely "do no worse than the current state of the art". I am specifically concerned with the use of long lived unique identifiers. We have already got significant feedback on such identifiers in a number of products, e.g. identifiers of CPU chips, identifiers of users of audio-video players, host identifiers in IPv6, use of social security numbers in data bases, and the list goes on. Any unique identifier is a privacy time bomb. Obviously, there are places where unique identifiers are unavoidable. For example, one cannot receive mail without publishing a mail address of some kind. But there are many places where identifiers are in fact not needed. For example, a vast majority of Internet connections involve resolving the name of a server, obtaining the server address or "locator", and exchanging a few packets between a single pair of locators. A cautious design would not mandate use of any identifier in such circumstances. If we do use identifiers, we should obviously allow systems to create short-lived identifiers, and to use different identifiers for different activities. However, we should be very concerned with the default behavior. In practice, many application developers don't bother with advanced API and just use whatever is the default behavior of the stack. A cautious design would be to err on the side of privacy, and to make sure that by default, an application's traffic will use an identifier that is both short-lived and specific to that application. The use of long lived global identifiers should be reserved to those applications that specifically request them. -- Christian Huitema From owner-multi6@ops.ietf.org Sat Jul 10 04:04: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 EAA28516 for ; Sat, 10 Jul 2004 04:04:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BjCoU-000JbL-FA for multi6-data@psg.com; Sat, 10 Jul 2004 08:02:26 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BjCoR-000Jab-Tb for multi6@ops.ietf.org; Sat, 10 Jul 2004 08:02:24 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6A82MFA122324 for ; Sat, 10 Jul 2004 08:02:22 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6A82L33285034 for ; Sat, 10 Jul 2004 10:02:22 +0200 Received: from zurich.ibm.com (sig-9-145-242-250.de.ibm.com [9.145.242.250]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA85148 for ; Sat, 10 Jul 2004 10:02:20 +0200 Message-ID: <40EFA281.1020707@zurich.ibm.com> Date: Sat, 10 Jul 2004 10:02:09 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Re: Advantages and disadvantages of using CB64 type of identifiers 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.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: >>Are you saying we should treat applications as black boxes and be >>prepared to handle any combination of actions from all of them? > > > Yes. I hate to inject reality, but I think Erik is correct. Thousands of applications believe that an address is an address is an address, and only see addresses via the socket API. We have to accept that. The good news about porting apps to IPv6 is that it is easy, if a little boring, since no redesign is needed. Multi6 won't get deployed if it breaks that property. Brian > > If we can't do that we have to require application changes (or configuration > external to the applications) so that the stack can know what requirements > the applications have on the identifiers they use. > > (Requring such application changes is quite different than for instance > suggesting that applications that do callbacks or referrals invoke some new > API or do something different to take *full advantage* of multihoming.) > > Erik > > From owner-multi6@ops.ietf.org Sun Jul 11 00:02: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 AAA15539 for ; Sun, 11 Jul 2004 00:02:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BjVVf-000DNQ-QF for multi6-data@psg.com; Sun, 11 Jul 2004 04:00:15 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BjVVe-000DN9-Pj for multi6@ops.ietf.org; Sun, 11 Jul 2004 04:00:14 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id EF30D369 for ; Sun, 11 Jul 2004 00:00:13 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 11 Jul 2004 00:00:13 -0400 Message-Id: <20040711040013.EF30D369@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Messages | Bytes | Who --------+------+--------+----------+------------------------ 31.15% | 19 | 33.34% | 76467 | brc@zurich.ibm.com 14.75% | 9 | 14.25% | 32687 | erik.nordmark@sun.com 11.48% | 7 | 10.87% | 24928 | huitema@windows.microsoft.com 11.48% | 7 | 9.28% | 21296 | iljitsch@muada.com 6.56% | 4 | 9.12% | 20924 | fred@cisco.com 6.56% | 4 | 7.42% | 17026 | marcelo@it.uc3m.es 4.92% | 3 | 3.37% | 7737 | jari.arkko@piuha.net 3.28% | 2 | 4.53% | 10385 | internet-drafts@ietf.org 3.28% | 2 | 3.23% | 7417 | mbagnulo@ing.uc3m.es 1.64% | 1 | 1.21% | 2774 | sra@hactrn.net 1.64% | 1 | 1.21% | 2773 | gih@telstra.net 1.64% | 1 | 1.11% | 2555 | pekkas@netcore.fi 1.64% | 1 | 1.05% | 2418 | kurtis@kurtis.pp.se --------+------+--------+----------+------------------------ 100.00% | 61 |100.00% | 229387 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Jul 11 10: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 KAA23088 for ; Sun, 11 Jul 2004 10:10:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bjezp-0002Hp-Jy for multi6-data@psg.com; Sun, 11 Jul 2004 14:08:01 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bjezo-0002HS-9t for multi6@ops.ietf.org; Sun, 11 Jul 2004 14:08:00 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7F3A739564; Sun, 11 Jul 2004 15:08:24 +0200 (CEST) Received: from [163.117.252.45] (unknown [163.117.252.45]) by smtp01.uc3m.es (Postfix) with ESMTP id 8712A395D0; Sun, 11 Jul 2004 15:08:22 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: "Brian E Carpenter" , "Multi6 List" , "Erik Nordmark" From: marcelo bagnulo braun Subject: Re: Unique identifiers and privacy Date: Sun, 11 Jul 2004 16:01:55 +0200 To: "Christian Huitema" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Christian, El 09/07/2004, a las 20:31, Christian Huitema escribi=F3: > I am concerned with the general statement that we should merely "do no > worse than the current state of the art". I think that we already have considered the multihoming solution to be=20= a possibility to improve other parts of the architecture, namely, we=20 have considered improving the security, the mobility, the renumbering=20 and now the privacy of the Internet. I am attracted to all this approaches, since i can see that all these=20 approaches could provide some great benefits. However, the multihoming problem presents a great difficulty on its=20 own, so i feel that we should focus on choosing the solutions that best=20= solves the multihoming problem without breaking any other part of the=20 Internet. In other words, providing multihoming support without doing=20 worst on the other aspects concerned. For sure, if the best solution for the multihoming problem also=20 provides more security or privacy or mobility or renumbering support,=20 then great. But for now, imho these are nice-to-have features. Just my 2 cents on this. > I am specifically concerned > with the use of long lived unique identifiers. We have already got > significant feedback on such identifiers in a number of products, e.g. > identifiers of CPU chips, identifiers of users of audio-video players, > host identifiers in IPv6, use of social security numbers in data = bases, > and the list goes on. Any unique identifier is a privacy time bomb. > Okey, i see your concern but i think that this is not the case here. I guess that your point is about unique identifiers in the sense that=20 they cannot be changed over time, like a hardware serial number or a=20 MAC address. In this case, the hardware number is fixed and it is a=20 clear privacy time bomb as you mention. However, using identifiers, like crypto identifiers that can be changed=20= periodically, does not pose the same level of privacy issues. I mean, the problem with fixed identifiers is that they can be traced=20 during long periods of time. Periodically generated identifiers can have the same behaviour than=20 RFC3041 addresses, so they can be changed pretty frequently, so i=20 really don't feel that they pose the same privacy threats that you are=20= mentioning. regards, marcelo > Obviously, there are places where unique identifiers are unavoidable. > For example, one cannot receive mail without publishing a mail address > of some kind. But there are many places where identifiers are in fact > not needed. For example, a vast majority of Internet connections=20 > involve > resolving the name of a server, obtaining the server address or > "locator", and exchanging a few packets between a single pair of > locators. A cautious design would not mandate use of any identifier in > such circumstances. > > If we do use identifiers, we should obviously allow systems to create > short-lived identifiers, and to use different identifiers for = different > activities. However, we should be very concerned with the default > behavior. In practice, many application developers don't bother with > advanced API and just use whatever is the default behavior of the=20 > stack. > A cautious design would be to err on the side of privacy, and to make > sure that by default, an application's traffic will use an identifier > that is both short-lived and specific to that application. The use of > long lived global identifiers should be reserved to those applications > that specifically request them. > > -- Christian Huitema > From owner-multi6@ops.ietf.org Sun Jul 11 10:10:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23114 for ; Sun, 11 Jul 2004 10:10:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bjezo-0002HX-Lk for multi6-data@psg.com; Sun, 11 Jul 2004 14:08:00 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bjezm-0002H6-UH for multi6@ops.ietf.org; Sun, 11 Jul 2004 14:07:59 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1158538161; Sun, 11 Jul 2004 15:08:22 +0200 (CEST) Received: from [163.117.252.45] (unknown [163.117.252.45]) by smtp01.uc3m.es (Postfix) with ESMTP id 3111B395D0; Sun, 11 Jul 2004 15:08:19 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Multi6 List , Iljitsch van Beijnum From: marcelo bagnulo braun Subject: Re: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers Date: Sun, 11 Jul 2004 16:07:45 +0200 To: Erik Nordmark X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 El 09/07/2004, a las 17:56, Erik Nordmark escribi=F3: >> Now, imho, this goals don't impose that we have to have different >> identities for different interfaces, but that we need different >> identities for different communications. >> The problem as usual, is how the wedge layer can find out which=20 >> packets >> belong to which communication. > > That part is hard; mapping the communicating to the privacy=20 > requirements. > > But it is also hard for the wedge leayer to know the beginning and end > of a session, which is also needed. For instance, an application=20 > session > might silently assume that multiple TCP connections (to the same peer,=20= > or > even to different peers) use the same IP address today to represent=20 > the host. > As a result, if such an application isn't modified for multihoming=20 > somehow, > it would assume that the same AID (application-visible identifier) is > representing the host for that set of connections. > Question: wouldn't this application also break when RFC3041 addresses=20 are used? in particular when a new temporary address is used > But at the same time one might want to have different sessions (where > there isn't a need to present the same identifier to the peer) > explicitly use different identifiers for privacy reasons. > > One can definitely create APIs by which the applications can express=20= > both > the privacy requirements for communication, and the set of=20 > communication > that must use the same identifier for the host. > But if we do that then the question is what the default settings = should > be for (unmodified) applications which do not express anything using=20= > those > APIs. > Should we err on the side of privacy? Should we err on the side of > making as many unmodified applications as possible work by using the > same identifier all the time by default? > >> Now, just to mix things a bit more, how would a solution like NOID >> support the privacy requirements? Are the DNS times compatible with >> this requirement? > > draft-nordmark-multi6-noid-02 (which I submitted on Wed so it should = be > in the I-D directory any day now) talks a bit more about this. > Briefly: > For a host to take advantage of itself (or its site) being multihomed > for rehoming, the host needs to have a FQDN and consistent forward and=20= > reverse > information for itself in the DNS. > > For such a host to have multiple pseudonyms, this implies having=20 > multiple > FQDNs. (Such as host-2002-8192-56bb-9258-0-0-8192-5882.example.com = i.e. > the FQDN doesn't have to provide any mnemonic meaning to a user.) ok, but in order to support RFC3041 addresses the host would need to=20 dynamically update the DNS (creating a new record for its new temporary=20= addresses), right? this would imply that multihomed hosts will need to=20= support Dyn DNs or something similar right? regards, marcelo > > If the host doesn't need to take advantage of itself being multihomed, > but uses NOID to take advantage of the peer/server being multihomed, > then it doesn't need a FQDN. Hence it can have pseudonyms just using > RFC 3041 temporary addresses.) > > Erik > > From owner-multi6@ops.ietf.org Mon Jul 12 05:50: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 FAA25881 for ; Mon, 12 Jul 2004 05:50:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BjxQK-000OAq-6p for multi6-data@psg.com; Mon, 12 Jul 2004 09:48:36 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BjxQI-000O9o-6a for multi6@ops.ietf.org; Mon, 12 Jul 2004 09:48:34 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 1263B4C5332 for ; Mon, 12 Jul 2004 11:48:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=fixed To: Multi6 List From: Kurt Erik Lindqvist Subject: Updated draft-ietf-multi6-v4-multihoming-01.txt Date: Mon, 12 Jul 2004 11:48:29 +0200 X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have today submitted draft-ietf-multi6-v4-multihoming-01.txt to the I-D editor. As I assume I am not the only one submitting drafts today :-) it is also at http://www.kurtis.pp.se/ietf/draft-ietf-multi6-v4-multihoming-01.txt Brian will act as WG chair for anything that relates to this draft, I will act as editor. While updating I have gone through all comments I have found. I have acted on most, and disagreed with some. Some where more or less out of scope after recent (6 months) development of the WG, so I haven't acted on them. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQPJecKarNKXTPFCVEQKf9ACg8RY+xEWXhiZ1a+sTc4llwr65q+oAoNeW 2qZQX6T0C6UnCpSAkE32Ehx4 =lY7m -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Mon Jul 12 07:53: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 HAA01284 for ; Mon, 12 Jul 2004 07:53:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BjzM6-000KLF-DR for multi6-data@psg.com; Mon, 12 Jul 2004 11:52:22 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BjzM3-000KKr-Sy for multi6@ops.ietf.org; Mon, 12 Jul 2004 11:52:20 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6CBqIGm030206 for ; Mon, 12 Jul 2004 11:52:18 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6CBqIdb156388 for ; Mon, 12 Jul 2004 13:52:18 +0200 Received: from zurich.ibm.com (dyn-9-13-126-72.ge.ch.ibm.com [9.13.126.72]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA88456 for ; Mon, 12 Jul 2004 13:52:17 +0200 Message-ID: <40F27B66.3000703@zurich.ibm.com> Date: Mon, 12 Jul 2004 13:52:06 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.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.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 Erik Lindqvist wrote: > I have today submitted draft-ietf-multi6-v4-multihoming-01.txt to the > I-D editor. As I assume I am not the only one submitting drafts today > :-) it is also at > http://www.kurtis.pp.se/ietf/draft-ietf-multi6-v4-multihoming-01.txt > > > Brian will act as WG chair for anything that relates to this draft, I > will act as editor. The plan is to try to reach consensus on any open issues during the San Diego meeting, so please let's hear what issues exist. Brian > > While updating I have gone through all comments I have found. I have > acted on most, and disagreed with some. Some where more or less out of > scope after recent (6 months) development of the WG, so I haven't acted > on them. > > - - kurtis - > From owner-multi6@ops.ietf.org Mon Jul 12 11:18: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 LAA16650 for ; Mon, 12 Jul 2004 11:18:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk2Xm-00029V-LH for multi6-data@psg.com; Mon, 12 Jul 2004 15:16:38 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk2Xk-00028x-Nw for multi6@ops.ietf.org; Mon, 12 Jul 2004 15:16:37 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 1B25439DCE; Mon, 12 Jul 2004 16:17:01 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id EF18B39D59; Mon, 12 Jul 2004 16:17:00 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.txt Date: Mon, 12 Jul 2004 17:17:53 +0200 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Kurtis, some comments about the draft... - Section 1 In the third paragraph it is stated that: "This practice has two advantages and one disadvantage for the..." what practice are you considering? I think you are considering the situation where a multihomed site=20 obtains an address block from one of its providers and announces it=20 through the other providers, but i couldn't find it stated explicitly multihomed network. The first advantage is that they can obtain a much smaller block of address space from an ISP than from a RIR. (Would-be multihomers still often optimize their networks for qualifying for at least a /24 by adopting accepted but relatively wasteful address deployment strategies.) Well, i don't know why this is a benefit for the multihomed network in=20= particular. I mean, i can see that this is benefit for the Internet as a whole,=20 since addresses are used in a more efficient way, but i don't see how=20 the multihomed site is better off. The second advantage is that even if their announcement is filtered, they are still reachable = over the primary ISP by virtue of the aggregate announced by this ISP. Even when the circuit to the primary ISP is down, this often works because the primary ISP will generally accept the announcement over the secondary ISP, so traffic flows from the filtering network to = the primary ISP and then to the secondary ISP in order to arrive at the multihomed network. While this is common, it is also not = universally true. An implicit requirement here is that the primary ISP must peer with=20 each one of the other ISPs, wwhich i am not sure that this is always=20 true. I mean, there are two conditions here: first the primary ISP must=20= peer with the other ISP and second the primary ISP must accept the=20 announcement of shorter prefixes. The disadvantage is that the multihomed network must depend on the primary ISP for the aggregate. If the primary ISP goes down, this will impact reachability to networks that filter. And when the multihomed network leaves the primary ISP, they are generally expected to return the address space because otherwise this ISP = would have to route traffic for a non-customer. Most ISPs will cooperate with this "punching holes in an aggregate" solution to multihoming, but some are reluctant. Well, another clear disadvantage is that the address block of the=20 multihomed site belongs to the ISP, so if the multihomed site changes=20 its primary ISP, it must renumber. An interesting point is that if the=20= multihomed site changes any of the other isps, it don't have to=20 renumber. - Section 2 Terminology Perhaps for completeness it would good to add the definition of a=20 multihomed (end)site? - Section 3 - Section 3.1 By multihoming, an enterprise can insulate itself from certain failure modes within one or more transit providers, as well as failures in the network providing interconnection with one or more transit providers. I fail to understand the meaning of the last part of the sentence=20 (starting from "as well..) Perhaps it needs some rewording? - Section 3.2 Perhaps it would be valuable to add some more detailed description of=20 which kind of support for load sharing is obtained with this solution? I mean, perhaps talking about announcing more specific prefixes, AS=20 prepending and so on and presenting the limitations of each method.=20 IMHO this may be important when considering the capabilities of an IPv6=20= multihoming solution. I mean, when comparing IPv4 capabilities vs IPv6=20= capabilities we will need to go more in detail than just load sharing=20 support, i guess. - Section 3.4 Same comments that in load sharing. Current multihoming solution=20 support some degree of policing. Perhaps explaining what level of=20 support is provided and its limitations could be useful (like the stuff=20= presented in section 5.3 but w.r.t policy and perhaps in a bit more of=20= detail) - Section 3.5 Most of the benefits presented are related to obtaining a PI address=20 block (rather than being multihomed) As you mention in the introduction, a site can be multihomed, but still=20= use PA address from one of its providers, so most of these benefits=20 will not be achieved. imho this section is a bit misleading in this aspect. I mean independency w.r.t. renumbering, easier migration and so on are=20= benefits of having PI addresses and they are not benefits of being=20 multihomed. Just happens to be that being multihomed is one of the ways=20= of obtaining PI addresses given current RIR policies :-) I mean, imho we need to explain the situation a bit more in detail here. - Section 4.2 s/addressblock/address block s/teh/the - Section 5 The features described in this section don't really apply to all=20 multihomed configurations described in section 4. For instance,=20 configuration 4.5 (using NATs) don't provide feature 5.2 (transport=20 layer survivability), Moreover, multiattached networks don't obtain=20 full fault tolerance against all the failures described in section 3.1.=20= Additionally NAT configuration doesn't really provide much TE=20 capabilities AFAICS. OTOH, NAT configuration is really simple and can=20 be adopted in unmanaged environments, while BGP based configuration=20 doesn't seems as simple as this, so i am not sure that the simplicity=20 benefit applies to all of the configurations in the same level. I don't know which approach to follow with this, but i am tempted to=20 suggest that the NAT approach and the multiattached approach are moved=20= to a later section where they are presented as "other approaches" where=20= their limitations and advantages are presented. In addition, as i understand this, the features described in this=20 section are in addition to the features presented in section 3, right?=20= Perhaps stating this explicitly would make it clearer - Section 5.2 I would mention in this section that becuase the number of AS in the=20 Internet and the delayed BGP convergence that it causes, this feature=20 is not universal in the current Internet, i.e. that there are some=20 outages that take a long time BGP to reconverge causing come TCP=20 connections to fail. Perhaps quoting Labovitz work here... another limitation here (as Iljitsch has mentioned several times by=20 now) is that the current default time setting on some commercial=20 routers make that BGP need 3 minutes to detect an outage, so this=20 implies that it will take more than 3 min to reroute the established=20 communications. Bottom line is that current multihoming solution=20 doesn't really preserves all established communications always. - Section 5.4 The current multihoming solution places control of traffic flow in the hands of the enterprise responsible for the multi-homed interconnections with transit providers. A single-homed customer of a multi-homed enterprise may vary the demand for traffic that they impose on the enterprise, and may influence differential traffic = load between transit providers; however, the basic mechanisms for congestion control and route propagation are in the hands of the enterprise, not the customer. I fail to understand this section. I mean, here we are considering only=20= site multihoming, so i don't see why are relevant comments about=20 clients of the multihomed enterprise. AFAIU, a multihomed end site=20 don't have customers, right? The same goes for the customer/ enterprise comments in the last sentence Regards, marcelo El 12/07/2004, a las 11:48, Kurt Erik Lindqvist escribi=F3: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > =09 > > I have today submitted draft-ietf-multi6-v4-multihoming-01.txt to the > I-D editor. As I assume I am not the only one submitting drafts today > :-) it is also at > http://www.kurtis.pp.se/ietf/draft-ietf-multi6-v4-multihoming-01.txt > > > Brian will act as WG chair for anything that relates to this draft, I > will act as editor. > > While updating I have gone through all comments I have found. I have > acted on most, and disagreed with some. Some where more or less out of > scope after recent (6 months) development of the WG, so I haven't = acted > on them. > > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQPJecKarNKXTPFCVEQKf9ACg8RY+xEWXhiZ1a+sTc4llwr65q+oAoNeW > 2qZQX6T0C6UnCpSAkE32Ehx4 > =3DlY7m > -----END PGP SIGNATURE----- > > From owner-multi6@ops.ietf.org Mon Jul 12 14:19:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28766 for ; Mon, 12 Jul 2004 14:19:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk5Nn-0001e7-Ay for multi6-data@psg.com; Mon, 12 Jul 2004 18:18:31 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk5Nk-0001df-Vd for multi6@ops.ietf.org; Mon, 12 Jul 2004 18:18:29 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000129762.msg for ; Mon, 12 Jul 2004 20:21:10 +0200 Message-ID: <02e801c4683c$9826e9b0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: Subject: IPv6 multihoming scenarios I-D Date: Mon, 12 Jul 2004 20:18:11 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 12 Jul 2004 20:21:10 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 12 Jul 2004 20:21:11 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: quoted-printable Hi all, As consequence of some comments with the WG co-chairs in the recent interim meeting (see the minutes also), we submitted this morning this document (for the inpatients): http://www.consulintel.euro6ix.org/ietf/draft-palet-multi6-scenarios-00.txt There is still some work to be done, and we will like to get some inputs specially from different experts: - 3GPP - Ad-hoc - Mesh - Mobility - Content Delivery Networks - Internet Data Centers - Other special applications or protocols ? Depending on the inputs, we may decide not to go so further, but at this stage, seems worth to think on it. We also had an internal debate among the authors to understand if the SOHO/Home environment which can be managed/unmanaged, could two different scenarios, but may be this will depend on the solution ? Hopefully the solution is good enough to not require management skills on the network and not depend on the ISP willingness to provide a multihoming solution, specially if several ISPs need to cooperate. We will try to submit an updated version next Monday, if we have comments. So please, provide your feedback ! Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Mon Jul 12 15:36: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 PAA04803 for ; Mon, 12 Jul 2004 15:36:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk6aG-000CF2-KK for multi6-data@psg.com; Mon, 12 Jul 2004 19:35:28 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk6aE-000CEn-Sz for multi6@ops.ietf.org; Mon, 12 Jul 2004 19:35:27 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6CJae2r098451; Mon, 12 Jul 2004 21:36:43 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9BF78B66-D43A-11D8-84DE-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.txt Date: Mon, 12 Jul 2004 21:35:19 +0200 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 12-jul-04, at 11:48, Kurt Erik Lindqvist wrote: > http://www.kurtis.pp.se/ietf/draft-ietf-multi6-v4-multihoming-01.txt Ok, I'm not going to repeat everything that Marcelo said, but I agree with pretty much all of it. Apart from that: - no mention of what "multihoming" is in the abstract, multi6 is mentioned but only the long title, this won't help people looking for the wg very much - enterprises enterprises, why not say "organizations" at least once in a while? - the introduction talks about all kinds of details without illuminating the big picture 2. - definition for multihomed isn't very good as this also catches organizations which use one isp for part of their network and another for another part - "A "multi-attached" enterprise is one with more than one point of layer-3 interconnection to a single transit provider." Huh? How is this different from being multihomed? 3.1 - a bgp peer reset isn't a routing protocol failure - multihoming doesn't necessarily protect a customer against isp igp failure as it is likely that bgp will continue to function in such a case - a bgp peer reset isn't an exchange failure 3.2 - load sharing limitations aren't explained 3.4 - why talk about load sharing here? 4.1 and 4.2 - difference between pa addresses and pa addresses is unclear. what's meant here is the difference between having your own block and shooting holes in an isp's block 4.3 - who cares? only confuses the issue 4.5 - this is so different from the other types of multihoming that it's impossible to discuss it along with those. move this to a different section. and don't forget that nat in and of itself doesn't do anything for multihoming. also this isn't mentioned anywhere else so it's mostly a red herring. 5.1 - grammar - i think many people wouldn't agree that this is straightforward 5.2 - i partially agree with Marcelo: there are times when sessions don't survive. however, this is rare in practice 5.3 - this is a very bad practice as it inflates the (global) routing table and certainly not the only way to influence INBOUND traffic, not to mention outbound traffic. also, rfc 1998 is a very good reference here 6.1 - why avoid 32 bit AS numbers??? this draft has been around for years. references - 7: this was later published as rfc 3221, which makes for a better reference imo general - it is never really explained how multihoming is actually done (in a way that someone who doesn't already do it understands) Wouldn't starting from scratch be simpler than trying to fix this document? From owner-multi6@ops.ietf.org Mon Jul 12 15:48: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 PAA06117 for ; Mon, 12 Jul 2004 15:48:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bk6mj-000E3P-UN for multi6-data@psg.com; Mon, 12 Jul 2004 19:48:21 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bk6ma-000E1W-Jn for multi6@ops.ietf.org; Mon, 12 Jul 2004 19:48:13 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000129931.msg for ; Mon, 12 Jul 2004 21:50:56 +0200 Message-ID: <04e201c46849$27a395f0$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <02e801c4683c$9826e9b0$8700000a@consulintel.es> Subject: Re: IPv6 multihoming scenarios I-D Date: Mon, 12 Jul 2004 21:48:06 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Mon, 12 Jul 2004 21:50:56 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-MDAV-Processed: consulintel.es, Mon, 12 Jul 2004 21:50:57 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: quoted-printable Ooops ... I didn't want to say inpatients, but impatient ! So, please, once more, read the document and provide your feedback, even if you're not in the hospital ;-) Regards, Jordi ----- Original Message -----=20 From: "JORDI PALET MARTINEZ" To: Sent: Monday, July 12, 2004 8:18 PM Subject: IPv6 multihoming scenarios I-D Hi all, As consequence of some comments with the WG co-chairs in the recent interim meeting (see the minutes also), we submitted this morning this document (for the inpatients): http://www.consulintel.euro6ix.org/ietf/draft-palet-multi6-scenarios-00.txt There is still some work to be done, and we will like to get some inputs specially from different experts: - 3GPP - Ad-hoc - Mesh - Mobility - Content Delivery Networks - Internet Data Centers - Other special applications or protocols ? Depending on the inputs, we may decide not to go so further, but at this stage, seems worth to think on it. We also had an internal debate among the authors to understand if the SOHO/Home environment which can be managed/unmanaged, could two different scenarios, but may be this will depend on the solution ? Hopefully the solution is good enough to not require management skills on the network and not depend on the ISP willingness to provide a multihoming solution, specially if several ISPs need to cooperate. We will try to submit an updated version next Monday, if we have comments. So please, provide your feedback ! Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Tue Jul 13 04:03: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 EAA19222 for ; Tue, 13 Jul 2004 04:03:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkIFA-000Gwp-M0 for multi6-data@psg.com; Tue, 13 Jul 2004 08:02:28 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkIF9-000GwM-JN for multi6@ops.ietf.org; Tue, 13 Jul 2004 08:02:27 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6D83g2r008822; Tue, 13 Jul 2004 10:03:43 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <02e801c4683c$9826e9b0$8700000a@consulintel.es> References: <02e801c4683c$9826e9b0$8700000a@consulintel.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: From: Iljitsch van Beijnum Subject: Re: IPv6 multihoming scenarios I-D Date: Tue, 13 Jul 2004 10:02:22 +0200 To: "JORDI PALET MARTINEZ" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 12-jul-04, at 20:18, JORDI PALET MARTINEZ wrote: > As consequence of some comments with the WG co-chairs in the recent > interim meeting (see the minutes also), we submitted this morning this > document (for the inpatients): What about the outpatients? :-) > http://www.consulintel.euro6ix.org/ietf/draft-palet-multi6-scenarios > -00.txt The first part is very good. In fact, much of this should have been in the "how it's done today" draft. Maybe it would even be good to merge these two drafts, as the text overlaps significantly even if the intention behind the documents doesn't. One thing that could use a little more text is the situation where a network connects to the commodity internet through one or more ISPs, but also to a specialized network such as an NREN. In this case the policy that certain traffic should always flow over the specialized network, or that certain traffic never flows over the specialized network is important and must be enforceable. > There is still some work to be done, and we will like to get some > inputs specially from different experts: > - 3GPP > - Ad-hoc > - Mesh > - Mobility > - Content Delivery Networks > - Internet Data Centers > - Other special applications or protocols ? I wasn't impressed by this part. Sure, an UMTS network can be multihomed, and a mobile device can be multihomed. But does this mean we have to talk about 3GPP (what does this stand for anyway?) multihoming? Better remove this part and stick with what's important. Iljitsch From owner-multi6@ops.ietf.org Tue Jul 13 16:12:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11209 for ; Tue, 13 Jul 2004 16:12:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkTap-000M4C-6I for multi6-data@psg.com; Tue, 13 Jul 2004 20:09:35 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkTan-000M3i-T6 for multi6@ops.ietf.org; Tue, 13 Jul 2004 20:09:34 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10799; Tue, 13 Jul 2004 16:09:30 -0400 (EDT) Message-Id: <200407132009.QAA10799@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: multi6@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-multi6-v4-multihoming-01.txt Date: Tue, 13 Jul 2004 16:09:30 -0400 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Site Multihoming in IPv6 Working Group of the IETF. Title : IPv4 Multihoming Motivation, Practices and Limitations Author(s) : J. Abley, et al. Filename : draft-ietf-multi6-v4-multihoming-01.txt Pages : 16 Date : 2004-7-13 Multihoming is an essential component of service for enterprises which are part of the Internet. This draft describes some of the motivations, practices and limitations of multihoming as it is achieved in the IPv4 world today. The analysis is done in order to serve as underlaying documentation to the discussions in the "Site multihoming for IPv6" workinggroup of the IETF, who are working to a longerterm solution to some of the issues that arise from doing multihoming in the ways as are described here. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-multi6-v4-multihoming-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-multi6-v4-multihoming-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-multi6-v4-multihoming-01.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-7-13145348.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-multi6-v4-multihoming-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-multi6-v4-multihoming-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-13145348.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-multi6@ops.ietf.org Tue Jul 13 22:30: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 WAA29887 for ; Tue, 13 Jul 2004 22:30:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkZVl-0003tF-G3 for multi6-data@psg.com; Wed, 14 Jul 2004 02:28:45 +0000 Received: from [203.178.142.130] (helo=shonan.sfc.wide.ad.jp) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkZVi-0003sa-6Y for multi6@ops.ietf.org; Wed, 14 Jul 2004 02:28:42 +0000 Received: from galibier.nautilus6.org (unknown [203.178.138.3]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 913545D1F0 for ; Wed, 14 Jul 2004 11:28:39 +0900 (JST) Date: Wed, 14 Jul 2004 11:28:24 +0900 From: Thierry Ernst To: Multi6 Subject: Fw: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt Message-Id: <20040714112824.4efdc8d8.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Wed__14_Jul_2004_11:28:24_+0900_08218118" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 This is a multi-part message in MIME format. --Multipart_Wed__14_Jul_2004_11:28:24_+0900_08218118 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear all, I think this problem statement for multihoming in NEMO would interest some of you. This is now a NEMO WG document, so we will most likely discuss the document during our NEMO WG meeting, on Monday August 2nd. I guess the NEMO WG would appreciate if some of you could join the discussion, so that we make sure there is a good interaction between both WGs. Thierry. -- Thierry Ernst, PhD WIDE at Keio University, Japan IETF NEMO WG co-chair http://www.ietf.org/html.charters/nemo-charter.html WIDE NAUTILUS WG co-chair http://www.nautilus6.org --Multipart_Wed__14_Jul_2004_11:28:24_+0900_08218118 Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from shonan.sfc.wide.ad.jp ([unix socket]) by shonan.sfc.wide.ad.jp (Cyrus v2.0.17); Wed, 14 Jul 2004 10:37:29 +0900 X-Sieve: cmu-sieve 2.0 Return-Path: Received: from ironport1.sfc.wide.ad.jp (ironport1.sfc.wide.ad.jp [203.178.143.33]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 4FD1E5D0BC; Wed, 14 Jul 2004 10:37:29 +0900 (JST) Received: from megatron.ietf.org (132.151.6.71) by ironport1.sfc.wide.ad.jp with ESMTP; 14 Jul 2004 10:36:45 +0900 X-Ironport-AV: i="3.81R,166,1083510000"; d="scan'208"; a="1203803:sNHT23569348" Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkV0n-0004Z7-6g; Tue, 13 Jul 2004 17:40:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkTVH-0003BZ-RH; Tue, 13 Jul 2004 16:03:51 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10328; Tue, 13 Jul 2004 16:03:49 -0400 (EDT) Message-Id: <200407132003.QAA10328@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 13 Jul 2004 16:03:49 -0400 Cc: nemo@ietf.org Subject: [nemo] I-D ACTION:draft-ietf-nemo-multihoming-issues-00.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : Analysis of Multihoming in Network Mobility Support Author(s) : C. Ng, et al. Filename : draft-ietf-nemo-multihoming-issues-00.txt Pages : 33 Date : 2004-7-13 This document is an analysis of multihoming in the context of network mobility (NEMO). As there are many situations in which mobile networks may be multihomed, a taxonomy is proposed to classify the possible configurations. We also describe possible deployment scenarios and we attempt to identify issues that arise when mobile networks are multihomed while mobility supports is taken care by NEMO Basic Support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-multihoming-issues-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-ietf-nemo-multihoming-issues-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-7-13145203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-multihoming-issues-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-multihoming-issues-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-13145203.I-D@ietf.org> --OtherAccess-- --NextPart-- --Multipart_Wed__14_Jul_2004_11:28:24_+0900_08218118-- From owner-multi6@ops.ietf.org Wed Jul 14 03:14: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 DAA27682 for ; Wed, 14 Jul 2004 03:14:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkdwG-0007UA-4e for multi6-data@psg.com; Wed, 14 Jul 2004 07:12:24 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkdwD-0007Td-V4 for multi6@ops.ietf.org; Wed, 14 Jul 2004 07:12:22 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 1CF574D43F1; Wed, 14 Jul 2004 09:12:21 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <23060B2D-D565-11D8-B57E-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.txt Date: Wed, 14 Jul 2004 09:12:16 +0200 To: marcelo bagnulo braun X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! > - Section 1 > > In the third paragraph it is stated that: > > "This practice has two advantages and one disadvantage for the..." > > what practice are you considering? > I think you are considering the situation where a multihomed site > obtains an address block from one of its providers and announces it > through the other providers, but i couldn't find it stated explicitly I think that is what the second paragraph describes? I guess you are saying that it should be more clear....:-) > multihomed network. The first advantage is that they can obtain a > much smaller block of address space from an ISP than from a RIR. > (Would-be multihomers still often optimize their networks for > qualifying for at least a /24 by adopting accepted but relatively > wasteful address deployment strategies.) > > Well, i don't know why this is a benefit for the multihomed network in > particular. > I mean, i can see that this is benefit for the Internet as a whole, > since addresses are used in a more efficient way, but i don't see how > the multihomed site is better off. Hmm. True. This should refer to an advantage with the model, not for the network. > The second advantage is that > even if their announcement is filtered, they are still reachable > over > the primary ISP by virtue of the aggregate announced by this ISP. > Even when the circuit to the primary ISP is down, this often works > because the primary ISP will generally accept the announcement over > the secondary ISP, so traffic flows from the filtering network to > the > primary ISP and then to the secondary ISP in order to arrive at the > multihomed network. While this is common, it is also not > universally > true. > > An implicit requirement here is that the primary ISP must peer with > each one of the other ISPs, wwhich i am not sure that this is always > true. I mean, there are two conditions here: first the primary ISP > must peer with the other ISP and second the primary ISP must accept > the announcement of shorter prefixes. Agreed. Will add or try to re-write. I will post some proposed text here first. > > The disadvantage is that the multihomed network must depend on the > primary ISP for the aggregate. If the primary ISP goes down, this > will impact reachability to networks that filter. And when the > multihomed network leaves the primary ISP, they are generally > expected to return the address space because otherwise this ISP > would > have to route traffic for a non-customer. Most ISPs will cooperate > with this "punching holes in an aggregate" solution to multihoming, > but some are reluctant. > > Well, another clear disadvantage is that the address block of the > multihomed site belongs to the ISP, so if the multihomed site changes > its primary ISP, it must renumber. An interesting point is that if the > multihomed site changes any of the other isps, it don't have to > renumber. True. I should add something on this as well. > - Section 2 Terminology > > Perhaps for completeness it would good to add the definition of a > multihomed (end)site? I guess I agree. > - Section 3 > > - Section 3.1 > > By multihoming, an enterprise can insulate itself from certain > failure modes within one or more transit providers, as well as > failures in the network providing interconnection with one or more > transit providers. > > I fail to understand the meaning of the last part of the sentence > (starting from "as well..) > Perhaps it needs some rewording? I refers to the physical network. Point-2-point links, peering point etc. > - Section 3.2 > > Perhaps it would be valuable to add some more detailed description of > which kind of support for load sharing is obtained with this solution? > I mean, perhaps talking about announcing more specific prefixes, AS > prepending and so on and presenting the limitations of each method. > IMHO this may be important when considering the capabilities of an > IPv6 multihoming solution. I mean, when comparing IPv4 capabilities vs > IPv6 capabilities we will need to go more in detail than just load > sharing support, i guess. Ok, agreed. > - Section 3.4 > > Same comments that in load sharing. Current multihoming solution > support some degree of policing. Perhaps explaining what level of > support is provided and its limitations could be useful (like the > stuff presented in section 5.3 but w.r.t policy and perhaps in a bit > more of detail) I kind o agree, but then we need to be clear that we only describe methods that are direct results of the way the prefixes are announced. So that we ignore other features of BGP. > - Section 3.5 > > Most of the benefits presented are related to obtaining a PI address > block (rather than being multihomed) > As you mention in the introduction, a site can be multihomed, but > still use PA address from one of its providers, so most of these > benefits will not be achieved. > imho this section is a bit misleading in this aspect. > I mean independency w.r.t. renumbering, easier migration and so on are > benefits of having PI addresses and they are not benefits of being > multihomed. Just happens to be that being multihomed is one of the > ways of obtaining PI addresses given current RIR policies :-) > I mean, imho we need to explain the situation a bit more in detail > here. Hmm, I sort of see what you are saying but I am not sure how to describe it. I will think it over a bit and propose text. > - Section 4.2 > > s/addressblock/address block > s/teh/the Thanks! > - Section 5 > > The features described in this section don't really apply to all > multihomed configurations described in section 4. For instance, > configuration 4.5 (using NATs) don't provide feature 5.2 (transport > layer survivability), Moreover, multiattached networks don't obtain > full fault tolerance against all the failures described in section > 3.1. Additionally NAT configuration doesn't really provide much TE > capabilities AFAICS. OTOH, NAT configuration is really simple and can > be adopted in unmanaged environments, while BGP based configuration > doesn't seems as simple as this, so i am not sure that the simplicity > benefit applies to all of the configurations in the same level. > I don't know which approach to follow with this, but i am tempted to > suggest that the NAT approach and the multiattached approach are moved > to a later section where they are presented as "other approaches" > where their limitations and advantages are presented. > > In addition, as i understand this, the features described in this > section are in addition to the features presented in section 3, right? > Perhaps stating this explicitly would make it clearer Yes. There is nothing in the document that says that all reasons that can be used for requiring multihoming in section 4 needs to apply to section 5. Section 3 is to list the high level reasons as to why someone might want to do multihoming, section 4 lists the possible ways of doing multihoming, and section 5 lists what features you _can_ have from multihoming as done today. If you think this needs to be made clearer I will try and do that. > - Section 5.2 > > I would mention in this section that becuase the number of AS in the > Internet and the delayed BGP convergence that it causes, this feature > is not universal in the current Internet, i.e. that there are some > outages that take a long time BGP to reconverge causing come TCP > connections to fail. Perhaps quoting Labovitz work here... > another limitation here (as Iljitsch has mentioned several times by > now) is that the current default time setting on some commercial > routers make that BGP need 3 minutes to detect an outage, so this > implies that it will take more than 3 min to reroute the established > communications. Bottom line is that current multihoming solution > doesn't really preserves all established communications always. Well. Hmm. I kind of agree. Will add. > - Section 5.4 > > The current multihoming solution places control of traffic flow in > the hands of the enterprise responsible for the multi-homed > interconnections with transit providers. A single-homed customer of > a multi-homed enterprise may vary the demand for traffic that they > impose on the enterprise, and may influence differential traffic > load > between transit providers; however, the basic mechanisms for > congestion control and route propagation are in the hands of the > enterprise, not the customer. > > I fail to understand this section. I mean, here we are considering > only site multihoming, so i don't see why are relevant comments about > clients of the multihomed enterprise. AFAIU, a multihomed end site > don't have customers, right? > The same goes for the customer/ enterprise comments in the last > sentence I agree that this needs to be rewritten. What I read it as saying is that within an enterprise, needs for load-control will rise from different entities varying need for bandwidth to different destinations over time. But customer is not a very good description. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQPTc06arNKXTPFCVEQIBbACgm6hYVKrbyRsEJgsD8yk/VRlPD2AAnRY0 YGVE/GDHvV8PBFMlNOzM0MC+ =8Tgi -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Jul 14 03:29:32 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28469 for ; Wed, 14 Jul 2004 03:29:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkeCV-0009D0-UG for multi6-data@psg.com; Wed, 14 Jul 2004 07:29:11 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkeCU-0009Cl-Kx for multi6@ops.ietf.org; Wed, 14 Jul 2004 07:29:11 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 79CA54D4476; Wed, 14 Jul 2004 09:29:11 +0200 (CEST) In-Reply-To: <9BF78B66-D43A-11D8-84DE-000A95CD987A@muada.com> References: <9BF78B66-D43A-11D8-84DE-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <7B98B8D2-D567-11D8-B57E-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.txt Date: Wed, 14 Jul 2004 09:29:03 +0200 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > - no mention of what "multihoming" is in the abstract, multi6 is > mentioned but only the long title, this won't help people looking for > the wg very much Ok, agreed. > - enterprises enterprises, why not say "organizations" at least once > in a while? Actually I used organizations in the text I had written. Then realized that Pekka had posted the suggestion to use sites, and then saw that enterprise was used before. Reading the text I decided that I thought enterprise was a good word to use. I have no strong feeling one way or the other though. Do the native English speakers have any view? > - the introduction talks about all kinds of details without > illuminating the big picture Care to be a bit more specific? > 2. > - definition for multihomed isn't very good as this also catches > organizations which use one isp for part of their network and another > for another part Yes? Is this a problem? > - "A "multi-attached" enterprise is one with more than one point of > layer-3 interconnection to a single transit provider." Huh? How is > this different from being multihomed? It's to a single upstream compared to multiple upstreams. > 3.1 > - a bgp peer reset isn't a routing protocol failure Is "Failures signaled by routing protocols" better wording? > - multihoming doesn't necessarily protect a customer against isp igp > failure as it is likely that bgp will continue to function in such a > case Well, it doesn't protect it automatically but you could manually route around it for the time being. > - a bgp peer reset isn't an exchange failure While I agree, I think it does describe what is happening in the text : " Exchange failure, such as a BGP reset on an inter-provider peering." > 3.2 > - load sharing limitations aren't explained No. Agreed. > 3.4 > - why talk about load sharing here? I can try and come up with a better name for what is described. But I would argue it is a form of load-sharing. > 4.1 and 4.2 > - difference between pa addresses and pa addresses is unclear. what's > meant here is the difference between having your own block and > shooting holes in an isp's block PA and PA are the same :-) I assume you mean PI and PA. Ok, will try and come up with better text. > 4.3 > - who cares? only confuses the issue I disagree. This is a used multihoming mechanism that is different from all the others. > 4.5 > - this is so different from the other types of multihoming that it's > impossible to discuss it along with those. move this to a different > section. and don't forget that nat in and of itself doesn't do > anything for multihoming. also this isn't mentioned anywhere else so > it's mostly a red herring. I would disagree for the above reason. > 5.1 > - grammar Thanks! > - i think many people wouldn't agree that this is straightforward I think it is straightforward in the ways mentioned. That is not to say it is easy though. > 5.2 > - i partially agree with Marcelo: there are times when sessions don't > survive. however, this is rare in practice Yes, but I agree with Marcello that the limitations should be noted. > 5.3 > - this is a very bad practice as it inflates the (global) routing > table and certainly not the only way to influence INBOUND traffic, not > to mention outbound traffic. also, rfc 1998 is a very good reference > here It doesn't say it's good practice. It says it is used. I am not really sure in what way you want 1998 referenced? > 6.1 > - why avoid 32 bit AS numbers??? this draft has been around for years. > references I have no view on way or the other. I can remove that if needed. > - 7: this was later published as rfc 3221, which makes for a better > reference imo Ok, will change. > > general > - it is never really explained how multihoming is actually done (in a > way that someone who doesn't already do it understands) I don't really understand what you mean here. What is it that you think should be explained better? > Wouldn't starting from scratch be simpler than trying to fix this > document? I don't think so... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQPTgw6arNKXTPFCVEQKHEwCfd7KTPQg3PpRvT3qsD2XjYAC60WAAniUo TN+aKQLEjiZAs4fFtYyEuf28 =Q0yH -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Wed Jul 14 15:26: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 PAA09535 for ; Wed, 14 Jul 2004 15:26:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BkpN0-000HrR-G8 for multi6-data@psg.com; Wed, 14 Jul 2004 19:24:46 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BkpMy-000Hr5-Ns for multi6@ops.ietf.org; Wed, 14 Jul 2004 19:24:45 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6EJPx2r036617; Wed, 14 Jul 2004 21:26:00 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <7B98B8D2-D567-11D8-B57E-000A95928574@kurtis.pp.se> References: <9BF78B66-D43A-11D8-84DE-000A95CD987A@muada.com> <7B98B8D2-D567-11D8-B57E-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <73698850-D5CB-11D8-94A0-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.txt Date: Wed, 14 Jul 2004 21:24:39 +0200 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 14-jul-04, at 9:29, Kurt Erik Lindqvist wrote: >> - the introduction talks about all kinds of details without >> illuminating the big picture > Care to be a bit more specific? Multihoming is an important component of service for many enterprises which are part of the Internet. meaningless Current IPv4 multihoming practices have been added on to the CIDR architecture [1], Anyone who is familiar with why CIDR exists doesn't need to read this document, anyone who needs to read this document won't be helped by this reference in the introduction. Multihoming is a mechanism by which enterprises can currently satisfy a number of high-level requirements, meaningless, list them and is widely used in the IPv4 network today. Actually that's not true. There are around 15k ASes in use world wide, and most of these are ISPs or similar. This leaves only around 5000 - 10000 BGP-type multihomers world wide. The preferred way to multihome in IPv4 is to announce an independent block of address space over two or more ISPs using BGP. The type of address block is a detail that isn't important at this stage in my opinion. Until the mid-1990s this was relatively easy to accomplish, More information without added value. as the maximum generally accepted prefix length in the global routing table was a / 24, and little justification was needed to receive a /24. However, in 1995 the growth of the global routing table became a problem once again, and as a result some providers decided to start filtering prefixes it accepted from peers based on prefix length. This broke the expectation that a multihomed network announcing a /24, regardless of where in the IPv4 address space this /24 was taken from, would be globally reachable. Detail detail detail This practice has two advantages and one disadvantage for the multihomed network. The first advantage is that they can obtain a much smaller block of address space from an ISP than from a RIR. Detail... (Would-be multihomers still often optimize their networks for qualifying for at least a /24 by adopting accepted but relatively wasteful address deployment strategies.) Detail for the detail The second advantage is that even if their announcement We don't even know what an "announcement" is (yet?)... Most ISPs will cooperate with this "punching holes in an aggregate" solution to multihoming, but some are reluctant. More detail. >> - definition for multihomed isn't very good as this also catches >> organizations which use one isp for part of their network and another >> for another part > Yes? Is this a problem? Of course. If I connect my office X to ISP A and office Y to ISP B but don't connect the offices together, that's not multihoming. This is why talking about "enterprises" is dangerous. ("Organization" has the same problem though.) "Site" or "network" would be better. And of course an explicit mention that the ISP connections are shared by the same users/systems. >> - a bgp peer reset isn't a routing protocol failure > Is "Failures signaled by routing protocols" better wording? The problem is not with the wording but with the example. BGP detects reachability failures. There are a few corner cases but those don't belong in a document like this. >> - multihoming doesn't necessarily protect a customer against isp igp >> failure as it is likely that bgp will continue to function in such a >> case > Well, it doesn't protect it automatically but you could manually route > around it for the time being. So a multihomed customer has the option of manually rerouting when there is a failure that isn't detected by BGP. That's certainly true. >> - a bgp peer reset isn't an exchange failure > While I agree, I think it does describe what is happening in the text : > " Exchange failure, such as a BGP reset on an inter-provider > peering." We're talking about multihoming benefits. This has little to do with exchange failure, which a BGP reset isn't. >> 4.1 and 4.2 >> - difference between pa addresses and pa addresses is unclear. what's >> meant here is the difference between having your own block and >> shooting holes in an isp's block > PA and PA are the same :-) I assume you mean PI and PA. No, what I mean is having your own PA block and having an address block that is part of someone else's PA block. PI is different from both. >> - who cares? only confuses the issue > I disagree. This is a used multihoming mechanism that is different from > all the others. There is no legitimate reason to not use an AS number when multihoming. I can't seem to find an RFC that says you can't do it, but sourcing prefixes with an inconsistent origin AS is certainly frowned upon. >> 4.5 >> - this is so different from the other types of multihoming that it's >> impossible to discuss it along with those. move this to a different >> section. and don't forget that nat in and of itself doesn't do >> anything for multihoming. also this isn't mentioned anywhere else so >> it's mostly a red herring. > I would disagree for the above reason. You need to talk about this separately as none of the rest of the document applies to this type of multihoming. >> - this is a very bad practice as it inflates the (global) routing >> table and certainly not the only way to influence INBOUND traffic, not >> to mention outbound traffic. also, rfc 1998 is a very good reference >> here > It doesn't say it's good practice. It says it is used. Yes, and people also use tinfoil for fuses. So should they talk about that in electrical engineering texts? > I am not really sure in what way you want 1998 referenced? RFC 1998 provides a cleaner mechanism to do something similar to what you're describing. >> - it is never really explained how multihoming is actually done (in a >> way that someone who doesn't already do it understands) > I don't really understand what you mean here. What is it that you think > should be explained better? This is what I say on my website about what multihoming is: http://www.bgpexpert.com/#multi I'm not suggesting reusing this text but certainly something conveying this information but written for an IETF audience would be useful in the introduction. From owner-multi6@ops.ietf.org Thu Jul 15 18:18: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 SAA09877 for ; Thu, 15 Jul 2004 18:18:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BlEW8-000GE3-22 for multi6-data@psg.com; Thu, 15 Jul 2004 22:15:52 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BlEW7-000GDj-4p for multi6@ops.ietf.org; Thu, 15 Jul 2004 22:15:51 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA00468 for ; Thu, 15 Jul 2004 15:15:49 -0700 (PDT) Received: from xch-nw-23p.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id i6FMFnc13064 for ; Thu, 15 Jul 2004 17:15:49 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by xch-nw-23p.nw.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Jul 2004 15:15:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.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: FW: I-D ACTION:draft-nikander-multi6-hip-01.txt Date: Thu, 15 Jul 2004 15:15:47 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04522214@xch-nw-27.nw.nos.boeing.com> Thread-Topic: I-D ACTION:draft-nikander-multi6-hip-01.txt Thread-Index: AcRqpeQBdoDwt9GmRsy1A5/L/ZLMUQAEiZJA From: "Henderson, Thomas R" To: "Multi6 List" X-OriginalArrivalTime: 15 Jul 2004 22:15:47.0944 (UTC) FILETIME=[47CEB680:01C46AB9] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Considerations on HIP based IPv6 multi-homing Author(s) : P. Nikander, T. Henderson Filename : draft-nikander-multi6-hip-01.txt Pages : 30 Date : 2004-7-15 =09 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-multi6-hip-01.txt Changelog: Changes between this version (-01) and -00 draft - added Section 2.6 comparing HIP with other group F multi6 proposals - added Section 3.3 describing how HIP could be possibly changed to include routable AIDs - updated references to HIP WG and HIP RG (Section 1.2) From owner-multi6@ops.ietf.org Sun Jul 18 00: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 AAA28048 for ; Sun, 18 Jul 2004 00:02:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bm2qW-00079s-9M for multi6-data@psg.com; Sun, 18 Jul 2004 04:00:16 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bm2qV-00079R-AI for multi6@ops.ietf.org; Sun, 18 Jul 2004 04:00:15 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id 9DA6F4C8 for ; Sun, 18 Jul 2004 00:00:14 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 18 Jul 2004 00:00:14 -0400 Message-Id: <20040718040014.9DA6F4C8@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Messages | Bytes | Who --------+------+--------+----------+------------------------ 18.75% | 3 | 24.28% | 21101 | marcelo@it.uc3m.es 18.75% | 3 | 22.55% | 19601 | kurtis@kurtis.pp.se 18.75% | 3 | 18.05% | 15689 | iljitsch@muada.com 12.50% | 2 | 9.98% | 8672 | jordi.palet@consulintel.es 6.25% | 1 | 9.36% | 8133 | ernst@sfc.wide.ad.jp 6.25% | 1 | 5.95% | 5170 | internet-drafts@ietf.org 6.25% | 1 | 3.41% | 2968 | brc@zurich.ibm.com 6.25% | 1 | 3.38% | 2935 | thomas.r.henderson@boeing.com 6.25% | 1 | 3.04% | 2645 | sra@hactrn.net --------+------+--------+----------+------------------------ 100.00% | 16 |100.00% | 86914 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Mon Jul 19 07:51: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 HAA07069 for ; Mon, 19 Jul 2004 07:51:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmWex-0000JY-SU for multi6-data@psg.com; Mon, 19 Jul 2004 11:50:19 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmWev-0000If-Vh for multi6@ops.ietf.org; Mon, 19 Jul 2004 11:50:18 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6JBoHgB088820 for ; Mon, 19 Jul 2004 11:50:17 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6JBoGNX149762 for ; Mon, 19 Jul 2004 13:50:16 +0200 Received: from zurich.ibm.com (sig-9-145-224-217.de.ibm.com [9.145.224.217]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA77712 for ; Mon, 19 Jul 2004 13:50:16 +0200 Message-ID: <40FBB577.7040601@zurich.ibm.com> Date: Mon, 19 Jul 2004 13:50:15 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Food for thought Content-Type: multipart/mixed; boundary="------------040807070407090809000808" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 This is a multi-part message in MIME format. --------------040807070407090809000808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Please don't start a discussion of renumbering here, but I think many of the operational considerations about adding and dropping prefixes in the referenced draft are likely to apply also to any multihoming solution. Brian -------- Original Message -------- Subject: I-D ACTION:draft-ietf-v6ops-renumbering-procedure-01.txt Date: Fri, 09 Jul 2004 15:34:14 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: v6ops@ops.ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Procedures for Renumbering an IPv6 Network without a Flag Day Author(s) : F. Baker, et al. Filename : draft-ietf-v6ops-renumbering-procedure-01.txt Pages : 24 Date : 2004-7-9 This document describes the steps in a procedure that can be used to transition from the use of an existing prefix to a new prefix in a network. It uses IPv6's intrinsic ability to assign multiple addresses to a network interface to provide continuity of network service through a make-before-break transition, as well as addressing naming and configuration management issues. It also uses other IPv6 features to minimize the effort and time required to complete the transition from the old prefix to the new prefix. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-01.txt --------------040807070407090809000808 Content-Type: Message/External-body; name="draft-ietf-v6ops-renumbering-procedure-01.txt" Content-Disposition: inline; filename="draft-ietf-v6ops-renumbering-procedure-01.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-7-9154924.I-D@ietf.org> --------------040807070407090809000808 Content-Type: text/plain; name="file:///C|/DOCUME%7E1/BRC/LOCALS%7E1/TEMP/nsmail.txt" Content-Disposition: inline; filename="file:///C|/DOCUME%7E1/BRC/LOCALS%7E1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------040807070407090809000808-- From owner-multi6@ops.ietf.org Mon Jul 19 16:36: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 QAA25778 for ; Mon, 19 Jul 2004 16:36:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bmer0-000Pil-HO for multi6-data@psg.com; Mon, 19 Jul 2004 20:35:18 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bmeqz-000Pi6-1v for multi6@ops.ietf.org; Mon, 19 Jul 2004 20:35:17 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6JKaUi9027837; Mon, 19 Jul 2004 22:36:31 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <40FBB577.7040601@zurich.ibm.com> References: <40FBB577.7040601@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <232461AD-D9C3-11D8-A54A-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Iljitsch van Beijnum Subject: Re: Food for thought Date: Mon, 19 Jul 2004 22:35:13 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 19-jul-04, at 13:50, Brian E Carpenter wrote: > Please don't start a discussion of renumbering here, but I think > many of the operational considerations about adding and dropping > prefixes in the referenced draft are likely to apply also to > any multihoming solution. Which part of the draft are you referring to? It seems to me the more natural flow of information would be in the other direction. (But Fred doesn't want that.) From owner-multi6@ops.ietf.org Mon Jul 19 21:19: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 VAA18979 for ; Mon, 19 Jul 2004 21:19:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmjGj-00082q-VG for multi6-data@psg.com; Tue, 20 Jul 2004 01:18:09 +0000 Received: from [207.69.200.157] (helo=tisch.mail.mindspring.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmjGi-00082F-W9 for multi6@ops.ietf.org; Tue, 20 Jul 2004 01:18:09 +0000 Received: from 1cust162.tnt36.dfw9.da.uu.net ([67.234.81.162] helo=ix.netcom.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BmjGZ-0003xC-00; Mon, 19 Jul 2004 21:17:59 -0400 Message-ID: <40FC8C10.819AC1D1@ix.netcom.com> Date: Mon, 19 Jul 2004 20:05:53 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Brian E Carpenter , Multi6 Subject: Re: Food for thought References: <40FBB577.7040601@zurich.ibm.com> <232461AD-D9C3-11D8-A54A-000A95CD987A@muada.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,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 Iljitsch and all, Well what Fred Baker wants he usually gets despite the lack of openness and transparency such desires may engender and the lack of serious discussion that may be important. Iljitsch van Beijnum wrote: > On 19-jul-04, at 13:50, Brian E Carpenter wrote: > > > Please don't start a discussion of renumbering here, but I think > > many of the operational considerations about adding and dropping > > prefixes in the referenced draft are likely to apply also to > > any multihoming solution. > > Which part of the draft are you referring to? > > It seems to me the more natural flow of information would be in the > other direction. (But Fred doesn't want that.) Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Tue Jul 20 03:50:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27406 for ; Tue, 20 Jul 2004 03:50:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BmpMN-000Aou-AQ for multi6-data@psg.com; Tue, 20 Jul 2004 07:48:23 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BmpMM-000AoW-2J for multi6@ops.ietf.org; Tue, 20 Jul 2004 07:48:22 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6K7mDFA117948; Tue, 20 Jul 2004 07:48:13 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6K7mCVB051938; Tue, 20 Jul 2004 09:48:13 +0200 Received: from zurich.ibm.com (sig-9-145-244-133.de.ibm.com [9.145.244.133]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA26872; Tue, 20 Jul 2004 09:48:11 +0200 Message-ID: <40FCCE3B.4050007@zurich.ibm.com> Date: Tue, 20 Jul 2004 09:48:11 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Multi6 Subject: Re: Food for thought References: <40FBB577.7040601@zurich.ibm.com> <232461AD-D9C3-11D8-A54A-000A95CD987A@muada.com> In-Reply-To: <232461AD-D9C3-11D8-A54A-000A95CD987A@muada.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.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 Iljitsch van Beijnum wrote: > On 19-jul-04, at 13:50, Brian E Carpenter wrote: > >> Please don't start a discussion of renumbering here, but I think >> many of the operational considerations about adding and dropping >> prefixes in the referenced draft are likely to apply also to >> any multihoming solution. > > > Which part of the draft are you referring to? > > It seems to me the more natural flow of information would be in the > other direction. (But Fred doesn't want that.) Fred wants to publish an RFC that describes current reality, and that's fine. But we're an Ops area WG, and regardless of which technical solution we adopt, there will be a need for a lot of operational guidance. I think it will be very similar - what does a site have to do when it adds or drops a prefix? I'm referring to the whole draft; which parts of it will *not* apply to multihomed sites? Brian From owner-multi6@ops.ietf.org Tue Jul 20 06:35: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 GAA07024 for ; Tue, 20 Jul 2004 06:35:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bmrxe-0007m7-Q0 for multi6-data@psg.com; Tue, 20 Jul 2004 10:35:02 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bmrxd-0007kr-A7 for multi6@ops.ietf.org; Tue, 20 Jul 2004 10:35:01 +0000 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KAYrx24092; Tue, 20 Jul 2004 13:34:56 +0300 (EET DST) X-Scanned: Tue, 20 Jul 2004 13:34:51 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i6KAYp4K031465; Tue, 20 Jul 2004 13:34:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00RvGC6e; Tue, 20 Jul 2004 13:34:50 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6KAYnu28846; Tue, 20 Jul 2004 13:34:49 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 20 Jul 2004 13:34:49 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: draft remarks Date: Tue, 20 Jul 2004 13:34:49 +0300 Message-ID: Thread-Topic: draft remarks Thread-Index: AcRW1rC2ANMwXsc7TtK1bWresdL0HQXbcyaQ From: To: Cc: X-OriginalArrivalTime: 20 Jul 2004 10:34:49.0994 (UTC) FILETIME=[2F6196A0:01C46E45] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Catching up on mail after vacation ... > > add: > > What are the implications for proxies? >=20 > Hm, this way the document is quickly becoming "list the way your=20 > solution interacts with RFCs 1 - 3800". The value of this document is=20 > that it reminds authors of issues that may be pertinent to their=20 > solution. In order to do this, it's important to offer a rationale for = > including a question. I see no reason why multi-address multihoming=20 > would impact network management or proxies. If you do, it would be = good=20 > to say why, so authors can determine whether your concerns are=20 > warrented. Upon reflection, I agree. With a proper Multi6 solution, the need for some proxies / middleboxes may be less, so I think we don't need to explicitly worry about them. John From owner-multi6@ops.ietf.org Thu Jul 22 05:33: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 FAA04097 for ; Thu, 22 Jul 2004 05:33:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnZud-000Bmx-Uc for multi6-data@psg.com; Thu, 22 Jul 2004 09:30:51 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnZuc-000Bmd-EJ for multi6@ops.ietf.org; Thu, 22 Jul 2004 09:30:50 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6M9UlGm106946; Thu, 22 Jul 2004 09:30:47 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6M9UkW6177814; Thu, 22 Jul 2004 11:30:46 +0200 Received: from zurich.ibm.com (sig-9-145-175-46.de.ibm.com [9.145.175.46]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA51922; Thu, 22 Jul 2004 11:30:45 +0200 Message-ID: <40FF8946.8020406@zurich.ibm.com> Date: Thu, 22 Jul 2004 11:30:46 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Kurt Erik Lindqvist CC: Multi6 List Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.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.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 > Brian will act as WG chair for anything that relates to this draft, I > will act as editor. Well, no chair hat is on for this message. After reading Iljitsch's & Marcelo's comments, and some side conversations, I think we would have a much easier time with this document if section 3 (motivations for mh) was simply removed. Otherwise, we will discuss it for ever and never converge. I suggest limiting to the description of solutions. > 4.5 NAT or RFC2260 based multihoming > > This last method might very well be the most commonly used method in > terms of volume. Simply because this is what most residential users > are normally referred to. That may be true, but it hides the fact that NAT is also very commonly used by enterprise networks, including some *very* big ones. It's the really easy way to avoid advertising a large number of specifics when the same enterprise is connected to the Internet at a large number of points. > 6.1 Scalability > > Current IPV4 multihoming practices contribute to the significant > growth currently observed in the state held in the global > inter-provider routing system; With an important exception - NAT based mh specifically doesn't do this (and probably explains why there has been significant growth in mh without a corresponding explosion in BGP4). Brian From owner-multi6@ops.ietf.org Thu Jul 22 05:45: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 FAA04647 for ; Thu, 22 Jul 2004 05:45:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bna6d-000DNc-2a for multi6-data@psg.com; Thu, 22 Jul 2004 09:43:15 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bna6b-000DNA-Lo for multi6@ops.ietf.org; Thu, 22 Jul 2004 09:43:14 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6M9hCgB077384 for ; Thu, 22 Jul 2004 09:43:12 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6M9hCW6143296 for ; Thu, 22 Jul 2004 11:43:12 +0200 Received: from zurich.ibm.com (sig-9-145-175-46.de.ibm.com [9.145.175.46]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA22910 for ; Thu, 22 Jul 2004 11:43:11 +0200 Message-ID: <40FF8C30.7010808@zurich.ibm.com> Date: Thu, 22 Jul 2004 11:43:12 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: I-D ACTION:draft-palet-multi6-scenarios-00.txt References: <200407131926.PAA06716@ietf.org> In-Reply-To: <200407131926.PAA06716@ietf.org> 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.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 Personal comments: Obviously this still needs quite a lot of work, and I suggest merging in section 3 of draft-ietf-multi6-v4-multihoming-01.txt. Just one direct comment today: > 3.1 Internet Service Provider (ISP) > > An ISP is naturally multihomed when connected to two or more upstream > providers. Actually this is a very common case, especially for > medium and large ISPs. But why should we care? Once we get into BGP4+ territory, multihoming just becomes part of routing. There isn't a scaling problem at this level. Brian From owner-multi6@ops.ietf.org Thu Jul 22 06:13: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 GAA06217 for ; Thu, 22 Jul 2004 06:13:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnaZS-000HgM-5W for multi6-data@psg.com; Thu, 22 Jul 2004 10:13:02 +0000 Received: from [207.69.200.246] (helo=smtp10.atl.mindspring.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnaZR-000Hg1-6w for multi6@ops.ietf.org; Thu, 22 Jul 2004 10:13:01 +0000 Received: from 1cust185.tnt36.dfw9.da.uu.net ([67.234.81.185] helo=ix.netcom.com) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 1BnaZG-0007l7-00; Thu, 22 Jul 2004 06:12:51 -0400 Message-ID: <40FFAC66.C79EE200@ix.netcom.com> Date: Thu, 22 Jul 2004 05:00:42 -0700 From: Jeff Williams Organization: INEGroup Spokesman X-Mailer: Mozilla 4.08 [en] (Win95; U; 16bit) MIME-Version: 1.0 To: Brian E Carpenter CC: Kurt Erik Lindqvist , Multi6 List Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.txt References: <40FF8946.8020406@zurich.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,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 Brian and all, Well really all this won't matter all that much as IPv8 and IPv9 work very smoothly with NAT's as well as ENUM. Brian E Carpenter wrote: > > Brian will act as WG chair for anything that relates to this draft, I > > will act as editor. > > Well, no chair hat is on for this message. > > After reading Iljitsch's & Marcelo's comments, and some side conversations, > I think we would have a much easier time with this document if section 3 > (motivations for mh) was simply removed. Otherwise, we will discuss > it for ever and never converge. I suggest limiting to the description > of solutions. > > > 4.5 NAT or RFC2260 based multihoming > > > > This last method might very well be the most commonly used method in > > terms of volume. Simply because this is what most residential users > > are normally referred to. > > That may be true, but it hides the fact that NAT is also very commonly > used by enterprise networks, including some *very* big ones. It's the really > easy way to avoid advertising a large number of specifics when the same > enterprise is connected to the Internet at a large number of points. > > > 6.1 Scalability > > > > Current IPV4 multihoming practices contribute to the significant > > growth currently observed in the state held in the global > > inter-provider routing system; > > With an important exception - NAT based mh specifically doesn't do this > (and probably explains why there has been significant growth in mh without > a corresponding explosion in BGP4). > > Brian Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Be precise in the use of words and expect precision from others" - Pierre Abelard "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. E-Mail jwkckid1@ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From owner-multi6@ops.ietf.org Thu Jul 22 06:23:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06818 for ; Thu, 22 Jul 2004 06:23:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnajY-000Itm-CI for multi6-data@psg.com; Thu, 22 Jul 2004 10:23:28 +0000 Received: from [192.71.80.74] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnajX-000ItN-93 for multi6@ops.ietf.org; Thu, 22 Jul 2004 10:23:27 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id E72294F5407; Thu, 22 Jul 2004 12:23:29 +0200 (CEST) In-Reply-To: <40FFAC66.C79EE200@ix.netcom.com> References: <40FF8946.8020406@zurich.ibm.com> <40FFAC66.C79EE200@ix.netcom.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <289FBD75-DBC9-11D8-B026-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , Brian E Carpenter From: Kurt Erik Lindqvist Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.txt Date: Thu, 22 Jul 2004 12:23:22 +0200 To: Jeff Williams X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 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 (chair-hat on) On 2004-07-22, at 14.00, Jeff Williams wrote: > Well really all this won't matter all that much as IPv8 and IPv9 work > very smoothly with NAT's as well as ENUM. I suggest you take _that_ discussion to the multi8 and multi9 lists. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQP+VoKarNKXTPFCVEQIgZQCgrPaojRd/DUpa2L4p9hbDVFJ0vS8AoKwB G9LvF5uvtk5p06iU7zZ7EhN1 =BLjD -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Thu Jul 22 09:57:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21006 for ; Thu, 22 Jul 2004 09:57:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bne3G-000L4P-48 for multi6-data@psg.com; Thu, 22 Jul 2004 13:56:02 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bne3E-000L0Y-GV for multi6@ops.ietf.org; Thu, 22 Jul 2004 13:56:01 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6MDtuFA009294 for ; Thu, 22 Jul 2004 13:55:56 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6MDttW6182382 for ; Thu, 22 Jul 2004 15:55:56 +0200 Received: from zurich.ibm.com (sig-9-145-226-207.de.ibm.com [9.145.226.207]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA64540 for ; Thu, 22 Jul 2004 15:55:54 +0200 Message-ID: <40FFC76A.2030902@zurich.ibm.com> Date: Thu, 22 Jul 2004 15:55:54 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Draft multi6 agenda References: <879DB373-D04C-11D8-9ADB-000A95928574@kurtis.pp.se> <40ED1C9F.1090403@zurich.ibm.com> <4547E140-D0C7-11D8-9ADB-000A95928574@kurtis.pp.se> <40ED2215.2090809@zurich.ibm.com> <9514C2C6-D0CA-11D8-9ADB-000A95928574@kurtis.pp.se> <40ED3EEF.2010906@zurich.ibm.com> In-Reply-To: <40ED3EEF.2010906@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.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 Draft agenda. We have to submit it on Monday, so comment right now please! Site Multihoming in IPv6 (multi6) Monday, August 2 at 0900-1130 =============================== CHAIR(s): Brian Carpenter Kurt Lindqvist AGENDA: o Administriva 5 minutes o Agenda Bashing 5 minutes o Review WG drafts in progress 60 minutes --no presentations, resolve open issues only-- draft-ietf-multi6-v4-multihoming-01.txt (10 minutes) draft-ietf-multi6-things-to-think-about-00.txt (10 minutes) draft-ietf-multi6-multihoming-threats-00.txt (20 minutes) draft-ietf-multi6-architecture-00.txt (20 minutes) o Scenarios 5 minutes --brief overview-- draft-palet-multi6-scenarios-00.txt o Further discussion of next steps to develop 75 minutes concrete recommendations for Wedgelayer 3.5 / Fat IP approaches and required components From owner-multi6@ops.ietf.org Thu Jul 22 11:27: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 LAA29142 for ; Thu, 22 Jul 2004 11:27:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnfS9-0008Wi-SG for multi6-data@psg.com; Thu, 22 Jul 2004 15:25:49 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BnfS6-0008W0-MG for multi6@ops.ietf.org; Thu, 22 Jul 2004 15:25:47 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6MEVfGm100406 for ; Thu, 22 Jul 2004 14:31:41 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6MEVfW6163108 for ; Thu, 22 Jul 2004 16:31:41 +0200 Received: from zurich.ibm.com (sig-9-145-226-207.de.ibm.com [9.145.226.207]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA90234 for ; Thu, 22 Jul 2004 16:31:40 +0200 Message-ID: <40FFCFCB.4010904@zurich.ibm.com> Date: Thu, 22 Jul 2004 16:31:39 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 List Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> In-Reply-To: <40E7CAE6.5060503@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.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 Brian E Carpenter wrote: > Some discussion on this thread refers to dependency on HIP. > > Question to the WG: given the current state of HIP, do we > want to consider dependency on HIP as > > a) acceptable > b) unacceptable? > > Brian (co-chair hat on) > There really wasn't much response to this one, but my reading of the sparse consensus was against solutions that depend on the deployment of HIP (but that does not exclude taking ideas or components of HIP). Brian From owner-multi6@ops.ietf.org Thu Jul 22 17:01: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 RAA02372 for ; Thu, 22 Jul 2004 17:01:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BnkfP-0006Es-TJ for multi6-data@psg.com; Thu, 22 Jul 2004 20:59:51 +0000 Received: from [218.219.201.146] (helo=tori.cc) by psg.com with smtp (Exim 4.34 (FreeBSD)) id 1BnkfO-0006EI-BH for multi6@ops.ietf.org; Thu, 22 Jul 2004 20:59:50 +0000 Received: (qmail 27021 invoked by uid 0); 22 Jul 2004 20:59:36 -0000 Received: from unknown (HELO ?192.168.2.20?) (torus@192.168.2.20) by 192.168.2.2 with SMTP; 22 Jul 2004 20:59:36 -0000 Message-ID: <41002AB7.9000707@tori.cc> Date: Fri, 23 Jul 2004 05:59:35 +0900 From: Kenji Ohira User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: multi6@ops.ietf.org Subject: [Fwd: I-D ACTION:draft-ohira-assign-select-e2e-multihome-03.txt] Content-Type: multipart/mixed; boundary="------------080809020605040101070608" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_DYNABLOCK, RCVD_IN_SORBS autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------080809020605040101070608 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, We revised an I-D which can contribute to a hostbased approach. Kenji. ---- Kenji Ohira Kyoto University, Japan -------- Original Message -------- Subject: I-D ACTION:draft-ohira-assign-select-e2e-multihome-03.txt Date: Tue, 20 Jul 2004 15:55:28 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Address Assingment and Route Selection for End-to-End Multihoming Author(s) : K. Ohira, et al. Filename : draft-ohira-assign-select-e2e-multihome-03.txt Pages : 22 Date : 2004-7-20 In this document, we propose a way of address assignment and route selection suitable for "Host-Centric" multihoming, where an end node plays the main role of multihoming. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ohira-assign-select-e2e-multihome-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ohira-assign-select-e2e-multihome-03.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-ohira-assign-select-e2e-multihome-03.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. --------------080809020605040101070608 Content-Type: Message/External-body; name="draft-ohira-assign-select-e2e-multihome-03.txt" Content-Disposition: inline; filename="draft-ohira-assign-select-e2e-multihome-03.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2004-7-20155542.I-D@ietf.org> --------------080809020605040101070608-- From owner-multi6@ops.ietf.org Fri Jul 23 03:48: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 DAA26898 for ; Fri, 23 Jul 2004 03:48:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bnum0-0009QM-4S for multi6-data@psg.com; Fri, 23 Jul 2004 07:47:20 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bnulx-0009PZ-Eb; Fri, 23 Jul 2004 07:47:18 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000154584.msg; Fri, 23 Jul 2004 09:50:17 +0200 Message-ID: <30ca01c47089$384ff090$8700000a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: , , , , , Subject: IEEE SAINT2005 workshop CPF: IPv6 Deployment Status and Challenges Date: Fri, 23 Jul 2004 09:46:50 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Fri, 23 Jul 2004 09:50:17 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Fri, 23 Jul 2004 09:50:20 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL,BAYES_00, X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, The call for papers for this international workshop is now open until October 7. Authors are kindly requested to submit papers as early as possible to facilitate a review process. IEEE SAINT2005 workshop CPF: IPv6 Deployment Status and Challenges http://www.ist-ipv6.org/modules.php?op=3Dmodload&name=3DNews&file=3Darticle&sid=3D659 Please forward this email to all your contacts. Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Sat Jul 24 00: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 AAA14701 for ; Sat, 24 Jul 2004 00:39:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoEHM-0007EG-0k for multi6-data@psg.com; Sat, 24 Jul 2004 04:37:00 +0000 Received: from [207.31.248.245] (helo=thingmagic.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoEHK-0007E2-Tp for multi6@ops.ietf.org; Sat, 24 Jul 2004 04:36:59 +0000 Received: from [66.52.129.2] (account margaret HELO [172.16.100.102]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 117585; Sat, 24 Jul 2004 00:34:09 -0400 Mime-Version: 1.0 X-Sender: margaret@mail.thingmagic.com Message-Id: In-Reply-To: <40E7CAE6.5060503@zurich.ibm.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> Date: Sat, 24 Jul 2004 00:36:43 -0400 To: Brian E Carpenter , Multi6 List From: Margaret Wasserman Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Brian, I saw this question: At 11:16 AM +0200 7/4/04, Brian E Carpenter wrote: >Question to the WG: given the current state of HIP, do we >want to consider dependency on HIP as > >a) acceptable >b) unacceptable? And this answer: >There really wasn't much response to this one, but my reading of the >sparse consensus was against solutions that depend on the deployment >of HIP (but that does not exclude taking ideas or components of HIP). But, I am not really sure what you were asking or what the answer means... I do not think that we should, a priori, assume that a multi6 solution will depend on HIP, NOID, MAST or any other specific mechanism/proposal. However, I also don't think that HIP should be considered out-of-scope for consideration as a solution (any more than NOID, MAST or others). So which way would I answer the question? Margaret From owner-multi6@ops.ietf.org Sat Jul 24 11:06: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 LAA24605 for ; Sat, 24 Jul 2004 11:06:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoO3l-0004mQ-1X for multi6-data@psg.com; Sat, 24 Jul 2004 15:03:37 +0000 Received: from [213.204.46.43] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoO3j-0004m3-HL for multi6@ops.ietf.org; Sat, 24 Jul 2004 15:03:35 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 2F39D4F8DA3; Sat, 24 Jul 2004 17:03:39 +0200 (CEST) In-Reply-To: <40FF8946.8020406@zurich.ibm.com> References: <40FF8946.8020406@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <4B84695A-DCB5-11D8-B026-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.txt Date: Fri, 23 Jul 2004 16:33:42 +0200 To: Brian E Carpenter X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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-07-22, at 11.30, Brian E Carpenter wrote: >> Brian will act as WG chair for anything that relates to this draft, I >> will act as editor. > > Well, no chair hat is on for this message. > > After reading Iljitsch's & Marcelo's comments, and some side > conversations, > I think we would have a much easier time with this document if section > 3 > (motivations for mh) was simply removed. Otherwise, we will discuss > it for ever and never converge. I suggest limiting to the description > of solutions. I agree with this (obviously). If someone _disagrees_, please let me know. I guess we will ask this question in San Diego as well. >> 4.5 NAT or RFC2260 based multihoming >> This last method might very well be the most commonly used method >> in >> terms of volume. Simply because this is what most residential >> users >> are normally referred to. > > That may be true, but it hides the fact that NAT is also very commonly > used by enterprise networks, including some *very* big ones. It's the > really > easy way to avoid advertising a large number of specifics when the same > enterprise is connected to the Internet at a large number of points. Ok, I guess I should add that. >> 6.1 Scalability >> Current IPV4 multihoming practices contribute to the significant >> growth currently observed in the state held in the global >> inter-provider routing system; > > With an important exception - NAT based mh specifically doesn't do this > (and probably explains why there has been significant growth in mh > without > a corresponding explosion in BGP4). Ok, and for consistency I should add a comment on this. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQQEhyaarNKXTPFCVEQI2uwCfUcF7w+GK0Ix+pwEF3lXO5HPEGxoAoLVT 8llMXLuyjMFYAJV4G0bje0sW =i/na -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sat Jul 24 11:06: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 LAA24626 for ; Sat, 24 Jul 2004 11:06:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoO4g-0004ws-3O for multi6-data@psg.com; Sat, 24 Jul 2004 15:04:34 +0000 Received: from [213.204.46.43] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoO4e-0004wO-7G for multi6@ops.ietf.org; Sat, 24 Jul 2004 15:04:33 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 2EFDD4F8DCC; Sat, 24 Jul 2004 17:04:38 +0200 (CEST) In-Reply-To: <73698850-D5CB-11D8-94A0-000A95CD987A@muada.com> References: <9BF78B66-D43A-11D8-84DE-000A95CD987A@muada.com> <7B98B8D2-D567-11D8-B57E-000A95928574@kurtis.pp.se> <73698850-D5CB-11D8-94A0-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Kurt Erik Lindqvist Subject: Re: Updated draft-ietf-multi6-v4-multihoming-01.txt Date: Fri, 23 Jul 2004 16:29:31 +0200 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Iljitsch, my apologies for the late reply. I managed to get ill and be alone in the office and rebuilding networks to get IPv6 to i.root - all at once. So the last week was a bit "exciting"..... On 2004-07-14, at 21.24, Iljitsch van Beijnum wrote: > On 14-jul-04, at 9:29, Kurt Erik Lindqvist wrote: > >>> - the introduction talks about all kinds of details without >>> illuminating the big picture > >> Care to be a bit more specific? What you have written as a response puzzles me a bit. Many of the paragraphs you mention as "details" are more less the same ones as you have listed in your mail to the list on 3 May 2003 commenting on the - -00 draft. Actually, the introduction and your suggested text in the mail was so similar after Vijay had started rewriting the draft that I thought your comment had been addressed with the new text. I won't comment on all the analysis because the above, but I want to address > Multihoming is an important component of service for many > enterprises > which are part of the Internet. > > meaningless As per Brian's mail, we have had off-list discussions that led to the belief that maybe we should strip this document of chapter 3 and all references as to why people want to multihome. > and is widely used in the IPv4 network today. > > Actually that's not true. There are around 15k ASes in use world wide, > and most of these are ISPs or similar. This leaves only around 5000 - > 10000 BGP-type multihomers world wide. Hmm. From Philip Smith's reports Total ASes present in the Internet Routing Table: 17594 Origin-only ASes present in the Internet Routing Table: 15254 Origin ASes announcing only one prefix: 7148 Transit ASes present in the Internet Routing Table: 2340 Transit-only ASes present in the Internet Routing Table: 70 I don't remember the definitions of each of the classes in the report, but I read this as there are at least ~15k potential multihomers. >>> - definition for multihomed isn't very good as this also catches >>> organizations which use one isp for part of their network and another >>> for another part > >> Yes? Is this a problem? > > Of course. If I connect my office X to ISP A and office Y to ISP B but > don't connect the offices together, that's not multihoming. This is > why talking about "enterprises" is dangerous. ("Organization" has the > same problem though.) "Site" or "network" would be better. And of > course an explicit mention that the ISP connections are shared by the > same users/systems. Actually the problem is that neither the definition nor what you write above gives away if this method leads to a growth in the number of routes. I could come up with a (although stretched) example of an enterprise that have sites A and B that are connected to ISP IA and ISP IB respectively. I have one /24 PI space that both ISPs announces. A and B have no direct connection between them, but have a IP-Sec/GRE/MPLS tunnel between them. Am I multihomed? If you think this is a wired example, it's done. Actually some large VPN customers of mine at KPNQwest did it this way. >>> - a bgp peer reset isn't a routing protocol failure > >> Is "Failures signaled by routing protocols" better wording? > > The problem is not with the wording but with the example. BGP detects > reachability failures. There are a few corner cases but those don't > belong in a document like this. As discussed in a private conversation between you, me and Pekka - this text needs to rewritten. >>> 4.1 and 4.2 >>> - difference between pa addresses and pa addresses is unclear. what's >>> meant here is the difference between having your own block and >>> shooting holes in an isp's block > >> PA and PA are the same :-) I assume you mean PI and PA. > > No, what I mean is having your own PA block and having an address > block that is part of someone else's PA block. PI is different from > both. Aha, then I understand you. Ok, agreed. >>> - who cares? only confuses the issue > >> I disagree. This is a used multihoming mechanism that is different >> from >> all the others. > > There is no legitimate reason to not use an AS number when > multihoming. I can't seem to find an RFC that says you can't do it, > but sourcing prefixes with an inconsistent origin AS is certainly > frowned upon. It's certainly also done. > >>> 4.5 >>> - this is so different from the other types of multihoming that it's >>> impossible to discuss it along with those. move this to a different >>> section. and don't forget that nat in and of itself doesn't do >>> anything for multihoming. also this isn't mentioned anywhere else so >>> it's mostly a red herring. > >> I would disagree for the above reason. > > You need to talk about this separately as none of the rest of the > document applies to this type of multihoming. That might be true :-) >>> - this is a very bad practice as it inflates the (global) routing >>> table and certainly not the only way to influence INBOUND traffic, >>> not >>> to mention outbound traffic. also, rfc 1998 is a very good reference >>> here > >> It doesn't say it's good practice. It says it is used. > > Yes, and people also use tinfoil for fuses. So should they talk about > that in electrical engineering texts? Actually solid pieces of iron is more common where I am from. But then the "application" might not be entirely legal either :-) But the result taste ok, and you will normally not get blind... But as for the including this. Yes, I think the textbook should include this. If is is in common use, it should be described. That is not the same as saying that it is good. >> I am not really sure in what way you want 1998 referenced? > > RFC 1998 provides a cleaner mechanism to do something similar to what > you're describing. Yes, but I would almost like to argue that 1998 is less used. But you are right, if we are to include all methods, we should include this as well. > >>> - it is never really explained how multihoming is actually done (in a >>> way that someone who doesn't already do it understands) > >> I don't really understand what you mean here. What is it that you >> think >> should be explained better? > > This is what I say on my website about what multihoming is: > http://www.bgpexpert.com/#multi > > I'm not suggesting reusing this text but certainly something conveying > this information but written for an IETF audience would be useful in > the introduction. Ok, see comments above on the introduction text. BTW, would you agree to remove chapter 3 and the references to motivations for multihoming. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQQEgz6arNKXTPFCVEQJUfQCeNyuxp6/BrcKSD4dQP2ufVrhpemUAoO/k nZqN8vjpbEnlMWvEZBgp96fe =S+C1 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Sat Jul 24 15:08: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 PAA05432 for ; Sat, 24 Jul 2004 15:08:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoRq0-000A4P-NI for multi6-data@psg.com; Sat, 24 Jul 2004 19:05:40 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoRpz-000A45-Fb for multi6@ops.ietf.org; Sat, 24 Jul 2004 19:05:39 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6OJ5bS00751; Sat, 24 Jul 2004 22:05:37 +0300 (EET DST) X-Scanned: Sat, 24 Jul 2004 22:05:13 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i6OJ5D1p015147; Sat, 24 Jul 2004 22:05:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00V2LSGh; Sat, 24 Jul 2004 22:05:12 EEST 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 i6OJ5Bn21079; Sat, 24 Jul 2004 22:05:11 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 24 Jul 2004 22:05:09 +0300 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: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] Date: Sat, 24 Jul 2004 22:05:08 +0300 Message-ID: Thread-Topic: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] Thread-Index: AcRwBRkLV87FPuFKSwGv01UUYnmjfwBq99pw From: To: , X-OriginalArrivalTime: 24 Jul 2004 19:05:09.0427 (UTC) FILETIME=[23A34830:01C471B1] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Brian, > > Question to the WG: given the current state of HIP, do we > > want to consider dependency on HIP as > >=20 > > a) acceptable > > b) unacceptable? > >=20 > > Brian (co-chair hat on) > >=20 >=20 > There really wasn't much response to this one, but my reading of the > sparse consensus was against solutions that depend on the deployment > of HIP (but that does not exclude taking ideas or components of HIP). I don't think Multi6 & HIP should fate-share. In other words, I think = that=20 Multi6 could work on something independent of HIP, if the WG felt that was the proper direction for the work. John From owner-multi6@ops.ietf.org Sun Jul 25 00:02:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00091 for ; Sun, 25 Jul 2004 00:02:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoaBS-0003dU-3g for multi6-data@psg.com; Sun, 25 Jul 2004 04:00:22 +0000 Received: from [66.92.66.68] (helo=cyteen.hactrn.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BoaBO-0003cd-7T for multi6@ops.ietf.org; Sun, 25 Jul 2004 04:00:19 +0000 Received: from hactrn.net (localhost [127.0.0.1]) by cyteen.hactrn.net (Postfix) with ESMTP id BE978376 for ; Sun, 25 Jul 2004 00:00:12 -0400 (EDT) To: multi6@ops.ietf.org Subject: Weekly posting summary for multi6@ops.ietf.org From: Rob Austein Date: Sun, 25 Jul 2004 00:00:12 -0400 Message-Id: <20040725040012.BE978376@cyteen.hactrn.net> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Messages | Bytes | Who --------+------+--------+----------+------------------------ 40.00% | 6 | 37.86% | 20084 | brc@zurich.ibm.com 20.00% | 3 | 27.60% | 14644 | kurtis@kurtis.pp.se 13.33% | 2 | 12.33% | 6543 | john.loughney@nokia.com 6.67% | 1 | 8.76% | 4648 | torus@tori.cc 6.67% | 1 | 4.93% | 2618 | margaret@thingmagic.com 6.67% | 1 | 4.58% | 2432 | sra@hactrn.net 6.67% | 1 | 3.92% | 2081 | iljitsch@muada.com --------+------+--------+----------+------------------------ 100.00% | 15 |100.00% | 53050 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the MULTI6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. From owner-multi6@ops.ietf.org Sun Jul 25 04:13: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 EAA23817 for ; Sun, 25 Jul 2004 04:13:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Boe6Y-0008C7-RK for multi6-data@psg.com; Sun, 25 Jul 2004 08:11:34 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Boe6U-0008BE-7P for multi6@ops.ietf.org; Sun, 25 Jul 2004 08:11:30 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6P8BSgB104762; Sun, 25 Jul 2004 08:11:28 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6P8BSMg067584; Sun, 25 Jul 2004 10:11:28 +0200 Received: from zurich.ibm.com (sig-9-145-143-150.de.ibm.com [9.145.143.150]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA41310; Sun, 25 Jul 2004 10:11:26 +0200 Message-ID: <41036B2C.6090408@zurich.ibm.com> Date: Sun, 25 Jul 2004 10:11:24 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Margaret Wasserman CC: Multi6 List Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Margaret Wasserman wrote: > > Hi Brian, > > I saw this question: > > At 11:16 AM +0200 7/4/04, Brian E Carpenter wrote: > >> Question to the WG: given the current state of HIP, do we >> want to consider dependency on HIP as >> >> a) acceptable >> b) unacceptable? > > > And this answer: > >> There really wasn't much response to this one, but my reading of the >> sparse consensus was against solutions that depend on the deployment >> of HIP (but that does not exclude taking ideas or components of HIP). > > > But, I am not really sure what you were asking or what the answer means... > > I do not think that we should, a priori, assume that a multi6 solution will > depend on HIP, NOID, MAST or any other specific mechanism/proposal. > However, I also don't think that HIP should be considered out-of-scope for > consideration as a solution (any more than NOID, MAST or others). > > So which way would I answer the question? Well, that's exactly why I summarized as I did - as so often, the question was too binary. Brian From owner-multi6@ops.ietf.org Sun Jul 25 05:07: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 FAA26691 for ; Sun, 25 Jul 2004 05:07:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BoexA-000DyI-KC for multi6-data@psg.com; Sun, 25 Jul 2004 09:05:56 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Boex8-000Dxo-Gy for multi6@ops.ietf.org; Sun, 25 Jul 2004 09:05:54 +0000 Received: from consulintel02 by consulintel.es (MDaemon.PRO.v7.1.2.R) with ESMTP id md50000157367.msg for ; Sun, 25 Jul 2004 11:08:56 +0200 Message-ID: <01b201c47226$8fe21a60$640a0a0a@consulintel.es> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: References: <200407131926.PAA06716@ietf.org> <40FF8C30.7010808@zurich.ibm.com> Subject: Re: I-D ACTION:draft-palet-multi6-scenarios-00.txt Date: Sun, 25 Jul 2004 11:05:40 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Authenticated-Sender: jordi.palet@consulintel.es X-Spam-Processed: consulintel.es, Sun, 25 Jul 2004 11:08:56 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: multi6@ops.ietf.org X-MDAV-Processed: consulintel.es, Sun, 25 Jul 2004 11:09:00 +0200 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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: quoted-printable Hi Brian, Agree that the document still requires work ... it was a first try to get a base document ready for San Diego. I'm not convinced in merging, at least not in section 3. Probably some text in section 3, but some other will require a new section. Really not sure, anyway, we can talk about this in San Diego, and also see what the other co-authors think. Regarding the ISP case, what you mention is clear to me, but the document just try to document all the cases, trying to be neutral and not excluding those that are solved already. Regards, Jordi ---- Original Message ---- From: "Brian E Carpenter" To: "Multi6" Sent: Thursday, July 22, 2004 11:43 AM Subject: Re: I-D ACTION:draft-palet-multi6-scenarios-00.txt > Personal comments: >=20 > Obviously this still needs quite a lot of work, and I suggest > merging in section 3 of draft-ietf-multi6-v4-multihoming-01.txt. >=20 > Just one direct comment today: >=20 >> 3.1 Internet Service Provider (ISP) >>=20 >> An ISP is naturally multihomed when connected to two or more upstream >> providers. Actually this is a very common case, especially for >> medium and large ISPs. >=20 > But why should we care? Once we get into BGP4+ territory, multihoming just > becomes part of routing. There isn't a scaling problem at this level. >=20 > Brian ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-multi6@ops.ietf.org Sun Jul 25 14:46: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 OAA21099 for ; Sun, 25 Jul 2004 14:46:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1Bonyd-000DJz-4w for multi6-data@psg.com; Sun, 25 Jul 2004 18:44:03 +0000 Received: from [131.160.192.2] (helo=p2.piuha.net) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1Bonyb-000DJP-UH for multi6@ops.ietf.org; Sun, 25 Jul 2004 18:44:02 +0000 Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 9F05B89849; Sun, 25 Jul 2004 21:42:41 +0300 (EEST) Message-ID: <4103FDAC.3060808@piuha.net> Date: Sun, 25 Jul 2004 21:36:28 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: Margaret Wasserman , Multi6 List Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <41036B2C.6090408@zurich.ibm.com> In-Reply-To: <41036B2C.6090408@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.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 Brian E Carpenter wrote: >>> There really wasn't much response to this one, but my reading of the >>> sparse consensus was against solutions that depend on the deployment >>> of HIP (but that does not exclude taking ideas or components of HIP). >> >> >> >> But, I am not really sure what you were asking or what the answer >> means... >> >> I do not think that we should, a priori, assume that a multi6 solution >> will >> depend on HIP, NOID, MAST or any other specific mechanism/proposal. >> However, I also don't think that HIP should be considered out-of-scope >> for >> consideration as a solution (any more than NOID, MAST or others). >> >> So which way would I answer the question? > > > Well, that's exactly why I summarized as I did - as so often, the question > was too binary. I agree that the question was too binary. [But I also think that posing the question at this time is a bit unfair on HIP. The responses that you got were that its either OK to use HIP or that HIP lacks feature X or Y which make it problematic to use it. The problem is, most if not all proposals in the category of solutions we are considering have such deficiencies; our task is to compose or develop a solution which overcomes these difficulties.] So, I think we should adopt ideas from HIP/NOID/WIMP/etc and/or develop one of them further to fulfill all our requirements. So, in a sense I agree with the second part of Brian's summary -- but it applies for all of the potential solutions we have. But I'm not sure I understand the deployment part. I mean I agree that we should not hold our breath in Multi6 while HIP gets deployed. But this is again similar in all of the solutions. Most of them (with the possible exception of HIP and maybe some others) would get deployed only when people install the multi6 feature on their nodes. --Jari From owner-multi6@ops.ietf.org Sun Jul 25 18:17: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 SAA00964 for ; Sun, 25 Jul 2004 18:17:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.34 (FreeBSD)) id 1BorGx-0001yq-UG for multi6-data@psg.com; Sun, 25 Jul 2004 22:15:11 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.34 (FreeBSD)) id 1BorGw-0001yI-T6 for multi6@ops.ietf.org; Sun, 25 Jul 2004 22:15:11 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6PMGDnw032500; Mon, 26 Jul 2004 00:16:13 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <4103FDAC.3060808@piuha.net> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <41036B2C.6090408@zurich.ibm.com> <4103FDAC.3060808@piuha.net> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <10D55EAA-DE88-11D8-BA4E-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] Date: Mon, 26 Jul 2004 00:14:58 +0200 To: jari.arkko@piuha.net X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 25-jul-04, at 20:36, Jari Arkko wrote: > I also think that posing the question at this time is a bit unfair on > HIP. The responses that you got were that its either OK to use HIP or > that HIP lacks feature X or Y which make it problematic to use it. The > problem is, most if not all proposals in the category of solutions we > are considering have such deficiencies; our task is to compose or > develop a solution which overcomes these difficulties. The way I understood Brian's question is: would it be ok to build on HIP the same way some proposed solutions build on the DNS, ie., just assume that it's there and that it works. My answer to this was that there are two issues: the first is that HIP isn't deployed yet. This will/can be solved in time and propbably isn't all that important in the long run. Still, building on HIP _now_ would probably make our life more difficult. The second is that HIP as it is today has certain properties that are undesirable for a generic multihoming solution. (Larger packets and mandatory crypto.) This would be like using the DNS but the DNS takes 15 minutes to resolve a query: you can build such a solution, but it doesn't address the user needs very well.. So basically what we're saying is that we only want to use HIP if it's modified to our liking. :-) This isn't unfair as we want all the solutions to be modified to our liking. (-: From owner-multi6@ops.ietf.org Mon Jul 26 03:19: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 DAA05297 for ; Mon, 26 Jul 2004 03:19:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bozi0-00018p-Qs for multi6-data@psg.com; Mon, 26 Jul 2004 07:15:40 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bozhz-00018K-2O for multi6@ops.ietf.org; Mon, 26 Jul 2004 07:15:39 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6Q7FZgB022060 for ; Mon, 26 Jul 2004 07:15:35 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6Q7FY0m182362 for ; Mon, 26 Jul 2004 09:15:34 +0200 Received: from zurich.ibm.com (sig-9-145-226-205.de.ibm.com [9.145.226.205]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA55530 for ; Mon, 26 Jul 2004 09:15:33 +0200 Message-ID: <4104AF95.8040608@zurich.ibm.com> Date: Mon, 26 Jul 2004 09:15:33 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt References: <200407091529.LAA05687@ietf.org> In-Reply-To: <200407091529.LAA05687@ietf.org> 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.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 (Chair hat off) I guess I have three high level concerns with NOID. 1. I am uncomfortable about the dependency on reverse DNS. It will effectively mean that only well-run servers can benefit from mh, because client systems with temporary addresses (especially RFC 3041 addresses) are realistically unlikely to have reverse DNS in place. And that probably eliminates mh for peer-to-peer applications too, which is a shame. 2. I'd have liked to see a walk-through for a 3rd-party referral case (i.e. how would it work for p2p anyway?). 3. I am also uncomfortable about "the bit." The whole of section 6 is, well, a bit kludgy. The only clean solution IMHO is a shim header, which knocks 8 bytes off the user's MTU. In the catgeory of possible alternatives, we could in theory add - encode a couple of bits in the flow label - get back the ECN bits (I'm not advocating either of these, but since the draft lists alternatives...) Brian From owner-multi6@ops.ietf.org Mon Jul 26 03:28: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 DAA05726 for ; Mon, 26 Jul 2004 03:28:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Boztx-0002d3-34 for multi6-data@psg.com; Mon, 26 Jul 2004 07:28:01 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Boztv-0002ci-KL for multi6@ops.ietf.org; Mon, 26 Jul 2004 07:28:00 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6Q7RuGm059722; Mon, 26 Jul 2004 07:27:56 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6Q7RtPi056244; Mon, 26 Jul 2004 09:27:55 +0200 Received: from zurich.ibm.com (sig-9-145-226-205.de.ibm.com [9.145.226.205]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA96416; Mon, 26 Jul 2004 09:27:54 +0200 Message-ID: <4104B27A.4070206@zurich.ibm.com> Date: Mon, 26 Jul 2004 09:27:54 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: JORDI PALET MARTINEZ CC: multi6@ops.ietf.org Subject: Re: I-D ACTION:draft-palet-multi6-scenarios-00.txt References: <200407131926.PAA06716@ietf.org> <40FF8C30.7010808@zurich.ibm.com> <01b201c47226$8fe21a60$640a0a0a@consulintel.es> In-Reply-To: <01b201c47226$8fe21a60$640a0a0a@consulintel.es> 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.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 Jordi, JORDI PALET MARTINEZ wrote: > Hi Brian, > > Agree that the document still requires work ... it was a first try to get a base document ready for San Diego. > > I'm not convinced in merging, at least not in section 3. Probably some text in section 3, but some other will require a new section. Really not sure, anyway, we can talk about this in San Diego, and also see what the other co-authors think. > > Regarding the ISP case, what you mention is clear to me, but the document just try to document all the cases, trying to be neutral and not excluding those that are solved already. Correct, but that does illustrate the overlap with draft-ietf-multi6-v4-multihoming-01.txt which of courses discusses exactly that scenario as a solution. Brian > > Regards, > Jordi > > ---- Original Message ---- > From: "Brian E Carpenter" > To: "Multi6" > Sent: Thursday, July 22, 2004 11:43 AM > Subject: Re: I-D ACTION:draft-palet-multi6-scenarios-00.txt > > >>Personal comments: >> >>Obviously this still needs quite a lot of work, and I suggest >>merging in section 3 of draft-ietf-multi6-v4-multihoming-01.txt. >> >>Just one direct comment today: >> >> >>>3.1 Internet Service Provider (ISP) >>> >>> An ISP is naturally multihomed when connected to two or more upstream >>> providers. Actually this is a very common case, especially for >>> medium and large ISPs. >> >>But why should we care? Once we get into BGP4+ territory, multihoming just >>becomes part of routing. There isn't a scaling problem at this level. >> >> Brian > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > From owner-multi6@ops.ietf.org Mon Jul 26 03:41:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06771 for ; Mon, 26 Jul 2004 03:41:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp06Y-0004ay-Ka for multi6-data@psg.com; Mon, 26 Jul 2004 07:41:02 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp06X-0004ag-II for multi6@ops.ietf.org; Mon, 26 Jul 2004 07:41:02 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i6Q7exv07947; Mon, 26 Jul 2004 10:40:59 +0300 Date: Mon, 26 Jul 2004 10:40:59 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Multi6 Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt In-Reply-To: <4104AF95.8040608@zurich.ibm.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.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 On Mon, 26 Jul 2004, Brian E Carpenter wrote: > 1. I am uncomfortable about the dependency on reverse DNS. It will effectively > mean that only well-run servers can benefit from mh, because client systems > with temporary addresses (especially RFC 3041 addresses) are realistically > unlikely to have reverse DNS in place. And that probably eliminates mh for > peer-to-peer applications too, which is a shame. (I haven't had time to look at the NOID draft in more detail, so let's hope I'm not missing some critical context..) RFC 3041 describes that those addresses can be added to the reverse tree as well (e.g., such as a hexadecimal string of the address), just without any real meaning for identifying the node. This is also mentioned in draft-ietf-dnsop-ipv6-dns-issues-08.txt section 2.2. However, for not to lose privacy this would probably mean at least two things: 1) the node must not have non-temporary addresses, at least in the (same) forward DNS name (as the public address) 2) the temporary reverses would have to be added automatically etc. -- draft-ietf-dnsop-ipv6-dns-issues-08.txt analyzes the feasibility of this to some degree. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-multi6@ops.ietf.org Mon Jul 26 05:25: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 FAA10691 for ; Mon, 26 Jul 2004 05:25:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp1ie-000Jia-9z for multi6-data@psg.com; Mon, 26 Jul 2004 09:24:28 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp1id-000Ji6-1x for multi6@ops.ietf.org; Mon, 26 Jul 2004 09:24:27 +0000 Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 97F2D8; Mon, 26 Jul 2004 12:24:24 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <947A318C-DEE5-11D8-9324-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Christian Huitema From: Pekka Nikander Subject: Re: Unique identifiers and privacy Date: Mon, 26 Jul 2004 12:24:22 +0300 To: Multi6 List X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 [Catching up e-mail] On Jul 9, 2004, at 21:31, Christian Huitema wrote: > I am concerned with the general statement that we should merely "do no > worse than the current state of the art". I am specifically concerned > with the use of long lived unique identifiers. ... > > If we do use identifiers, we should obviously allow systems to create > short-lived identifiers, and to use different identifiers for different > activities. However, we should be very concerned with the default > behavior. .... For the record, I strongly agree with Christian. This is an important issue. In my opinion, it is also important to make it sufficiently hard to link the network layer identifiers of a mobile user. That is, if a host changes its point of attachment, the default should be that it can use a new network layer identifier / identifiers at the new location, and linking the old identifier(s) with the new identifier(s) should be hard for the average non-participating attacker / eavesdropper. (What is hard enough is debatable, of course.) RFC3014 succeeds in fulfilling this goal for certain types of traffic with suitable implementations (e.g. HTTP where the underlying IP address is changed) but not for others. Mobile IPv6 fails miserably, unfortunately. MULTI6 should not make the situation any worse, and preferably should make it better. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Jul 26 05:32: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 FAA11007 for ; Mon, 26 Jul 2004 05:32:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp1ps-000Kfp-6f for multi6-data@psg.com; Mon, 26 Jul 2004 09:31:56 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp1pp-000KfX-UN for multi6@ops.ietf.org; Mon, 26 Jul 2004 09:31:54 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6Q9VrgB070646 for ; Mon, 26 Jul 2004 09:31:53 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6Q9VqPi052604 for ; Mon, 26 Jul 2004 11:31:52 +0200 Received: from zurich.ibm.com (sig-9-145-226-205.de.ibm.com [9.145.226.205]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA80048 for ; Mon, 26 Jul 2004 11:31:52 +0200 Message-ID: <4104CF87.8050706@zurich.ibm.com> Date: Mon, 26 Jul 2004 11:31:51 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Multi6 Subject: Re: Draft multi6 agenda References: <879DB373-D04C-11D8-9ADB-000A95928574@kurtis.pp.se> <40ED1C9F.1090403@zurich.ibm.com> <4547E140-D0C7-11D8-9ADB-000A95928574@kurtis.pp.se> <40ED2215.2090809@zurich.ibm.com> <9514C2C6-D0CA-11D8-9ADB-000A95928574@kurtis.pp.se> <40ED3EEF.2010906@zurich.ibm.com> <40FFC76A.2030902@zurich.ibm.com> In-Reply-To: <40FFC76A.2030902@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.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 Since there were no comments over the weekend, the attached agenda has been submitted. I'd like to remind people to be sure to read the 4 WG drafts in progress (listed below), and either email a summary of your issues to the list, or be ready to state them briefly at the microphone. The authors are asked to be ready with a summary of open issues (and no more). For the closing discussion, please review the minutes of the interim meeting http://ops.ietf.org/multi6/interim-04/interim-meeting-minutes.txt and the summary of next steps http://ops.ietf.org/lists/multi6/multi6.2004/msg00974.html Brian co-chair hat on Brian E Carpenter wrote: > Draft agenda. We have to submit it on Monday, so comment right now > please! > > Site Multihoming in IPv6 (multi6) > > Monday, August 2 at 0900-1130 > =============================== > > CHAIR(s): Brian Carpenter > Kurt Lindqvist > > AGENDA: > > o Administriva 5 minutes > > o Agenda Bashing 5 minutes > > o Review WG drafts in progress 60 minutes > --no presentations, resolve open issues only-- > draft-ietf-multi6-v4-multihoming-01.txt (10 minutes) > draft-ietf-multi6-things-to-think-about-00.txt (10 minutes) > draft-ietf-multi6-multihoming-threats-00.txt (20 minutes) > draft-ietf-multi6-architecture-00.txt (20 minutes) > > o Scenarios 5 minutes > --brief overview-- > draft-palet-multi6-scenarios-00.txt > > o Further discussion of next steps to develop 75 minutes > concrete recommendations for Wedgelayer 3.5 / > Fat IP approaches and required components > > > > > From owner-multi6@ops.ietf.org Mon Jul 26 06:39: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 GAA13384 for ; Mon, 26 Jul 2004 06:39:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp2sD-0004S8-Mn for multi6-data@psg.com; Mon, 26 Jul 2004 10:38:25 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp2sC-0004RZ-65 for multi6@ops.ietf.org; Mon, 26 Jul 2004 10:38:24 +0000 Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 582148; Mon, 26 Jul 2004 13:38:23 +0300 (EEST) In-Reply-To: <40FFCFCB.4010904@zurich.ibm.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Pekka Nikander Subject: Re: Question re HIP dependency & some architectural considerations Date: Mon, 26 Jul 2004 13:38:22 +0300 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 [Catching up e-mail] Brian and others, >> Some discussion on this thread refers to dependency on HIP. >> Question to the WG: given the current state of HIP, do we >> want to consider dependency on HIP as >> a) acceptable >> b) unacceptable? >> Brian (co-chair hat on) > > There really wasn't much response to this one, but my reading of the > sparse consensus was against solutions that depend on the deployment > of HIP (but that does not exclude taking ideas or components of HIP). Personally, and as far as I understand the goals for multi6, I don't think that HIP -- as it is currently being defined -- fulfils the multi6 goals. (Some people claim that none of the other solutions on the table do that either; I refrain to comment since I am too far back in reading the drafts.) But anyway, if I do understand your question correctly, IMHO it is "unacceptable" to "depend" on HIP. However, I do believe that HIP has a number of components and ideas that could, if so desired, be reused for the multi6 solution. I also do believe that it is possible, again if so desired, to make the eventual multi6 solution "forward compatible" with HIP. The latter would probably required some changes to HIP, but I don't see that as a problem. Anyway, I believe that HIP will necessarily undergo a number of incompatible changes from Experimental to PS, if it ever gets that far. More importantly, there are a number of important architectural issues lurking here behind. These relate to a) the nature of EIDs b) API evolution c) performance penalty and nature of multi-homed applications a) Firstly, HIP is not only about id/loc split, and thereby facilitating end-host mobility and multi-homing. It is also about moving from using "ordinary" non-crypto-based identifiers towards using cryptographically strong identifiers, i.e., public keys. From an architectural point of view, one can consider this as a potentially far more important change than moving from IPv4 to IPv6. This is one of the primary reasons why I do believe that HIP warrants development of its own, independent of multi6, mobike, etc. b) Secondly, it starts to look like that we really should start to think about the API issues more seriously. As an example, HIP does support multiple different APIs (IPv4 LSI and IPv6 HIT based currently, native HIP fairly soon). Furthermore, it does support (limited) application interoperability, i.e., simple applications can talk to each other independent of the API they use. At the HIP list, we have been discussing about adding support for IPv6 non-HIT based API to this list, but a security analysis of that solution is still to be seen. Looking at the multi6 goals and recent discussion, it looks like that any acceptable solutions MUST support unmodified IPv6 API, using routable IPv6 addresses as API level identifiers. Only that way we can fully support all existing applications. To me, it remains an interesting question how to support API evolution. One architectural possibility would be to use HIP as an example: - convert AIDs into EIDs at the API level - use EIDs to establish the end-to-end context - map EIDs to IP addresses when sending packets out and, of course, vice versa at the receiving end. This using of internal EIDs that are not IP addresses in the protocol layer seems to offer an evolution path for the API. (See also the HIP architecture draft, draft-moskowitz-hip-arch-06.txt, Section 4.1. Badly formatted, sorry, but I was in hurry when submitting -06, and xml2rfc was changed.) c) Thirdly, but perhaps less importantly, it looks like that we should also take an architectural stance at the performance implications. Some people seem to have an opinion that requiring one to perform an authenticating D-H exchange each and every time one wants to use multi-homing is unacceptable. But is it really so? If your application needs the multi-homing benefits, doesn't that usually mean that it expects to continue communication over some time span? If so, does the less-than-second delay caused by authenticated D-H really matter? Related to this, it does look like that we could develop a protocol where the hosts have a very light weight piggybacked exchange initially, with reasonable initial security and the possibility to "upgrade" the context security into authenticated D-H level. However, such a protocol is inherently more complex than one where one always performs authenticated D-H initially. Hence, to me the question is whether the performance benefit from the delayed state set up is really worth the added complexity, taking the nature of multi-homed applications into consideration? ---- Just looking at the multi6 goals and things to think about is of course right in the multi6 context. However, to me the "larger" questions about EID nature and API evolution are perhaps more important. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Jul 26 06:56: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 GAA14394 for ; Mon, 26 Jul 2004 06:56:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp39r-0007WT-0j for multi6-data@psg.com; Mon, 26 Jul 2004 10:56:39 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp39p-0007W6-Sa for multi6@ops.ietf.org; Mon, 26 Jul 2004 10:56:38 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8AE093A2E6; Mon, 26 Jul 2004 12:56:36 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 235B83A329; Mon, 26 Jul 2004 12:56:36 +0200 (CEST) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: Question re HIP dependency & some architectural considerations Date: Mon, 26 Jul 2004 12:58:14 +0200 To: Pekka Nikander X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Pekka, I agree with most of your comments, just a clarification question here.... > > To me, it remains an interesting question how to support API evolution. > One architectural possibility would be to use HIP as an example: > - convert AIDs into EIDs at the API level > - use EIDs to establish the end-to-end context > - map EIDs to IP addresses when sending packets out > This is how hip works today, right? i mean in the HIP case: AID==HIT EID==HI I guess that what it seems that we need is to support routable AIDs, and provide the means to securely bind them to the corresponding EID, right? regards, marcelo From owner-multi6@ops.ietf.org Mon Jul 26 07:42: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 HAA15897 for ; Mon, 26 Jul 2004 07:42:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp3rP-000E1T-9o for multi6-data@psg.com; Mon, 26 Jul 2004 11:41:39 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp3rG-000E04-CW for multi6@ops.ietf.org; Mon, 26 Jul 2004 11:41:30 +0000 Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 856718; Mon, 26 Jul 2004 14:41:28 +0300 (EEST) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Pekka Nikander Subject: Re: Question re HIP dependency & some architectural considerations Date: Mon, 26 Jul 2004 14:41:27 +0300 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 >> To me, it remains an interesting question how to support API >> evolution. >> One architectural possibility would be to use HIP as an example: >> - convert AIDs into EIDs at the API level >> - use EIDs to establish the end-to-end context >> - map EIDs to IP addresses when sending packets out > > This is how hip works today, right? Yes, more or less. However, the details in various implementations are different. > i mean in the HIP case: > AID==HIT > EID==HI Yes, with the addition that the AID can also be an LSI instead of a HIT, and there has been some discussions of allowing the AID to be a routable IP address of the peer host. > I guess that what it seems that we need is to support routable AIDs, > and provide the means to securely bind them to the corresponding EID, > right? Well, I think so. But, at least for the time being, I remain puzzled about what does the "secure binding" mean, exactly. Anyway, the AID is primarily a thing that is internal to the host. For simple applications, the AID never leaves the host since the IP address in the wire is conceptually different from the AID, even if they happen to have the same binary value. The problems are created by the desire to be backwards compatible with referrals and with non-RFC1958-conformant applications. For them, the AID needs to be a routable IP address that can be used to reach the peer. Hence, for them the AID does appear outside of the host, both conceptually and in practise. The security problem is created when the host that uses the AID does not have a corresponding EID-level association with the peer identified with the AID. One needs to have a secure enough way to tell whether the peer has an EID or not, and if it does, what its EID is. There are obviously various approaches in providing assurance, such as using CGA (and some bit in the address to indicate whether CGA is used or not), using WIMP, using opportunistic HIP, etc. I tend to believe that just using some end-to-end protocol might be secure enough. That would obviously be vulnerable to man-in-the-middle attackers, but so is current IP. However, I am worried about the case where a MitM attacker hands over a different EID to the initiating host, thereby creating a false AID-to-EID mapping at that host, and then using the multi6 protocol to claim that the AID-IP-address is no longer reachable. Such an attack can potentially cause quite a lot of harm, but of course only if the host can be lured to try to make a contact to the AID. However, that is easy enough in many cases. Using CGA based AIDs seems to provide enough security. However, if we want to pursue that further, we would have to consider the IPR. --Pekka Nikander From owner-multi6@ops.ietf.org Mon Jul 26 11:07: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 LAA10482 for ; Mon, 26 Jul 2004 11:07:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bp72M-000FCA-MZ for multi6-data@psg.com; Mon, 26 Jul 2004 15:05:10 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bp72I-000F8t-6N for multi6@ops.ietf.org; Mon, 26 Jul 2004 15:05:06 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id EC2403A102; Mon, 26 Jul 2004 17:05:04 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id B911F3A0F7; Mon, 26 Jul 2004 17:05:04 +0200 (CEST) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <66F7C35E-DF15-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: Question re HIP dependency & some architectural considerations Date: Mon, 26 Jul 2004 17:06:42 +0200 To: Pekka Nikander X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Pekka, I include some comments mostly about the reasoning behind your=20 conclusions, since i agree with your conclusions El 26/07/2004, a las 13:41, Pekka Nikander escribi=F3: >>> To me, it remains an interesting question how to support API=20 >>> evolution. >>> One architectural possibility would be to use HIP as an example: >>> - convert AIDs into EIDs at the API level >>> - use EIDs to establish the end-to-end context >>> - map EIDs to IP addresses when sending packets out >> >> This is how hip works today, right? > > Yes, more or less. However, the details in various implementations > are different. > >> i mean in the HIP case: >> AID=3D=3DHIT >> EID=3D=3DHI > > Yes, with the addition that the AID can also be an LSI instead of a=20 > HIT, > and there has been some discussions of allowing the AID to be a > routable IP address of the peer host. > >> I guess that what it seems that we need is to support routable AIDs, >> and provide the means to securely bind them to the corresponding EID, >> right? > > Well, I think so. But, at least for the time being, I remain puzzled > about what does the "secure binding" mean, exactly. Anyway, the AID > is primarily a thing that is internal to the host. For simple > applications, the AID never leaves the host since the IP address in > the wire is conceptually different from the AID, even if they happen > to have the same binary value. I am not sure i understand this statement, about AID never leaving the=20= host. I mean, suppose the Host A is communicating with Host B, then Host A=20 identifies Host B through its AID i.e. AIDB. So as matter of fact, AIDB=20= is not internal to host B, since it is used by Host A (even though=20 packets from Host A to Host B don't really carry AIDB in the address=20 field of the IP header) But i guess that you meant something different by that AID never leave=20= the hosts... [Side Note: Also, i think that the AID should be used as IP address=20 (i.e. locator) for the initial packets, since i believe it would allow=20= to delay the security checks to the moment you need to start using an=20 alternative address. I mean, initial packets just use the AID as the IP address contained in=20= the received packet (no additional security checks are required) and=20 then if you need to change locators, you start performing more complex. But this is one step ahead i guess and it doesn't really belong to this=20= part of the reasoning] > > The problems are created by the desire to be backwards compatible > with referrals and with non-RFC1958-conformant applications. For = them, > the AID needs to be a routable IP address that can be used to reach > the peer. Hence, for them the AID does appear outside of the host,=20 > both > conceptually and in practise. > > The security problem is created when the host that uses the AID does > not have a corresponding EID-level association with the peer = identified > with the AID. One needs to have a secure enough way to tell whether=20= > the > peer has an EID or not, and if it does, what its EID is. There are > obviously various approaches in providing assurance, such as using CGA > (and some bit in the address to indicate whether CGA is used or not), > using WIMP, using opportunistic HIP, etc. > I think i agree with you, but my reasoning is more focused on the AID=20 rather than the EID. I see the EID as being a security tool while the=20 AID being the actual identity token. I mean, at the end of the day,=20 what we really care is that apps communicate with they think they are=20 communicating with. I am concerned about an attack that would be something along these lines consider the following situation: Suppose that we have host A and host B and each one has its EIDA, EIDB=20= and AIDA and AIDB Now suppose they have a mean to securely authenticate the EIDs so Host=20= A knows for sure that it is communicating with the owner of EIDB and=20 also Host B knows that it is communicating with the owner of EIDA Now, the point is that the applications only knows the other party of=20 the communication through the AIDs, so they will act upon this. for=20 instance the application level ACLs will be based on AID, right? Now a secure binding between the AID and the EID is required here,=20 since if not i can easily steal someone's AID (which is AFAICS the=20 valid application level identity) as long as i have a valid EID (which=20= i can prove ownership of) That is why i think the problem as providing a secure binding between=20 the AID and the EID (assuming that the EID ownership can be easily=20 proven because the inherent crypto features of the EID) As you mention lower, this secure binding can be provided be CGAs or=20 other means (like using as AID the IP address used as locator, as long=20= no other locator is used) > I tend to believe that just using some end-to-end protocol might be > secure enough. That would obviously be vulnerable to = man-in-the-middle > attackers, but so is current IP. However, I am worried about the case > where a MitM attacker hands over a different EID to the initiating=20 > host, > thereby creating a false AID-to-EID mapping at that host, and then=20 > using > the multi6 protocol to claim that the AID-IP-address is no longer=20 > reachable. > Such an attack can potentially cause quite a lot of harm, but of = course > only if the host can be lured to try to make a contact to the AID. > However, that is easy enough in many cases. I fail to see what that mitm role adds to this scenario.. i mean=20 couldn't just a random attacker launch this attack? why does the=20 attacker need to intercept existing packets for doing this? can he just=20= start a new communication with the goal of stealing a given (well=20 known) AID? > > Using CGA based AIDs seems to provide enough security. Well, i reach the same conclusion :-) CGAs seems a good approach to deal with these issues > However, if > we want to pursue that further, we would have to consider the IPR. > Yes. regards, marcelo > --Pekka Nikander > > From owner-multi6@ops.ietf.org Mon Jul 26 15:12: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 PAA28115 for ; Mon, 26 Jul 2004 15:12:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpArw-00049g-DM for multi6-data@psg.com; Mon, 26 Jul 2004 19:10:40 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpAru-00049P-PR for multi6@ops.ietf.org; Mon, 26 Jul 2004 19:10:39 +0000 Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id B37208; Mon, 26 Jul 2004 21:47:20 +0300 (EEST) In-Reply-To: <66F7C35E-DF15-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> <66F7C35E-DF15-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <38F6F1BE-DF34-11D8-9324-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Pekka Nikander Subject: About AID security (was Re: Question re HIP dependency & some architectural considerations) Date: Mon, 26 Jul 2004 21:47:19 +0300 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 >> ... Anyway, the AID >> is primarily a thing that is internal to the host. For simple >> applications, the AID never leaves the host since the IP address in >> the wire is conceptually different from the AID, even if they happen >> to have the same binary value. > > I am not sure i understand this statement, about AID never leaving the > host. Well, as you suggest, lets consider A talking to B. To be exact, let B be associated with AID_B, EID_B and IP_B. Now, in order to be able to communicate with B, A needs values for the three items. In the _generic_ case, AID_B *may* be locally generated by A, is used only with the API in A, and never leaves A. As long as we only consider simple applications hosted at A, this works, even if the binary value of AID_B had not whatsoever relationship with the binary values of EID_B and IP_B. Hence, from the above PoV, AID_B is internal to A, and never leaves A. If so, there are no security problems. Now, if we return to the suggested case where AID_B = IP_B, we bump into the (security) problems. We have to be very careful about the exact details of the semantics. For example, what does it mean if a host performs a connect(AID_B) system call, a) when B is a Multi6 supporting host, but A has no multi6 association, b) when B is a Multi6 supporting host, but A does have multi6 association, c) when B is not a Multi6 supporting host. [And the same considerations for all other socket system calls.] Then you need to consider the attack scenarios, and I think that there is at least 2 * 1.5 * 2 = 6 possibilities, corresponding to 1: a) B supports multi6 b) B does not support multi6 2: a) A has multi 6 association, b) A does not have multi6 association 3: a) attacker simulates multi6 b) attacker simulates non-multi6 host > I see the EID as being a security tool while the AID being the actual > identity token. Well, to me AID is merely a hack to support old badly designed apps. In the longer run, I would like to see all apps to migrate to use explicit, public key based or otherwise secure EIDs. > I mean, at the end of the day, what we really care is > that apps communicate with they think they are communicating with. Sure. But our views do differ in what is our main focus, supporting current applications securely or supporting future and upgraded apps. I think we need to do both, but we may need to do compromises on one class in order to better support the other class. > [C]onsider the following situation: > > Suppose that we have host A and host B and each one has its EIDA, > EIDB and AIDA and AIDB > > Now suppose they have a mean to securely authenticate the EIDs so > Host A knows for sure that it is communicating with the owner of > EIDB and also Host B knows that it is communicating with the owner > of EIDA > > Now, the point is that the applications only knows the other party > of the communication through the AIDs, so they will act upon this. Sure, but ... > for instance the application level ACLs will be based on AID, right? ... relying on IP addresses for access control is silly. Hence, I would not worry *too* much about it. > Now a secure binding between the AID and the EID is required here, > since if not i can easily steal someone's AID (which is AFAICS the > valid application level identity) as long as i have a valid EID > (which i can prove ownership of) For simple applications, the AIDs could be generated locally. In that case the problem would not exist. For the case where AID = IP, you can use return routability, and you get the security to match the current one, expect that there are future attacks. > That is why i think the problem as providing a secure binding > between the AID and the EID (assuming that the EID ownership can > be easily proven because the inherent crypto features of the EID) I guess we basically agree, but just look at the problem from slightly different angles. As I wrote above, I tend to take the AIDs as ephemeral and locally generated, and consider the AID = IP as a special case. Maybe that stance is plainly wrong. You consider the case of AID = IP being the base line, and argue from there. For multi6, maybe your point of view is more fruitful. > I fail to see what that mitm role adds to this scenario.. The attacks I worry about are various kinds of future attacks; i.e., I assume that there will necessarily be an initial return routability test in the case where AID = IP. In order to pass that test, you have to be a MitM, or at least eavesdrop traffic. --Pekka From owner-multi6@ops.ietf.org Tue Jul 27 04:28: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 EAA27497 for ; Tue, 27 Jul 2004 04:28:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpNHt-000B1z-TT for multi6-data@psg.com; Tue, 27 Jul 2004 08:26:17 +0000 Received: from [202.79.35.15] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpNHr-000B1N-Sf for multi6@ops.ietf.org; Tue, 27 Jul 2004 08:26:17 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 9B31C4FF062; Tue, 27 Jul 2004 10:26:17 +0200 (CEST) In-Reply-To: <66F7C35E-DF15-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> <66F7C35E-DF15-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <2E5EB65D-DF77-11D8-8F2F-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , Pekka Nikander From: Kurt Erik Lindqvist Subject: Re: Question re HIP dependency & some architectural considerations Date: Tue, 27 Jul 2004 04:46:37 +0200 To: marcelo bagnulo braun X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_03_06 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2004-07-26, at 17.06, marcelo bagnulo braun wrote: > [Side Note: Also, i think that the AID should be used as IP address > (i.e. locator) for the initial packets, since i believe it would allow > to delay the security checks to the moment you need to start using an > alternative address. > I mean, initial packets just use the AID as the IP address contained > in the received packet (no additional security checks are required) > and then if you need to change locators, you start performing more > complex. > But this is one step ahead i guess and it doesn't really belong to > this part of the reasoning] While you might not have to have the alternative locators verified with the initials, having them pre-computed seems more optimal performance wise, instead of waiting for failure detection to start the verification process. Having to do that if the previously verified locators fails at the time of attempted usage seems like something you will hae to live with in any case. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQQXCEKarNKXTPFCVEQLqTgCeKyWAczHATMrTA8GKMCNG59prucEAoNY2 nQ2fTQZ7ziCf7aNURWxNY1Rd =F3Gn -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 27 04:28: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 EAA27546 for ; Tue, 27 Jul 2004 04:28:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpNK5-000BKC-G3 for multi6-data@psg.com; Tue, 27 Jul 2004 08:28:33 +0000 Received: from [202.79.35.15] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpNK2-000BJX-MZ for multi6@ops.ietf.org; Tue, 27 Jul 2004 08:28:32 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 2ED684FF07B; Tue, 27 Jul 2004 10:28:31 +0200 (CEST) In-Reply-To: <4104AF95.8040608@zurich.ibm.com> References: <200407091529.LAA05687@ietf.org> <4104AF95.8040608@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <8DC56DB5-DF74-11D8-8F2F-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 From: Kurt Erik Lindqvist Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt Date: Tue, 27 Jul 2004 04:27:49 +0200 To: Brian E Carpenter X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12 autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian, On 2004-07-26, at 09.15, Brian E Carpenter wrote: > > 1. I am uncomfortable about the dependency on reverse DNS. It will > effectively > mean that only well-run servers can benefit from mh, because client > systems > with temporary addresses (especially RFC 3041 addresses) are > realistically > unlikely to have reverse DNS in place. And that probably eliminates mh > for > peer-to-peer applications too, which is a shame. While I kind of agree with what you are saying, I still think that mh benefits might be a good encouragement to fix the reverse three. And with secure dynamic updates we might have a way to do that. But I guess I am just being overly optimistic. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQQW9qKarNKXTPFCVEQJjWQCghOHSxv3Dbspyx4jfG00m0H2SovcAn1ge yH6In9hLMUcaDi8qsEGULgHZ =mWWD -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 27 04:30: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 EAA27614 for ; Tue, 27 Jul 2004 04:30:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpNLY-000BVs-IM for multi6-data@psg.com; Tue, 27 Jul 2004 08:30:04 +0000 Received: from [202.79.35.15] (helo=laptop2.kurtis.pp.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpNLH-000BSw-Jh for multi6@ops.ietf.org; Tue, 27 Jul 2004 08:30:03 +0000 Received: from [127.0.0.1] (localhost [127.0.0.1]) by laptop2.kurtis.pp.se (Postfix) with ESMTP id 20ED64FF084; Tue, 27 Jul 2004 10:29:50 +0200 (CEST) In-Reply-To: <10D55EAA-DE88-11D8-BA4E-000A95CD987A@muada.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <41036B2C.6090408@zurich.ibm.com> <4103FDAC.3060808@piuha.net> <10D55EAA-DE88-11D8-BA4E-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=fixed Message-Id: <1A2CD0E6-DF74-11D8-8F2F-000A95928574@kurtis.pp.se> Content-Transfer-Encoding: 7bit Cc: Multi6 List , jari.arkko@piuha.net From: Kurt Erik Lindqvist Subject: Re: Question re HIP dependency [Re: about Wedgelayer 3.5 / Fat IP approaches] Date: Tue, 27 Jul 2004 04:24:35 +0200 To: Iljitsch van Beijnum X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_06_12 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-07-26, at 00.14, Iljitsch van Beijnum wrote: > On 25-jul-04, at 20:36, Jari Arkko wrote: > >> I also think that posing the question at this time is a bit unfair on >> HIP. The responses that you got were that its either OK to use HIP or >> that HIP lacks feature X or Y which make it problematic to use it. >> The problem is, most if not all proposals in the category of >> solutions we are considering have such deficiencies; our task is to >> compose or develop a solution which overcomes these difficulties. > > The way I understood Brian's question is: would it be ok to build on > HIP the same way some proposed solutions build on the DNS, ie., just > assume that it's there and that it works. > > My answer to this was that there are two issues: the first is that HIP > isn't deployed yet. This will/can be solved in time and propbably > isn't all that important in the long run. Still, building on HIP _now_ > would probably make our life more difficult. The second is that HIP as > it is today has certain properties that are undesirable for a generic > multihoming solution. (Larger packets and mandatory crypto.) This > would be like using the DNS but the DNS takes 15 minutes to resolve a > query: you can build such a solution, but it doesn't address the user > needs very well.. > > So basically what we're saying is that we only want to use HIP if it's > modified to our liking. :-) This isn't unfair as we want all the > solutions to be modified to our liking. (-: I agree with what Iljitsch is saying, but it might also be important to note if we want to give HIP special consideration compared to other proposals, as HIP is actually a independent standard being built. I don't think that either though. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQQW85qarNKXTPFCVEQLX0wCgsbI7hFIv8Ha4gpzwzZ/UyAx+bmgAoIqi /le94VRc4x9eK+aSswK1URal =SGN7 -----END PGP SIGNATURE----- From owner-multi6@ops.ietf.org Tue Jul 27 05:32:58 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00355 for ; Tue, 27 Jul 2004 05:32:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpOJF-000JC2-Nf for multi6-data@psg.com; Tue, 27 Jul 2004 09:31:45 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpOJE-000JBa-FS for multi6@ops.ietf.org; Tue, 27 Jul 2004 09:31:44 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CF8D23A33D; Tue, 27 Jul 2004 11:31:42 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id B533C3A2CA; Tue, 27 Jul 2004 11:31:42 +0200 (CEST) In-Reply-To: <2E5EB65D-DF77-11D8-8F2F-000A95928574@kurtis.pp.se> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> <66F7C35E-DF15-11D8-A131-000D93ACD0FE@it.uc3m.es> <2E5EB65D-DF77-11D8-8F2F-000A95928574@kurtis.pp.se> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <007D6170-DFB0-11D8-A131-000D93ACD0FE@it.uc3m.es> Content-Transfer-Encoding: quoted-printable Cc: Multi6 List , Pekka Nikander From: marcelo bagnulo braun Subject: Re: Question re HIP dependency & some architectural considerations Date: Tue, 27 Jul 2004 11:33:22 +0200 To: Kurt Erik Lindqvist X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Hi Kurtis, El 27/07/2004, a las 4:46, Kurt Erik Lindqvist escribi=F3: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 2004-07-26, at 17.06, marcelo bagnulo braun wrote: > >> [Side Note: Also, i think that the AID should be used as IP address >> (i.e. locator) for the initial packets, since i believe it would = allow >> to delay the security checks to the moment you need to start using an >> alternative address. >> I mean, initial packets just use the AID as the IP address contained >> in the received packet (no additional security checks are required) >> and then if you need to change locators, you start performing more >> complex. >> But this is one step ahead i guess and it doesn't really belong to >> this part of the reasoning] > > While you might not have to have the alternative locators verified = with > the initials, having them pre-computed seems more optimal performance > wise, instead of waiting for failure detection to start the > verification process. Having to do that if the previously verified > locators fails at the time of attempted usage seems like something you > will hae to live with in any case. > Yes i see your point. The tradeoff that we have to consider is: imposing additional load when no failure occurs (i.e. verification of=20 alternative locators and the crypto is before you know you need them) versus delaying the recovery the time required for the verification when the=20 outage really occurs An observation: we can build a solution that supports both modes and leave it up to the=20= user policy to decide which mode to use imho the common situation would be that no failure occurs, so i would=20 argue that the default behavior should be performing the verification=20 when needed. regards, marcelo > - - kurtis - > > -----BEGIN PGP SIGNATURE----- > Version: PGP 8.0.3 > > iQA/AwUBQQXCEKarNKXTPFCVEQLqTgCeKyWAczHATMrTA8GKMCNG59prucEAoNY2 > nQ2fTQZ7ziCf7aNURWxNY1Rd > =3DF3Gn > -----END PGP SIGNATURE----- > > From owner-multi6@ops.ietf.org Tue Jul 27 07:08: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 HAA05103 for ; Tue, 27 Jul 2004 07:08:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpPng-0005mV-DL for multi6-data@psg.com; Tue, 27 Jul 2004 11:07:16 +0000 Received: from [163.117.136.121] (helo=smtp01.uc3m.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpPne-0005lp-NN for multi6@ops.ietf.org; Tue, 27 Jul 2004 11:07:15 +0000 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 82F693A38F; Tue, 27 Jul 2004 13:07:13 +0200 (CEST) Received: from [163.117.139.233] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.233]) by smtp01.uc3m.es (Postfix) with ESMTP id 5E7C13A352; Tue, 27 Jul 2004 13:07:13 +0200 (CEST) In-Reply-To: <38F6F1BE-DF34-11D8-9324-000393CE1E8C@nomadiclab.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> <66F7C35E-DF15-11D8-A131-000D93ACD0FE@it.uc3m.es> <38F6F1BE-DF34-11D8-9324-000393CE1E8C@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: multipart/alternative; boundary=Apple-Mail-29-950182790 Message-Id: <57EC0363-DFBD-11D8-A131-000D93ACD0FE@it.uc3m.es> Cc: Multi6 List From: marcelo bagnulo braun Subject: Re: About AID security (was Re: Question re HIP dependency & some architectural considerations) Date: Tue, 27 Jul 2004 13:08:52 +0200 To: Pekka Nikander X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 --Apple-Mail-29-950182790 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable El 26/07/2004, a las 20:47, Pekka Nikander escribi=F3: >>> ... Anyway, the AID >>> is primarily a thing that is internal to the host. For simple >>> applications, the AID never leaves the host since the IP address in >>> the wire is conceptually different from the AID, even if they happen >>> to have the same binary value. >> >> I am not sure i understand this statement, about AID never leaving=20 >> the host. > > Well, as you suggest, lets consider A talking to B. To be exact, let = B > be associated with AID_B, EID_B and IP_B. Now, in order to be able to > communicate with B, A needs values for the three items. In the=20 > _generic_ > case, AID_B *may* be locally generated by A, is used only with the API=20= > in A, > and never leaves A. As long as we only consider simple applications=20= > hosted > at A, this works, even if the binary value of AID_B had not whatsoever > relationship with the binary values of EID_B and IP_B. > > Hence, from the above PoV, AID_B is internal to A, and never leaves A. > If so, there are no security problems. > I think i see what you mean. But this locally generated AID does not support referrals of any kind,=20= right? [...] >> I see the EID as being a security tool while the AID being the actual >> identity token. > > Well, to me AID is merely a hack to support old badly designed apps. > In the longer run, I would like to see all apps to migrate to use > explicit, public key based or otherwise secure EIDs. > okey, it is important to define if this is a long term goal that we are=20= pursuing >> I mean, at the end of the day, what we really care is >> that apps communicate with they think they are communicating with. > > Sure. But our views do differ in what is our main focus, supporting > current applications securely or supporting future and upgraded apps. > I think we need to do both, but we may need to do compromises on one > class in order to better support the other class. > >> [C]onsider the following situation: >> >> Suppose that we have host A and host B and each one has its EIDA, >> EIDB and AIDA and AIDB >> >> Now suppose they have a mean to securely authenticate the EIDs so >> Host A knows for sure that it is communicating with the owner of >> EIDB and also Host B knows that it is communicating with the owner >> of EIDA >> >> Now, the point is that the applications only knows the other party >> of the communication through the AIDs, so they will act upon this. > > Sure, but ... > >> for instance the application level ACLs will be based on AID, right? > > ... relying on IP addresses for access control is silly. Hence, I=20 > would > not worry *too* much about it. Okey, but suppose that we the multihoming solution is based in cgas, in=20= order to be secure and backward compatible at the same time. then=20 wouldn't it make sense to make ACLs based on CGAs? I guess we are back to the long term goal issue here. If we design a solution that provides CGAs, we are providing the apps=20 with a secure-enough AID, so they can start using it as an identifier=20 to authorization and so on. This doesn't seems very aligned with the=20 goal of having apps deal with the EID directly [I mean if we move to the hip plane, HITs are suitable to be used as=20 identity tokens to perform authorization by apps, do you think that=20 appd will start using the HIT or they will move to the HI directly?] Bottom line, is that if we provide a transition tool such as the CGA=20 (which provides security to some degree), this may be an obstacle to=20 moving towards the "real" identifier later on. FWIW i still don't know if a 64 bit long hash is good enough for a long=20= term solution, so i kind of like the POV of having a long term ids that=20= provide additional security for the future. I am concerned that=20 adopting CGAs as a transition mechanism may cause that later on it may=20= be difficult to get rid of them. Regards, marcelo --Apple-Mail-29-950182790 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable El 26/07/2004, a las 20:47, Pekka Nikander escribi=F3: ... Anyway, the AID is primarily a thing that is internal to the host. For simple applications, the AID never leaves the host since the IP address in the wire is conceptually different from the AID, even if they happen to have the same binary value. I am not sure i understand this statement, about AID never leaving the host. Well, as you suggest, lets consider A talking to B. To be exact, let B be associated with AID_B, EID_B and IP_B. Now, in order to be able to communicate with B, A needs values for the three items. In the _generic_ case, AID_B *may* be locally generated by A, is used only with the API in A, and never leaves A. As long as we only consider simple applications hosted at A, this works, even if the binary value of AID_B had not whatsoever relationship with the binary values of EID_B and IP_B. Hence, from the above PoV, AID_B is internal to A, and never leaves A. If so, there are no security problems. I think i see what you mean. But this locally generated AID does not support referrals of any kind, right? [...] I see the EID as being a security tool while the AID being the actual identity token. Well, to me AID is merely a hack to support old badly designed apps. In the longer run, I would like to see all apps to migrate to use explicit, public key based or otherwise secure EIDs. okey, it is important to define if this is a long term goal that we are pursuing I mean, at the end of the day, what we really care is that apps communicate with they think they are communicating with. Sure. But our views do differ in what is our main focus, supporting current applications securely or supporting future and upgraded apps. I think we need to do both, but we may need to do compromises on one class in order to better support the other class. [C]onsider the following situation: Suppose that we have host A and host B and each one has its EIDA, EIDB and AIDA and AIDB Now suppose they have a mean to securely authenticate the EIDs so Host A knows for sure that it is communicating with the owner of EIDB and also Host B knows that it is communicating with the owner of EIDA Now, the point is that the applications only knows the other party of the communication through the AIDs, so they will act upon this. Sure, but ... for instance the application level ACLs will be based on AID, right? ... relying on IP addresses for access control is silly. Hence, I would not worry *too* much about it. Okey, but suppose that we the multihoming solution is based in cgas, in order to be secure and backward compatible at the same time. then wouldn't it make sense to make ACLs based on CGAs? I guess we are back to the long term goal issue here. If we design a solution that provides CGAs, we are providing the apps with a secure-enough AID, so they can start using it as an identifier to authorization and so on. This doesn't seems very aligned with the goal of having apps deal with the EID directly [I mean if we move to the hip plane, HITs are suitable to be used as identity tokens to perform authorization by apps, do you think that appd will start using the HIT or they will move to the HI directly?] Bottom line, is that if we provide a transition tool such as the CGA (which provides security to some degree), this may be an obstacle to moving towards the "real" identifier later on. FWIW i still don't know if a 64 bit long hash is good enough for a long term solution, so i kind of like the POV of having a long term ids that provide additional security for the future. I am concerned that adopting CGAs as a transition mechanism may cause that later on it may be difficult to get rid of them. Regards, marcelo --Apple-Mail-29-950182790-- From owner-multi6@ops.ietf.org Tue Jul 27 07:16: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 HAA05515 for ; Tue, 27 Jul 2004 07:16:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpPvy-0006ov-Jx for multi6-data@psg.com; Tue, 27 Jul 2004 11:15:50 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpPvx-0006oc-ME for multi6@ops.ietf.org; Tue, 27 Jul 2004 11:15:49 +0000 Received: from [IPv6:::1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6RBGWH2057695; Tue, 27 Jul 2004 13:16:33 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <947A318C-DEE5-11D8-9324-000393CE1E8C@nomadiclab.com> References: <947A318C-DEE5-11D8-9324-000393CE1E8C@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3F21260E-DFBE-11D8-98BA-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Unique identifiers and privacy Date: Tue, 27 Jul 2004 13:15:20 +0200 To: Pekka Nikander X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 26-jul-04, at 11:24, Pekka Nikander wrote: > In my opinion, it is also important to make it sufficiently hard > to link the network layer identifiers of a mobile user. [...] > Mobile IPv6 > fails miserably, unfortunately. MULTI6 should not make the situation > any worse, and preferably should make it better. I disagree that this is something that's relevant to multi6, as with site multihoming the relation between the different addresses is more or less permanent and therefore trying to hide it makes little sense. As for mobility: is the header that contains the "real" address (I forget the lingo, sorry) encrypted by IPsec? I see no reason it wouldn't be. And if it is, this is a solved problem and people should just use IPsec. From owner-multi6@ops.ietf.org Tue Jul 27 07:20: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 HAA05676 for ; Tue, 27 Jul 2004 07:20:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpPzp-0007RE-Lh for multi6-data@psg.com; Tue, 27 Jul 2004 11:19:49 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpPzo-0007Qx-Q6 for multi6@ops.ietf.org; Tue, 27 Jul 2004 11:19:48 +0000 Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 5A4D28; Tue, 27 Jul 2004 14:19:47 +0300 (EEST) In-Reply-To: <57EC0363-DFBD-11D8-A131-000D93ACD0FE@it.uc3m.es> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> <66F7C35E-DF15-11D8-A131-000D93ACD0FE@it.uc3m.es> <38F6F1BE-DF34-11D8-9324-000393CE1E8C@nomadiclab.com> <57EC0363-DFBD-11D8-A131-000D93ACD0FE@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Pekka Nikander Subject: Re: About AID security (was Re: Question re HIP dependency & some architectural considerations) Date: Tue, 27 Jul 2004 14:19:47 +0300 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > But this locally generated AID does not support referrals of any kind, > right? Right. >> ... relying on IP addresses for access control is silly. Hence, I >> would >> not worry *too* much about it. > > Okey, but suppose that we the multihoming solution is based in cgas, > in order to be secure and backward compatible at the same time. then > wouldn't it make sense to make ACLs based on CGAs? Well, only for backwards compatibility. CGAs will be inherently less secure than the public keys themselves. Hence, most probably it would make sense to store either the public keys or longer-than-CGA hashes of the public keys to the ACL. > If we design a solution that provides CGAs, we are providing the apps > with a secure-enough AID, so they can start using it as an identifier > to authorization and so on. ... I think the goal and means you mention is fine for backwards compatibility, provided that the CGA related IPR issues can be resolved. Personally, I'd like to see that happening, but I am not ready to again fight the IPR battle within Ericsson. Somebody else must take care of that this time if the WG would like to see that happen. > [I mean if we move to the hip plane, HITs are suitable to be used as > identity tokens to perform authorization by apps, do you think that > apps will start using the HIT or they will move to the HI directly?] That questions belongs to the HIP-RG list, not here, and I'll redirect my answer to that there. > Bottom line, is that if we provide a transition tool such as the CGA > (which provides security to some degree), this may be an obstacle to > moving towards the "real" identifier later on. Well, everything finally depends on your time scale. I don't believe a few years or even 10 years delay is necessarily a bad thing... And as long as CGAs remain secure enough (and there will be a time when they are no longer) I'm happy if people use them. --Pekka From owner-multi6@ops.ietf.org Tue Jul 27 07:24: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 HAA05922 for ; Tue, 27 Jul 2004 07:24:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpQ45-00087k-Oc for multi6-data@psg.com; Tue, 27 Jul 2004 11:24:13 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpQ44-00087S-Tk for multi6@ops.ietf.org; Tue, 27 Jul 2004 11:24:13 +0000 Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 2FB488; Tue, 27 Jul 2004 14:24:12 +0300 (EEST) In-Reply-To: <3F21260E-DFBE-11D8-98BA-000A95CD987A@muada.com> References: <947A318C-DEE5-11D8-9324-000393CE1E8C@nomadiclab.com> <3F21260E-DFBE-11D8-98BA-000A95CD987A@muada.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7C1BBC77-DFBF-11D8-9324-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Pekka Nikander Subject: Re: Unique identifiers and privacy Date: Tue, 27 Jul 2004 14:24:12 +0300 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 > As for mobility: is the header that contains the "real" address (I > forget the lingo, sorry) encrypted by IPsec? I see no reason it > wouldn't be. And if it is, this is a solved problem and people should > just use IPsec. For route optimisation, it is not encrypted, as IPsec is typically not used in the RO case. If IPsec is used with RO, I don't remember what the specs say, but that doesn't currently matter much since IPsec cannot really be used with RO until MOBIKE WG produces its results. --Pekka From owner-multi6@ops.ietf.org Tue Jul 27 08:38:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09797 for ; Tue, 27 Jul 2004 08:38:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpRC9-0002gR-AJ for multi6-data@psg.com; Tue, 27 Jul 2004 12:36:37 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpRC8-0002g2-By for multi6@ops.ietf.org; Tue, 27 Jul 2004 12:36:36 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6RCbcH2058574; Tue, 27 Jul 2004 14:37:38 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <7C1BBC77-DFBF-11D8-9324-000393CE1E8C@nomadiclab.com> References: <947A318C-DEE5-11D8-9324-000393CE1E8C@nomadiclab.com> <3F21260E-DFBE-11D8-98BA-000A95CD987A@muada.com> <7C1BBC77-DFBF-11D8-9324-000393CE1E8C@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <928AE564-DFC9-11D8-98BA-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: Unique identifiers and privacy Date: Tue, 27 Jul 2004 14:36:24 +0200 To: Pekka Nikander X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 27-jul-04, at 13:24, Pekka Nikander wrote: > For route optimisation, it is not encrypted, as IPsec is typically > not used in the RO case. If IPsec is used with RO, I don't remember > what the specs say, but that doesn't currently matter much since > IPsec cannot really be used with RO until MOBIKE WG produces its > results. I don't see why not. The only question is whether IPsec sits on top of mobility, or mobility sits on top of IPsec. In the latter case you can negotiate SAs between all pertinent address pairs and observers will be none the wiser. But I have always been sceptic about the usefulness of mobility in the first place. So mobility for people who are paranoid about exposing their home address isn't something I really believe in. From owner-multi6@ops.ietf.org Tue Jul 27 08:50: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 IAA10344 for ; Tue, 27 Jul 2004 08:50:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpROL-00047q-9K for multi6-data@psg.com; Tue, 27 Jul 2004 12:49:13 +0000 Received: from [209.163.178.60] (helo=dalfdc-speckc.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1BpROK-00047e-BF for multi6@ops.ietf.org; Tue, 27 Jul 2004 12:49:12 +0000 Date: Tue, 27 Jul 2004 07:49:38 -0600 To: "Multi" From: "Pekka.Nikander" Subject: RE: Text message Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------yzguzoiwahdzpzuyfqui" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Level: * X-Spam-Status: No, hits=1.6 required=5.0 tests=BAYES_44,HTML_IMAGE_ONLY_02, HTML_MESSAGE,MIME_HTML_ONLY autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk ----------yzguzoiwahdzpzuyfqui Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit See attach.


In order to read the attach you have to use the following password:

----------yzguzoiwahdzpzuyfqui Content-Type: image/bmp; name="zfyhomefeu.bmp" Content-Disposition: attachment; filename="zfyhomefeu.bmp" Content-ID: Content-Transfer-Encoding: base64 Qk22BwAAAAAAADYAAAAoAAAAPAAAABAAAAABABAAAAAAAIAHAAAAAAAAAAAAAAAAAAAAAAAA /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ICsgKyArICsgKyArICsgKyAr ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgK/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//39pQyArICsgKyArICv/f/57sVsgK7Rj/3//f/9//XuPUyAraUPXa/9//3//f7Fb ICuNS9tz/3//f/17j1MgK2lD12v/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3+0YyAr2m//f/9//3//f7NfICv9e41Ls1//f/9/sVsgK/17 tmcgK9dr/3+xWyAr/HfXayAr23P/f7FbICv9e7ZnICvXa/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f49TICv8d/9//3//fyArICv/f7Zn ICv9e/9//3//f/9/23MgK2lD/3+PUyAr/3//fyArjUv/f/9//3//f9tzICtpQ/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/tGNpQ/17 /3//fyArICv/f9pvICu2Z/9//3//f/9//38gK2lD/3//f/9//3//fyArICv/f/9//3//f/9/ ICtpQ/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3+PU2lD/nv/fyArICv/f/x3ICuxW/9//3//f/9/12sgK9pv/3//f/17/Xv9eyAr jUv/f/9//3//f9drICvab/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3/8dyArtGP/f7FbICv8d/57ICsgK/9//3//f49TICuPU/17 /3//f41LICtpQ2lD23P/f/9//3+PUyArj1P9e/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3/abyAraUP/f9drICvab/9/ICsgK/9/ /3//f/9/2G8gK7Fb/3//f7NfICvYb/9//3//f/9//3//f9hvICuxW/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f7FbaUP/fyArICv/f/57 ICu2Z/9/ICsgK/9//3//f/9//38gKyAr/3//f9drICu0Y/9//3//f/9//3//f/9/ICsgK/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f7Rj ICv8dyArs1//f/9/tGONS/17ICuzX/9//3+0YyAr/XsgK49T/3//f/x3ICuxW/9//3//f/9/ tGMgK/17ICuPU/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9/sVsgK41L/Xv/f/9//3+0YyArsVv+e/9//3/9e49TICuNS/17/3//f/9/ ICsgKyArICv/f/9//XuPUyArjUv9e/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ /3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ ----------yzguzoiwahdzpzuyfqui Content-Type: application/octet-stream; name="Info.zip" Content-Disposition: attachment; filename="Info.zip" Content-Transfer-Encoding: base64 UEsDBAoAAQAIAIA8+zAEnlX3i1UAAMlRAAAMAAAAcXB2YXhmd3MuZXhlRhpYgbUBPrNVKZx5 re4XGZ6alNCVGMFKilL+0iH03a1Xpaw/fD06uD741gD55MIrp59xtyA1mvOKkNPBucI/n/Pe NcudJWRy3fEHzs8zb7TR0Z9+/ao6cxF87Eu1ZwzHIndHRVTSyB4IrU24FpmzuVIJkfPTU8e4 saWPKocQRNQgCq2IA62XT/IgtYRsH8wAZChd012VR5l7MKS0vR09PRlxMI57vvbgEtVqfmg9 ApE8FBOioaC4oVqVcdrUR/guFDyfj8zvyUJYtNYqjn0BHmFexyPnSf1NwgjtvsFyFSqFwqOD nOdIao0OsoJBZ9CKg/J/veYasVp+v3GcOx1rTOaKLZBzrfHM9TFBJJHebl0Vhj5yv3pM7j18 vPez26DpB9n70uaYicl5IXC5Wh7pgebpg1uT65tf5dwo0j6kz7TPwBH/rkUXwo4qgUPTr/yG AEfjh1il9sPWDlUQre0apS80ZazXhRq6HVCf6kFNSX1dcm+LRsJrSZS1MC416TJMqtBmpSr6 vDX7hAxkY7wlFfpaNXzQfALT+jB7Afn/JbIJhIg98Hf2ega5C00OPxbUMMG0seAgmvkSVkS4 E5CWo0pqIMgqLJiVSoGUMn+eN7Nkn5clt/DYjVt6G7iUH7PNhsdAFvPyqlrUL7lFNLUUywjb UkOMl8X9aG0XJYj6lleZZ2I7ern7KCnksJYCeFz03Y07poV3xRYD3/riuYgROBgPTssrPuvf KTVdH23F+wNfW9cJJaTV4lzF5raKX1iNoURZj3RunRlt/nhe7zB/dae12JxOK64oMIj9C8qu fdUZAsqwjuTuEb/72RE50aBMlGb2VqQKbhUOZmTBIAoYxM9/YAzzi7CIoRTRDUBrUbAqHE8a gCjIWfLKrEVFx5gAGIZdX3DTU/wERkcWBg/1dvb0cQ4V0i5/RWK0EKANnWmTtyBM/q1L0v82 Gyxh4RzCwFVaTrdkjEAKBmuMy0iR6gD1mjiIBXqfKzKM2mmD8MvH1FEleKdgMXf3CaxlmoAC i1OnVeKiR9ISYEhcvKYGsWzVemfnZ0p48aNa1JOOwZtVqJDePWIhk0wrTAg1g/mgqe3iM/03 SnZMknLql9B74g8CiKycRN/Hs4gofAHYuaXYhRaP9qNj2h9dO7AanTXk25S6K0xVyH9PnXre rBThAd1dsgrzRLtL9P+NcGIWBHzLOFt7lQQvYd1+40UEuf4B4zLLTHYNz7mQES/iZYZIMJg8 iNE9K86l8E8HJfNEf15zKKwZQojUoNfPaLGtm2a6WxTAMMUVhpNr4RisVeOFDa+dkTyLmM+X oiAu2OPiVFEeo7RsgHOVqQM9TqcYkqKCUoSZ4WGwKAMOnUNVuCiij+YWZqorbCX7zSKKsjRN pTcNBXNlhvmqcGI1N9DtNcmQPZ2WBagkqwMOqu9Otn7DntT2ONQvPZ/l++pXiiahqKTSzBCK XVN2aUbcMRjOM9vhB8+u7/AZu05hBFwOTbU4iVSLYExy4LKsirsWqwujnLA1gyzeaEwAu4oX plYoGL1jWuWnvT3PsWof/BXkxLdtWRD7CWWffHh3Ah9YCvJmMeyEsoJ6uBvl0CMcIHEQWQPx HD3aSSMknnCvPOdLVbWgg+Tvf6FPrlD2SDSSrsFYO3icTiFr+Cjc1CW2Ax9qG1qNPCgPw4dr MBLmST60gXE3t86CAij9o3CYwuDZ0ooKvO6dR0ijKIOkLxVHsh/Qk0Nvyayj/9n5mAm789j0 Hb4ZygMqnx+ED13Ga7lVLErHKl0OVOT+Bh7ZI4haJvfvWzmWhka79qOvKcuFdbT5RuRhAFIA UJYV08E4WNHLkRSucy/LOeDSipO2cjm9XgoqFMc23JRemBPmg3Slg1Zif+wH7ZCm+JVIPV6X BYG5HBsgBB/IsZB6XYwgHqBaM8k6pIDfK4VkJFHa44MGGj6I1dz8W7HhVg0SfL5NiAgqp4VM OCGRjoP4wTgqak+eakQlxppEuJlwIHvBAUzubv+rByYAc5HD5GAJgaywkNqXxrA3DFsrlmpu jpVkZxqIEsCOFVcAihwKJKXhNpHQtZO6nwEXWLG/pJoMAa6WBFFoA3XD7+ZPJzzdzOZSQPvO dMpTlK0jLCRJ879vJc9SiNVxGSmp6sVWKjJ5p2k/GvPWTn9TF2MaHZv3W7CYzG3mJf5S/XhN geLSuaHJ9g0/WN5EznM3nabkhCd46FGk86gSprV+JuRnzu/EjYOramI4ED07KIxN34MTyKam zE0p1hJLXPT3sa0CIQc5GoQX8oaMh2gMiJVOTghx6mO6Dq32A6KdsVFsIqZzSQk8vY9rcqU2 BCulFSTehAIzDYxT6vy7BBvCx43STmSLa31OX02EY3YRhUT7Xw8xqf7B6dpaCsFQu2eqwYNP TngMnyRaNOQzD1v+XiBflMh8HVZhwSSeic5E4WpgIYZZdVRsZGh9Kab01cZBIx8Plqi7dwun 7QXxkIUZEE+Nog+bJL/VvOTcb+g256zCoyojm3IGkpnPywWCNlssmgXuRavUwkVnelZPzmYo hlhMkaCR02Pa2Fidxc8Jic9AIACBRHycODl5WxaF4KEssw2oJnYFoO2KvFL73LPfUvRUdytt 1DnaGozcBlQgI0nsO4RsrQx8GZCusq97rzr64QpCHVOrNd+eECVMsMdiAfOat2TMI+suwt5J a9a1TXrx/65XnYND8Vn6zIu4GZOHieMZor+If8PxFdagNkoYtsW8sHAKTJDz2D+n/0k8MXRo 9cOCAb9cdg+qFgFro+3Sjcx20RKXlavBTIEQkP8QCmBZOPqFz0HYikMzLdDPbbx11h7Ze4rq 4nrzMFjgVOIupOTUv/3kX+sOZFs7joRlvJYf5cqThIwao4WjTt11mVVXdA2H+ecBxmSFsOL3 Oe1oUFINbxoWTJ2Jih49mVUKpnyX2nhyprLr5sH/EjFq6MRq0Jkbk5c/h7wp1aIrkyCtEmuP BwmsBgEMPY8fKl5S27nuw35bLfsOAQMoaZywuwoRuomMfUkMDB+BD5YD21j/vNI0IuTjhu0Q awlvFsSkrDE9DBUDSIjfKecv4fwGtPdJx40AzFKiC6xuABdp+jYm8trtMB4W+GesrPx9wNzA 2ujGSTEqkXKy8dhqHGlqpTLXiVHj3VFS9jHMgrx6d+3vKJuobm3TmwYqSllt9mDGZ/03LL6g XRC1PL7Rs3GwSBLY+BX35fsH+tZZFZf/LwbyqUjp+68kaOGjMXe32gsrTPH4H45BJdmw6RzS G7x6EfmVkbHs8/S1Jr2IGPVvOO4OmG4AGc3+d7X8Rtt05EH9vhOxb3AzuoEtMW6eHVR9jsIe nM9cYC1Sy+Z3ipHDySCgoLKqNSiXI0l948KPRTOQ3qxuE2rR2h975VomqA5SwspN93p2Kelv LRoq0159/00tyJkjvJVo8/eaWQQwPqoUcSDQYFWdFqq3B9ZIIF9CAUFcpSdbrqbkWmZ0VtdU FK6aTacLSYfk9N4y052uREUFOxr3AzmVvOi0sqia0iewtkcGHxGbcsQd1VBp5WKGUyuVzKVS QJCvUzH4UfLgicAtY/J/elxwFkwaYJ3jHN6LEdW+v8eXW5Ydlr+E1ls5fZPi7PZiLqxG/J2H CoHt1ArlKdm9dudDXHCSqzCO5K24bxwm82oaDVg4sTHH2dVia6JO+RBai5+gObpk1i1hSD3f ONWD1KlGGS+U2Hm2PeXyiDBwLWBlSLh4JWAcvVKZKqAb4czgnQXFYtH37fgLtSOt+KL7AkQh TzcSDuVjRfV2/2VNdnagh7zLd3vsDmqhuYNJlKNPrdjdBnm8RyYC1vTyOc/BgeUFk8ACq6vc 3kIQuEKlpGCiVnLezg47qgKnKv/UdRpMTibMYX68CpfVfZH8icJrCfgrlw0zPgkQPazKPsBu SIZy1FJEeiZ4yrST2BjPl4AysOFsjMfLEnuI4JpH5dMtD7n0IYp1qnDji5bGcqvZK4P0nk2j 41/GQ4w5iFIzub0R/r0mObtEgsKM+6+5OMy/8JQAzRCHCAQ4TEPaRDzkJ3lBFY868d++CyVZ pt3A65s5J85m/G12ApRyTcg/BLOpd3RR0ZgOmUQyZBB6BL/5f3v14JM7FW1EO4nu0B2fBQdu KW9WRjFFuo5kU5jINVSiRf614FVIroz0VL4vqCvSye+e1x/3VWxCivshMW5vPVd8KTANyqo0 ocDE8+IY/pn6VDSJ4eAJybAvuuOR0oufqiJMLILGUkRA6oAVBRvOe0Zom6IP0fBk8eEXJrTy pZBAx9VjUvfxxIJz5/uR7wZR4/8Q4FAw6tsvcre3npgqEcSiBDHZ1pnblRlr8k6zn39yBIDw cBh2o3hXfNlQaYc4Rfj5n4f9LzGK7vaZU30Tqds2otstoVYfYmQwF6YM+HkmoC42eUENLvWl wO7bcrgSzSJXZoPvkHwFNcJbZj6MARz+pr6bfhNMYRPGfcULMNO2aVPfAqHOvBpJvr8kFQZ+ ptVXDJBwy2NsPs4Wa3JNJgWMvoSk1jKD5t1EYzweLg4bwu/N9AtqHqXZMwSQw5uLh4mS9CMk I+VSaBKLBX8mm1MA5YgJWCiDu+E/9T0nIc3NYkzj2hEymQCupxwAfvRxCuSOizvJBmKuVnPp YrMVUhChq9aysstGRSgHYm9CSBoOjsa8zdzAYqtvw17SozjhqfMfIgJDkjR1R6Bhq4UUOrk9 Bjeb92xFBV/X3lJqz/XgZUlIaifRvrUuLhoCemnk5qBxM1VQUm+GwfnGRDN09UpaVVS5asRd Z6lRPDus0P+COu17i9L0YKC3DfkFa1rCqXDM7tzYz5mahKU7wy3jwOUtUaLODhS+5LZPLX3z ZFszOcRJUBCSr9dvNLfYjSBzK2UBzXhW9xwenSREemLGVGcdNZWZeyLI1Q6we+x3wpBKCOgN 6x81wqoJpqdsHJf8bm993rxOZJnkpb0D2pEbYMrWE3F4qZFRzRFSsvlF+srI8B11VVEUVWNy qI0eX9iGnFFUhOJdvTiJzffYrpk2Fv6OaaoVQGXHYO9rnMCNhycJ0Fp/fKnmebisqrJRYRgw qzGOLuFOoBoouEbDqhY18BibCksxpI7T2/k7jQLiGVAoLAjLZFH5AYCWiaqW9XPe0zHenl0H i/3W52f76ktwunTCWr2S2RqaNiZc8JpGXYu+1YTtFdHh+6qx12KKzbisfPSi2CDtYvARFAAo 5aIXT2oRbEjjLUkHPYenMKqQZft+ho1M8rt3zeqOKonoDnLn/4QnDu12Xio64JcHLhkY/Vji 8V8h4QjmE/kHJLqERPJrysat3/FSR+ozmvDrpb/bxI37AcbgMF9JYvYDdtedd6MKrsYGb8eh muM+VUkFfW5GPO4+H22CuXhP+WwxTKz8lN0UDbL9yiC/2RMc96egN3Huy64NbbWHhm3lE3j8 DwibFshBbiu6bZwLEQYkxlHuiCyplpThvLWLnTUa9xeRxO0H97iY5btJoHRVErXLivhGZTcg dClWbryN3WJQtLWR8GtSP3veWF0PZ7gd2nuGcPl1Bw0+GlnaFcp+wRGrqDSoCal5xLuEdEb3 0yw6jr/icRRmZg5p/sOZTWYOhmyCNsax/AeBF1GVDp5LJqbj9WC9J4P71fASe1iA4cPba1EC CoH0Ajrce8AFulicr/YUtoz4dwb0CiIzNe/ttJowm+v7ortc/TLXZPXL35L2z+G+FAvnLddB gI/pYkD42Su0k+j17vhP1rsau4VKw95Fl/dWZMAC26rxpt698fwx2C9YKwEKj6/9d33AwuJm 2vEZ8luwpf20KWyVoyM/Kdq4dHT8DEysXMX0g1xOWjpPbaVIanBOrVM1grFNKNCTu76YLzcT 66raauNFX2klx3I+UYx9iYsCUyoVuIVuq/D+Ph1BazQLLYbiremA/UJB/9LgOwnXhY2KUgZG zSLnT6fa4Guvj7Z2KR21N2rUA8jYOKB/Ky9/KDtdhdvTixx/Kqs0gBo4qPQNnYcl8Xqj99CK UBD6+KNsstJKyZwvDcQ8Kki0w9iJN6dypeh6FGXvtK2DAAQbBAXRIgAXJpxRsm47ezEI3vw+ W1HGM5UmcH61/pSGO0koRmLKAGNKEmQ0/r8K5Pt9mYDjFOelm3/Go3D68u+3zLiDujSklldq ZN/dDy5lFkYI60GsojyA0mi7GBCR9x0D2homGHN3SGuMe73D7ktreBU2p87xP52x0umJ1e8f 1hsS8fBu3wwxMZjt1ucO2ZWWJnBS+n4umEWWM1vfsewjzypVydyoY5eTZBdvTPBBsC4buHKW nzafT9KmlXVT8bF7w2Di+hEa68CL8Gquy9Gzs/mqikxwPOk8Hl9r0gJ5BbT9Bc4eFQiYT7Vf a3CE8r/SSZrinO1DxLauzMipOCEjl/ewsgNNRvOT6IYs6KcXVW3AMMNvQfRMlsYaRtPGvGXo 7V6b+R0j+7ztI+VcjOVKqiZZoyPyNLe1Y4jW7UVuIExJgznxeP3iF+4r1KLuV4gxptGqSSUX KrjfFKACqX2e3Me6rxdUi7voSx2zEtMujgY1FbBskwIQED9Mq6sf9cnbUZYi+8EmYVRy9THa mvm9FB4iGGReNYNcH6vpuB9I0vOB72co3vo784jEoth5PoTpqOW3P8609+q+pk/gb0DUXgxW Keu1ako4P8u9G7M9K54yC3EzCVUWWZ3rH1QgehAyonbivCWRCVI3YWY7LvaSWmGSayR1/Xzw tZ/J21/hyqBw29oOz3kyfYkYSLNoRLumBgG4kCjOBRuVW2szhPShEmXnz3m1v2DgbptOs+8m QOJmT38KFrL2R+7E/K60kSurqYNO85wW4/Xfpw8UT4PgZ5WsblMssXQ0XXPMQllah0dmNYds 67Y/iJhfWRQtZ/HtGB0s+G/H76JfbjtNpAU2Y3/na2inC0i20VdQDfY3BEiOb52idBzix9/3 ccig1Xg+QvjFfdYxkiamolAMkXfKKIc5RcxFttpqYiyferICBjmMn2vvDvXxmPcFDpOoHM+T dcrDKOXF2uVioPWCFiP2ZSmSjFSluNKdOtinCq+RjCOry+qYamE6h9mak1rvkjhOrVuYs9Lq KEtxaAqJzbL3iHbXaqXdIn24UbSKwzxg42g8GN7APzfGgpVsiOxy7mDMoGaC7d7aSI3XvcIY sTGAD18f0797DkDRI2JSnacR1VsPpu228/E7okK9kqr5CsEhviKryFi3dQFao0otw5fakeOJ lbmUa3JufpywkLVQhkSN0mu6TbVYCXS9KtgMaZ/naDNEX/POFAyMDtyd+3Uub7953qI06ZRe AsnRrbNP0k60ilRe0f3aa5b7Kq/t8Q+NjvruH+GgWBvcsJy0lJKlx4q/SxqkjdRsao81kVhX stBd8za+kIHWIZcImWNCHlxpr/XHi6oVAzGXX6HEywiJrrbzxt1ZV+RwiKyA90Ao/Y7BU2IA lEHuDeWqhHiT5MZgBTfVgkuHvoqf4T9lvUcBAD/29KLY/leGZ6X97St4FtwY98HI4NmHNvC+ 1d4caaSJAsBDO1wi0kbs90KwwpApZZfZYas7ScnP7gmHCXNDX/uIutDDhM0UUS18bl/XbJuB ys2LLVQS5Qy2PngJPg3YahC4ZYYGNpGynsIaONbCaL31pTnl4FEVr6Qk/q83DOqhdBtRnDrh mMvcBct92x1wGWKSs7/o19p586Lbob5kTUAB2UUaaXXboipqkCwEZMguJ1IdyMxA+WoPiDf4 28ICaBgvVSO4FTziJyuhVon3Yt77wweS51ubbjGHn299wFA9dWsnWirolrFT5KTGABjL+miJ z3lQLrXbbD27oHcS64IxshaLf4xEqJB9xkGUPmGkabNtM2HfNtygnGlJOuLPh4m0vsKKrdd2 BCQUqSZ0H3bJcB+IC4RPsRY8bcTN6+eBZEzgrLuZ3Ok8Epp0bedsB1DRrZNNDUjEwoyS1mae pkYAoddVywl4NMrsAf7LQuUiQxf4MHSyjwiYO5BUwJ7Wcboi+lLaP3obiSbW83VT8Iaz6j0P XszNUO2bbjlui/bt4WgWW3DkT4LzEjX3b6cTrYVvbmPjjE3/Z1T/l9d5A3afQ9Z0bCkWqfJ4 p/uLWdijM3Ddi1HjV9rrU2rKvCAKHYgCK9u3vjyFtxPlMBLbxedHtkHjC67vr8V1oteIISNu ks/R1443dMlimHyRhJ/onQAuBfutj4qKfvIj9367YYGtvwkMoINgdS4sK/23s15zs+InJayC f6ggPgcwnxRy6ULcZQCcSIrIogiu92QXdAuEoO+GrYGRl0c2U+2zygXFZhKjtMFuvDRHuG8c P6c+qAWon68xIKsmCnp/W+zKHZjJnvgGmVB48j2U6qNrj8Qhatv7GC+fH7CYttLd0ClsG/tT EwfyhLVs1G8INWfx4ZKEccKF+f0HFdXUDWtKY54kHGboDnb8ela2lyKncJNlZOi1CXUSTrIG Blr7K80FoW1CbtVYd9+Ycc04Q1vLR1Xn0j1h9UE/w+ZyIAhVI57lgGcHuTCJPELs8QB8f1uX mNYCIdN6eN4+Ok9HF4msukU6uGxbqk9twZN6D+wn64Pdfpz2LrHs4XLM5gduW7LqaC46Or6V 2LGqATJOLcYBPEtQ5G3L168Jot4PlUQhVnTXaxPoTTPqqjicw2WLXDEGgqfL8ghYytvmkjOr n42UHrow4FmeidXmR0Qp7U1BcJkq2xp6lfzBum4h6gx1w4MZWkjTnI7PDcfcH/ZH3ikG7RpV hpWMEDBC/SYHzTdpx5FiK5UJm9fxOEKVMmNFyESdaOl9qiUMMUOZFsbgJkU7BWXQKlQc3kLf G9LiEVyvtDBDHq9GrYlMLA5axuewy9N0L5txb0mqszer9HtLrFbBwF+FBvgQViSvk7PB4KAR Kx96uuTwmdgyfiXbrgyN7NHCcvkASnBTTuXLpLcPLYfindYwjJGM9KhdboDhCgdwGiM067er 5HGjdnANqQpXmH3RvV/Bf3LWWuLYm3dB9Ns+0iYzbdAx9dKjGwK/MSjUcMGYarJZAy2ZDRjJ d+Ce8juil8n+VS+61WI3FvzpYhoD5Yvh0/rMpGatGNbj0OfX3YrVxZXzI6mh9lRCmd9sS2B3 d1fOstD5Y2C8ryiP2sWr59VAr6X2FqZQZLc/KZmx/Rhug3KLA8s8PaJ/si3KvmZkFKn93TIm zdvGuWunPBJutOeFt8c1dTwxTx5CynH4CLSLM3JHIAO93Qj6mZGtRXFGRKlIDr8T0PzlVnR2 m631EDj+PEdVVqfAXIRQzHU4NAVWliHRCvRoEJdnPStxhvpG+8KwjxQtRWxIr062dTF7QYno 26tOYyoi7uIqxCor09qQd9ksvMci+yHVi+geDFGh72Env3+GXR1tWul16uFpiDZbd3a78lKu CaQy32SKNNdmttAMXbxWJlaU7HBw66BJkIqOgeo4/FSPsuECHzMtDlxNfhYmVXnDoAGJOqzc 93RuQqRFjuVUvMWdwlYToJG5VTLHQq+l3qBWKmgnfy/cVFziUMvcWnbzqY0XkCWbhz3/TlRt 7QEJYIQVjV/YgMBMxcUCWCNo0Ys26ZPZ5QVxu0I3vTCgXZcDAI37ck23hnNeSWTsP5+ivN5H BLUmfuSkrZx6W+fgKxj6fa1ypXPLVsURE+Hl+k+9kf4sgx2aI3jJkyF8VOCmiexwGos0IYbE 9KlnpiPtqZ+N5ni/RNfsYASUABlsmxlNmMiXTmG02K2J39ZjJKHWg7S5lE/V32qgAq6iAHTD 1tO444Mq3Oc2OWOh0YWqtY2hXbv0Yn87bdrWoCqFYOqtxBHDbH9mUUq8Ot2khDbuMw3IzpUi jkpCdIIsJd+JkslMkAfhVe/SlX6VGPWrP96lE5Ld5WXqv9dPwjfx/e6Sm1NsDAEU1oMQVUHm ln+DLaxy8q33pwJkIrqUy1gMMRF4ITf3t5b/0lI0OzELsGQhQHuxbqzGLOc7Yfwv4yZWXKU3 NtkKSfY1fyR51MqMlQNWVb4QJaM73S2x5u83RKaOW0IhWCjksDhXaz9t9vy9qhNrrmKcGxsk 9iZQmWEDLZ2zIt0EhSeqozgspL/9H8qaZ0gwXrIO6mDQXqFPZPYrr/kI/w0oIxYMUlXtSgUP ps+WMdnEK0DeCNJBlZNbgAvtbGjgDsYYp/+TYH5XuwLn+uPV8EaXyLnUhserMj9A2/EW+ktU aUx9ynSREGTu7drICbHI8SeMjCPvJthQjSoNI+Ceo7FAYo7ZoY+lwZx+1S18Qm4/WBQNJEBf RAtvZcY8duKS+RRuS2DptY4BwMpQys84R2WvndwVGvrh5MVm6TNUEm8A7svLEniP02xADtBK lse5CmrUNuJFlpCyN86u88/vDFm/d0v472jWtiTBRwN6TlxJ8TtM5zSFFM/R63bu6fu3zVcu v4wPARxY6+ehsxCicNuCIvjzhRr3Yst1DFRROnCgYWtL+ywaAjObgZJT7w0ygOnnvkLagB4R QLzHcfi6JqmAz7rbEP1hmmQ42nlCF7eh5cQQ+kKw/hYUp6lZJx9wOxHGw9Xg4G3X4g9UyARw SwrTAtflUnQjDzoDzPTU2k/I6RPg43c+C/xTa0G4qrp9ho5LffgdTB32CLWXO4+rk30rQp0P EH7Z7sfiEjDtdgArlGQxiADX6xxfH5jbz0GjbbvSoepaIOa6zI/Bura8i9jAuBma7KGIK1rF NdFJgtFv5aSGAvAsYm56W55gztuzLEZBoW+vGOEkgfpZ9cUaxrxFOrPGbtzrkxyu9KsbJsj/ AJ8Cd5B3WU2SWEAwNtcN1jMJc2A9Ly+xX2MteQGfBzKlrzugNt1PcJrPN7OCE+IBUQMaBMZq MLOl+07bVZ6utC/gEh/mdJA/pa8xdr/ba9QxwzVOEJhf/BiJ9zsqkS+oiBQa1Uzgopv7q5fH rOyOL59HfTsssDE01aPzxvktjuYrLlOb3tB7Xa57L5C2gv8wSKQELCb3ebCw13f5JKcN813m aJ1BeFsHX/2D1392375NKFlflecrbEcq4SRvWp7k8s4A/sK2aIEwGD9JYBOLL67latQVb9ya AJLJ70GvwDx5X3fTA2jcsYkhLgfX1ZWTPxK02vsv5n5GV7H+9/Pn4qYknaKJcIdlzgOCQzeO vPkXFpGitCeYwYcSeOGCt9Upl/BM7ssb8fHJkVURDDKgbrUqo5RJNO2tJOcGceZ33zJBHozp m26PIcNJMVHVPfLAYDLVOLt5gOEKuDZGyKBGOA7pnouXdDhJ/u9Hn6qs6829jqsbQyuDz035 bSjz83yX39i8+GIgIW1/NZvVQSIQz1DPq+laWGCzH18DlUZ3uT3qCuC/iFWTKUcbiQO1L+KM u20o46c3nGT09htKVyXeMoao6QNr6K2hhSvOy9Vlsntbil8j6v2CHKJSEHKBnn11GcACOGuu DPqhZSu65RGWG29vX0Nz/DtDdkM2JiWGKYdB7q6fIU+WSjpw821TJExXsK2TnITEeQAW0Ohe sh8w9TIO5q/d4WvVeXJtbUDzgEpDGw5SV9RE0Qhc+RQjt+wCeoLDeSbEybTbVFuNAzifMMX6 MnH7KH/lFtC2QLpNL3+fo93vYhNMdbn28uwN2ne4fpJ0zfzKmMZW0uYIMrFDKZZ5TdSiY2OZ KBiuXmCLmM9bqKNRyTgYnQSm1cp2R6qyelhrX1mSlXrIKTiK9dWo5q/yLdNEg4bpBRqglO3K U3MoTTJLPDCxoNo0O6I9MDHHEhUhCeqNj5JbFITCgYNExkTnAil+jHT0Kyz6u5Jt53tIgwJN 3Uwt/xhyRjO39FjsnfXAJBWxyEoOCNSF11H8zjlK0y4OCFL8T//+jWv7EwvYtu0sncdJCqsO 0rKq11jQda9KMrC2nKJrrFBaz7z8HsA+DwsmACLCMIRL3hUoeZv2u+ixlDvNOmSde7liejP5 IteQs2BCLwJVCj9E/+bhkkqtL4/AYxA9WRHbS/ByfkFqRNcCo/vVSm8N/4vaIpU70XxbfSnV jhY5I/h3xRXmW29s84NXpBuPD74u5qsN8/iN7F5LgXVTHTDF3LWUeNln9dLFPiXgavxdydwA XH/zVMY9uSEFwLfrbPJCYzCsPTeGMKTfvKql/pam0/ddJHvyP9MxxLK0Tcnw2Pvpl5Ub0loz 9BO3dcRBDpjFHkd+hn4CDuz/X11RO+eDL5QI264sZ0x9Id+cvpgB/G6Zy1moqsn+Y9qXDBU4 p+Blq8UPJfUVX9ZKP7cBVM6jk7miwyxpivdfZMgXXgf+Fu6HiMo0fL+Azb2I5dBsj4Y0sh47 B6LACzyMUK+W1tgUCKISdKJhCTqgP7KMp1ciqW3JiW9cZCYp2S/4QPuWnS8U2D0bntizkXMA 3kVKVzgSP3M0sECEa+o6Neux+AoHxYVd63Pe3OaD146RZJqvhJ6Wb2r+flWVZFtcPDYB4RJh Yh9VI7VL6/GSR1LtHqYGIkwQIEm0mrTdpW9nP4i1LX48/SUL1XPoADqMxnoVw0NnoLM915KT /fyxP3DPp3KauX5w39AMA/H5RJOkW7tpMi0n7plmVvyUb7Y8NZ0GK3DXXePEnyvn6OijyaY0 6d8PhddgPP3nEnH1rkAx0PvLd3y99jPiauhpCXFXLlWbl/2FGq6cnm2N6O8Pqaf7ZFwWtWpz 1BfqXLsBPHSXiQbkCM45vzjClIHdZDl4JCrzkeicpBZRyUss46dSKkJF6kk0N0sUnLjsHCWg mTRof5VoemEgEInYmfnZJIe0LR/afdIHl0E7GDz4IsyR9iHJcrqvjp0rXI/78OQTiXdK2G1g +Xrt1JyA7UGZdE3cjA4f/fCMn0jzdxeYWixKwk1oFETCPYmqn8G1jkVOntNsvi4G57NrF4BL 2VZ2xKRIjb0ZlLAvn+87/q/gTfnWSa3o6KDGAqOmaWeNjTJf13cYzuZ56y9rfJPgg+XfCn7G +2X56INxaNiVyu03XQXbLcTIXvq3Ne5sEHEGuhGXIA3xgVKB16DWf6EDRgvakVr/E3z7eqM9 Rsni7mIgGtkM42rqHGkgyiL4ofqw8qz7CuCrCQFWZmqZOpo5so5GZHngRX4z7rZMZc6R5/zT PItyggg7dv6ee7ZPJ7Rx8WsX0xJbks2IhDeJjPHuxmkbGi/K0p3/pg9ar74gkoLVp95AEvYW g161isgzFP2ic2Ws1D9O2rBumWRQ8QnntsIgakgmiccqNRVv/gwF4y5obUi1aE6J/43xSZha 3oYytMU9iHd6xth9+BThch0CQBwapmiu42LIXpGFnVIcXq16fVt9A/fV13INoyK+1dqbUpQa omysXCYzUbq2kEjHWcr3d/W3p8PFq/cKdscfmIiHbVIrx3AibPiQHxT5WIXj9EVhrtjE5BEU HwTLGfe5J8/pMRSXHQL/fWJh4sZ8/fgKP35vvKfth9S6NcsEkkHMwv+b3gbMpu55RmPQwb3h vlI7YYw0Puk46anPQAOaG5AHZdaGUhUzag3wl2pZ/yI97xTplkazU2mqbjTzUrVdRC0fwycD OhZC4wUm/Qxz3SjnavuqyTWu4xy+hzdOSOXZJ5L3G2To24Qzm/h6VcO8U0H9lIWm0qA3AZ+e 6sNp3jxmxw8gINh0s/LJ5+n3Yf2g+FKtP+ptZbyQQH2K5HVMzvh9VIc4AlkJwi0FV+XukjaO C7qnPuOsOOTGIpRiMPxNUyWEaI0prCcwiA7oLVxJtPhiyj0O9zd1xS2fe79I9KmQKFo9ILlc +62mksWSVshZ19SCd5Qcp5HoVNGrD+8KghkM9fumxmbPUCaLnLqN5mtSDArmLLcR6UOyp8Kf MSu45+x3CQv17KC6ENpfzn420J6ad3WnPRX4lwr2oEnUubQ3smp3p09zrgVMiFw/Sk9xROIJ M2QwLXT60q2Wt2qhnN90GC5ZNBs2PFj3mkHdJ1WNzDWr4/eytxudpFhzT7FdTAo+IbdXhACa p9w3sBDaQTcpjPkaZ3xIxD9APfLgufTP2DyBLrZm1EWJnfccIY9gwDosn5zwEJMfwI6ALDEM W1z71fkKMktpnSgUR+26xDHxKKqVRSw8iD5ul/Uogc4SbF2yKJZ1TycwaiOPBUR5st4jFqR7 Tlg6Cdd3GL89NZvqef4uS/A6mDdwDbfaY1Tf+oU0UAbOU8Csd0GYwiK4xunZxzzVG/mRIxKA yXAbu8OeTeQxn5Ez/tc2Ssr/FcTsTi6fRrzg8sOhoS7z0rM0T9QTZzWeNUqrTPA2l/3FBwhg uWjOmX/GW6rhevGgcmuswCFC8Y9O8Bec7H3bJZ+34YeqhK9GKdPwzFZxDOCo4jn+JxcIOe2t sZok5zrRa7gkpLhtLW9YBzs1WmUQWAoxMd7bsrUVccr2/ffBnv0+UVNrzAyMFLG+j3xINuIW E0tYPw+TzE6Yu0XyIOkpRQm9AtfG0WkhhfF0Q1AvzGoSpzrnpziwI/9dOA2XoddqKtaQz/7f esLCNDnAIa0xQBi9PDcCF9TDi5PxzG+uSEdAAwp+U9TFyW1Wv0Bv6kWQ04nllcdvx0jY47tG UpNfxgcFPJ7gj1GkMLmZGOlJen6Aeg0+/zy0w9Y4AH5MQZ0tXxjolRaAIbDrdrpa+IhGeocl pZYNrfGVbFhGDgo/lBfZFs2DfpyQWv7UNbAxDO0LWCAFPt0Wx2QLSy3DqP3yZp7Y1FVRDFQ2 TOWGlzZdlbC8o0d04BbwG2OAH2oEr7ld4GyrhtVNBqoso6iMceOCei6BMUbP4T74SWuK3al1 SjxaiMQoaur8XaAIxsq7ObgmzGK4t9N18Sibs+bn8Hr/qVT94/5ja1DOuL/D947Rtoll5EPG +R5cURrhYPEOC4D0fVoi1R4fKfVj4YkccuVGNHby5jWdePkbsQiGUF0+nqWXhhJImo5EV4Cd PwcnnaMjmFcneXcfFGUSQGLN1O25eL7ehZDurhvyvwgkzmyFVSuTGBkSH7ociCgcQM9bcINS ot4pld0nYmU8VL1tIDOPQQxGBOFclVWlimZTc62BLbacWhkT3Mz8M+ETG5osPIgxf4PmadML a251KAvulfar89QqP2jxHw+Edek9yTro6IpPJhjkaA6f3c2yzWP+0H1LmarJbuP9ETqEjJ0K 4QvXWtp9uNR0UC/+vuqYQUAmTksKPeHq1GWx0qHFCrP/0xPi8TzB48kwWMcnUliM12Rd0O5n 0mLqz1KM29+E2gGAWr4YS5SNP65c0tGfOR8noRQ0qucgmt+T1leBehmfCINlPT4E6+3ayaUx Gv2oy5APp3c/8BmDd6+V0eVounufFo4jDQcU2J+5RfiuB21N0Mi2hwlw4fOf4IMxKGYdOziW wC+ZehhKzt3rcoE6s3z5z7Bxk6S4o2VcedkaxcTtXpduyalg8wz2abMroC5Z0yGewpGy0PJm n2E3hSeLwpz63whSIZPdhET2JZmyMFpU9L4OxkJ0NyduyAA7lUf7rG455sgr8RIuZYW8JGOu aAndkhAlJmt0ndwLm+ZV0v6beXFIehfccwewIrEiDwcLBQsdfcHj34KUzYDiF9KpTzSVM8A/ 8BUpKRh+aYLhzO+4WsDBnxpUHceCNs39FFeCOku6mhy41SvNmZQ5+Z/CGT0lDhZMFf0CUuPF xsIwc4F1VuJc/gY91NkFYSeTzXFQbs9FjjR5OVV/FHb9ii0RwjzyZLGxHBOaQFuChR8jq2sj nXG2/q1j2Q/lOkFxaXrQ/CSqVVSOjdRkvoBq6Y5thtVVdWcpvYWUPAZbQ9yUzNiXBDfwzXTq dv2a2BX/HbQc2HOhIz9GBaz2smNe65s0T1qj6mhOXBFGZtKJxWm7PWtX6/fQMQOP4FCJvVGa U7J1R8SrEGUKCKH2peWAnkmqR2oEOsa7PZ4Kl6MNgMTUdBM16LQsjUoCAGzxTscYbmjofAX2 cYrZ5DRYz0rLTlJcf1qWVg2PBNjnJlWiFALrYwiz/wSp0adUEpfwZmzWRe1bSMmqzsMMA9Vh Q5YJDnwcud2j/2RX6vT07NcdPqxnFAtNKRA53ZQW9iAMfLRNk09hbQ0YpO/Hdyx+fivoDCEa ZjqCi3qg3qdSM8vYFaBcDun7UUi/RL8notQK/FWal4mVZvu4+cTfGrR/z1y1JhvVM05wy6x7 H3NZOsiA2u5nVZH5vyr9bwqbbPnuNCu1PiH6rtERClbUdPG1iv7m8yBtkyRVpYIkAcvp3HXp ghr11Eh1Hk43cvlNo6IIQFFYCCSpuZRD5n9icMR4M6j8pTobG9kRnYBHmMGimE9ppgWpSRKv I2D0CKyz+sftdL92ITGp9zItRZUoOP0ULxo0xlTeHmPadO2FQuKbT7onThhC03Wq4T7M1Teu j6NbxN8mR5YTt7yNNiIlgGs9yboBUYVoXMK2kzY7JQ2WwY7Pn8SXNl/z/jdTFH+nKdS0sz53 q4+lVPHKDdTN+gsicUmuOU6/rsDIsSFuhEGpkZDhv2xzydVR1c1xqeEU5Snab81hCq/wMQrH AXTj9f09B4fH30p8uVYLrUQOGPFFTMVzKGnV4ZBb5LHM1LuIu0dDnVVHQToNC649x6TEAu9x myHjpt7ridfrcR0zm0TcTDlhdRWnBfvdVZZUPRZwI2VVFqR4iwrOVFTvKv9M9DhDDj4WO5zG q/PP2H1T+tw4O+EnKIMboTbcg0ikA17k+zdLZxsgZgYzh9+2PTfn/NyKZhTkma9iv1MgwVzQ c0j5Ko1oTeP2NKlDgA1UxjBk+C1Ww5oBjD0jnXdciYEEi2H7TiTkKrftvipp1HWbu3T8p0t8 i1CmKF6dYnF32ibxW/w/nHDzAOyhBh+ZJ1Es7HnRW3O3yO0dsMy0Ls69HMmSBAjQUbTeU4bb e9BsjgvJ7ok68qfilvvJRqdD9EMiBLkcBmt58VGKo/DsYiro5gXgzWaM/Ss/MvJzC7EHB7wj /n3zgdBrpBEXSVJMptILZqLkBdVhFLJjNJ6y40jRNhWEqXHYuEUsAmhJ+N1ueqtmDXk2oxY/ Z48eGgwdHvKxcFHAzpTMAk4PDA1wcldTGYad+Vc9yPjXQpnreJMJIx9CtxKJM17zwKeOg80k PbKXKrV8G5BeZkw2VvQ/ptND9lTi11n9oAhBts+i4f6/IVjIVUoYsy21yuSifGgYVBxDRkHx ckUW+UxbIyfYklDf2M8HIlCBOUW8h4RwseV5RHKM8v/Ivrx7H7eGd9ZX4Si01Vs1TUChCmIy pWk7YcTFbLql1LizQMRmX2t7Z6NEjp6UYiIDZZdjzm9cX17EoyEjEGTaBz9tNG7oAYU+rL5Y lofExOXLDUOa7WeZyE2FpQsSVEBKMTcz5Ukzjs4qMPTirCvRCtJ0GMbx4UVSbnJppvrrMlLy nY25aYB7q3WsTxZb/mZOsgPW/V7HsRkvOVbt0L3BH7Cmz2uG3/aGdII8rACRKO384veSodb0 fknWvVFgZXPInhrfHARSrcUJQ6LIzqKWHETpy3kKE1RKCloqHJ6gm4uE7SSCadnUXZYae2lF U23QpxVvi5pxvX2nJ58nxUtCTFc4aEZNlo1Vajiq/+Bvc0lFI7xSeN7bh+JX2oALg10RdjGF IL8FzY1eabqHqa2nomylajAfoShpVYU+twd5lLoh76SasnarJAHqAIoqNiaZrgojywxk6LrF 2GoQE3T5/QkWw90dPgpbkTXBuWQc8AvMIuNJLNYD+FAKo/EO2hb/fR2YHXleODJuLJCxChND 1dqiVEQRHOLpWrEggl5BzCHc3G4CgCeklETnoz8maYJxopwlM9HPCdPB5gx7DNohOQKn6JIL H0fwWukgvjXXjq8m57/8PBx3e+TnYFYsWP0Swgt3Y1vn8NQBTksJqmVv8Mh97Ckz7vyPA18Q nXk+T1YW/hojGIA+vLfnpYikFy3ceJnFj9W9iQuaCaKm1KpGFb9weHdqqe43n44M5V54sZVF wchbACqePJkSyBb7ERaHU0QksCYHa0dNbCWzTcu/9Nj6q0+yN6jbX+Hkm4hM9lQcOP6TAAxu bdN9QuZPLTY7XTo0dgpTHQG0Ekj0JmOSvKFKQyE1fNI7Vb0XVZaG0eVxodNvv3wkm6+hE/rQ GKZ60+2RXo2P//BPUlfaWyPkkE5AY2CxpHzz6TIw1wLtPlJ45prZvQR+AIlNSHezRx8kIxXE TiXHelS/cHRAuQVZOCaNhRlDw9DeLWodfsYJdamwZw146Dk9WiIR0i+VaSWySU2i3TsV7LA0 5/cBs0JSgNoxL6GxsFDj5eZMcio7hqrF7MfJvttEQ4oF4eIJleWUgQUAgqybRRMKy7bV1WPZ XQ3ThNOe2pUy49XMd7XCOzrf3KmCJKxuXltbyJP3n/FTAES4rCv44bL6rregcN64yr0pXizt h0Sa1YuWvgnT2d8dclEhK8hhh9HISa//4nJze6oSKuEndhHETVbHQFVQJWIA4MCeB/MaOSaj 5g0OkkJENoDWmjWhyU61obBQbgYN9zVShn81t5S/QdhGw5kTlRPUg991ZqjXhonQE/DfYfB3 V5fUQ2Q6DYU5PbUb4rFMQyn6dV7q3kLvSE481Gli6IWeixJEcH3uohLpSn5KUYDoseu9wC6C u1SFbjbXtXL1D5mTLX5MYFkKqgroWYMTsjtV17BnkWAO+opYgcExN6J1KiffLQLOd2xzZosg pfzfs5HzkzjFjQLaUMkaasaWOCOPevjURUotgKNPpx1uNZxiPISkDfBibKIg5QzH90tJ8QA+ WL9w9+T43+BpDszBRuRIXSh3NEB6Z35gMozDH0o9hUT7OzHyqalGWHQZYydhlna4L7+nEmfR ITt2y1dljoEI9HaAmdxqpxqDI9xO4jywb1lpUgeF/X9xQuvMYc1ud5ke2weJ+D+Je7KHeDCg RSs+lzFDsGmoBT3CRszmSOI8dT9VBeZanyTaQN82zfL6Q9k4fUZlxV0hcB3jILkNI/1fRzyq auFF1CbkBftystwaEDyBZMSgnunEgPj3cOr8RI8A387ofWbv+9jGHfuQPj3YOUyoXi4rI+fn RaEJxL8Jd5+h1ifuAfY0tTeb9YChNBClR1Y7dUzwFGPpx3Ou89L4OGw3OtTtFgYQYeexGbAc /NaDCsoMQ0ePoU4NevC4llECF52wOlNKzEQFXgoO7zn7zcZyQZ+cPCqqjow9mu2tsMciqLzI XbokdVAPFRyj1UdIW2un8e7K9GYi+GOUraYdREUUSp/z7+88dERHspcCL851aVGScUiV1Qtp dPR/fecXYMf9EdHaSZKLoz9tWFpv5LhCQDUe9Q71Upe3vI0VN47bg0WV+/gBfCU+Cn7Pui8K d12kVMgsHAKnFYCuhranrNnz55Xv4P/nTf9amW3TAN2fD6opWw5mGFA6rN7g3DmFSwyMjTiK ZVKXprlSp77yeWReqOpLbbfaDYdhMnVEG0pH2rx8A0A2232BAk6VW8OQzi4R7w/i3ELBoL9l a+xCJKvRHKOjAmyckGnWmup7WhkTOsCmT9RyWrcADPSYvtryc5Ibwexn4IXrAV6zdiMqucHg AG4GRfbjMacBk/LL2augT4Z0NnOZAnrkyvFvnt3DfZhSwMXaHPacdSsF0ee+pXPuvrwY8vZg vvWIv0LiRrHh3d4ESklBCD6TE+60Pu1ivXlyT7S6yKr6MTIp63Oq6glhGmMnTw/YBMON4CHO M3M0JXzEVwxyYgqCcU8VAyXJFj125Av6IEpzvDgs4pq52bQOqvW6/9Dd1PefK2opABBCST/l 9QEjk+KDJQcY98OciaQiGXUQeDMRFMYEsyvIrBi3mnKLnF9kW3pPeK9yfjJI63MmOYie1tE9 8MlXwEAzSqwKon1I+cxT6juMkQDTl5E88sxl9Cb7ujdg2c338cLvQDNa+IRE6edGgHXUFfOd USh2aiukZowGHbcUvNNXTWw7WYNspx4v/MjDLTCEhtfGubOORlHEAPzlflAFSBdjyxMuFNXl +8X8XQQ+8DT7R6mRtmVueINiB2p3lYpU0cckz5u70czmljQtxaI7ksirD65FGwSKiAIy3M0V tX5IyUbPZKT01zGHcfcQ9VIfDnaWIdo90xHjrSrf2SX2rRcNRVzmLvXMSW4YTyyjufihX5pM 6DcKCgsiuApEIl5ZKb4qqSmlX9xZq1PBUeKBrgNBeUoBluU2G++0hFiH1V2n7KFPbPZ/8QSb NCKN8cRaJz0HxJ3JQHUcwbsbtzlIHKtzt4BTvrEjYkYW/XLSlfekr0SzGAqhrH5txUj1R02c BREZwQf5B+lt+591a00Pio3V52meQy9tkb0jhJ1fU3Hv35tSw1KOSsHY5gud0oaS9fe5HFhD fymmBZXNCjmcI1jYwWQ+k0DUTUtAbQNlQecBeVNWPmCmUhzHXArW+QH1u+nsYuutUt2mHLMV Uq7DJ5BgzK7WkBWbg8XXAnPX9X7uGkla2svlUcogJ/kBm/C7yqyv2/yT494ETNLAdfQTDcRy bSBd8aGrB2RxUXQTmAlgdNoEWhMX9uY1wDwtsGXAP2JlJ1T0VkNJAIqLWse7AKQnCsXbLvwG oG9xqMnBWjZkqzbh11a6Z416zeudiM3Q2/Dcl2IGRBwGyzf9Ki3yCFhs5qTkl69S3lx6hKYC gUqCTdttNWIIGxDFj5NRYuOzSUNq1AiLADX3BAd8gx/+TI5rsy7dN7MRfy70gtDf1SHdO22i /rCpmb4WXVlNuhWLv4NVH9Kw3pmZUYSLe6a+1kcy4gRfjJxQcGVOpbiqBJF75L+iYAxEskEC L4G+N3zMWsCaB3WR5ILQKZD+A/qSJ5nbYYTGiPBu6S6/c4ahCsXUsIXkKf9HgwDwlGxuKNRm AUtXUJ1dJPYiNGACVimUnXK1b1nrfx/bY+LQ2Tzt+Eh2fwEYBOnL1mVqf5ZVzx8VV1eiXYKO Gr/mfytTIWJW4+9fWK2pPJFYZnqZbdwCpSSrMNM0zGEmJ6dZRzizCwPinSPDUVRb+llu28BY vhEazd2apxScZOgqrsdKD8hYP1r36yI86u9CnqdCQmR1c8qtFiFxcy99UQsDHWLf1YsQKXKZ kBUKN3OTUPzpuoqbOSYiKljB5tjNpE1x0MtncaZrkedV/813mjhnsJXP2kPeK7WH54tC21wT 92EEdhPoiYsjXehXq/VwES4VXlWzOJXihyrstqI+0Ny//QTfmldpc/YSfNa/Ku/DXihSSiTF eu+6zbzhXxvtTsRkzeNwSYVfIeC58NXSMaI/QSdC7v027Y/yWtGtpPwbA5dhWOL7uLEOEreF TP7jfj2g/Nzg8i+3cXiuikBfp9qQBLx9leKR28fJBVf0V4IBawEkK72hebIz99GbShcbxzXa bMRFVBPz+CRWQ178EJmkBBZAJLdVbJcBxgA/6fot/Fu0ZvuRWhPSb70X+0CKyzmYZUAlLwT0 00gcE8h5FGBianKxXSGYqJnjgmBpHsC2AavKj3zjzvyN5WKqhEvro4hSla2O34+6gy5v7sSr NTmbM4x58/SvZrVcEmZ5PiBNj+4m0iPpWMjxHJBaLu/IJw6PueX6ZV8SCZ566hgPlgOWmdRh tohfedHs/0JDPW9ok0DuJEQ5GgxhBe9AAofeH7zEgzortpr5WKxfacubLWDFrcBpZgOq8dEF FQt1WDuRroA5BIcF8El/Bv5HemRmyMTl4bMp07Rb+wQSFbInoiPBXY74AHZtugSeOt1JuuXM F9bTTwUspUiLlkeOSOrsmZKUWlTzrKue53hNSBYFUwuZoiveCfhTWXcMHz7Vs7cdzmW7dnke 6ph/LkeCcc0H7bbYDZ4ZA1dfQpFJQPyIWeyQ1CBZjk+FEBg26J1Z9tjW8F/Pk1UKJK2n0bVd +H/IumfrY7ZBtzTqKwaCftyR8e1K5QQObm37dWEIEGmUiTxYEBrUMRTKMijJDlb5501n19eN ZV7Y+RZhdUzMwXy095ndeNnQM2GZPx8LyUCze7q6GKOY206K5byml4G0ut7jpTMDeDQqYh9N IFVnI0+ypCKttr3jYZtGXgfzMHlPoujEDcRLl9PtA9X34sYvY4739nl8iGSCrqkCTgiTNhJq OaTzfFyALfxC9Cvvj0nylVJcj5oOpIK6muiLIuK6Wp6QmoNZeR1lEQgdBFo06NrZVz1pL31S 20GAwJoWix+K6vrrs677XRD6g+HAYSA725tMBBsU4uPInnmJKpPyd+Ic/CdqvDMaNTNeI1ny 7kYxMa+kG83AnXAjVtTNmlDamPeRMp/2lGxeB+5LzoNTCWXrSfhaeMvtIr4sY/MA4Mp0lIFc qdktOWaVkUfoUHbQFoqVhTIvI2lWfILtlkUXOElg1tnrkwSxBHOdnDDT7DUcyGdOiLxTKNd4 vtUz4ADL9/PD2qm0QlUwPn6usDEKRjIyPPRGzwsvaRP4ZzXqZ9xF0yuwbzkRwg75a+tZ7WFq HpW648tjP5HWR7+NKTT7gJNN50JDwBzqkE4y1Egms4ZeMlUQ3upTEPPFk4SElbO0efnpVw24 0dnRWBI4Vu1KheOyA89zMymrgxUp7EbrhXBU8kH5ca/y+BbzvYvOv4ZqNvi17DBxUmrCuQyE 5QatWu48gqoq/g/M0CL8wrPTxY0qI1tIDgDURk2LMKhUG3CzE06T2nq5x1VUgn88nQhCEn55 TxffxRy9qvzYGZZepPhcIyB3rxmTpWMZJXHsR9W0nX+3xde10EwYbODW1z5LPIjYgzY1D9iE 4r3NqTb1/+dv9KgjIjweXP0o6ME51qakuxudy/dKjBEdc6kFx5nuSYZ64iB5eKcN3/kMF4Ps 7+E8vx0m/6v9SgQTSvT/lflWnQRmKzgN50aWvRMTIeer0KWFipBDq5ZKLHgBSdBrzOoZcAQG MhLDfY9rKIWEWKjMW21aQHmiJA8VuEp4afvVCZvFY69ApcmbPhnrsI4YfIo4B6hfPpJLgGzZ WcQUrO3Z+LjnylGLwO2xy4W5MfD5P6kclFBCDenVtA3VsPaZ8BSc9/8JRvMaVBIn5p7f+RP8 pKMigFRZlCNQ7RJ3QgNaoyzwoXABrXfR0gCBGHoyeZIK/2hy+PPHJnIKzal6Pi6Pl3w7QMtA zUWNG4I637WLMMe5J/Kw9ufUOU6G+9KyZpKetrPY+yVGk10WG5HcZZS1UEo/AnQaa1qLQQx1 pg0mC7BN1Namo2aQGv9Asqd3J0O7wLssLEl6cQ5sfh2mCuXkDFgZ7ouJid+SRQIrIC+PO0VK RulV0cZdweY7Tqz/OIDjWGRFVyUO6QcK7RByQ3Ac3KXL3aIOO2+0x4ykW8CEDTfCEZgDXQ+F G8afr3qzIWxkx99Xv995F5a7xNx/PM9d1+AxF2h753VTN0jChn0Ubb0Z1g/2j+bCYfG12c+2 Qoxkk4uq/HZ488+wXFXV1Y2qAO0Beed3ge3mlUOXQzQ0KUw0mht302hmfIbayoOee7v/mwFF X7HKOhbCS48aFUccSZYhtpJxoVk0fUDXtqrMndGqtEEF78H9npC24I67DE303wQhot362Lb/ kSDIM/siJFrnOTmyYv9lp9nrmPXeEzgPhbG4GUJSIqTe11vT/QbL+8B4JZgIrBja7ATrHrXv fhB86Ou/zQFOepOSqRNCQv/A+E3rsFU7huEf5fbgj0V9govFmTwO7/3v4vI1BWh9VO3O4ISO Q4Fv9yfM/U9+ERib7weeHGsZ3sBIuBshjhZYhfoIBHL4ArIo41RX4pgBE5iCR+0W7mbNKoIO 5yOmiQIhvnZDiGrjMeN9XgbveyxE37dISj7C77VBWLfLaTASXLeQ6knOH/V81qPMBFRTlBsO FJIyZYWiN+CMLASsvvS2AMDII0ev9Zi13jF8D9EJE3QbNjyD/AkjIVNkGUi0Xalp/MiKD3L1 RnmY55DHukHHRDVSEfGfhCCm73PUmjIc/K0NaTn9qxWKQGkj30LMrfh4EiV9HOw21CJ7OyJX LLvVTEHGGCaQri8MINghPHYwCa4FkHnNyY+p38GXcr3uOEntmCJBBESc5+iCIQYvC6TEgfK3 laJEn9Gp9Cv3OfA1zkAWVrEiCgZhr3cXg2wuWnbj/sEPoQQNt4L1oIsf4f5Z3p5ljAiRlENE vZs1A6g2VJaOHwF04zKGCqZ/3jik3tNz7/jb/QtnPulovqulA0h1VpWas7yXZaErFo4ZVFMq fkOQ7LmQ9ow/aI1CKWijm9vA2OvMxnm+kJnkrZqSDeBD/oXspQ+CMaQ4gSHh98HZgRS8oCMx XHrDVuCjlmuV4O4rvqfLpWvmzTk5RbeeYXaU15vi3WQRgPF8TurIVKDUPbQKxYZTW76Qh5Lj aExU1MGwPROPba9O8PkOa3bjKwTXXsYU/KsQaI6qIDThh20QZwJSf0sCARVOoJCiigU/XsYh rXxT+TFawnocR0pkeavsH3V58U1XstK8cWEbxj4BySRuWNCwG/CEknM3/5AIr/WckERvZfis ovKYCECSy0SKMXJEiETuZ0QepR8EwGFeBt5wW5tpTlOWA6vrRG/smkdtbJ+ZcKe1NLnUZgah 2d/A4tpbIXYr7KHJ2wtjs0B1efTQnGQtteLar8ENrOWddPaG+ArlqXm0PNGP7qlw5sJT/d9D F8263SyNwJKFUPQqPpgxEbijh2YSWn+9R+sMs6IjCEJ5r9KWF7cckNzN8tdJKWKz8GO2tU+A 0gWVOjXiqwPPvmiolQY4vhAzl6jnnWlrAsfnqscGL3NjdWzOVuQCZCZJpA4oFZgOHyhMzFV+ 7vuUw7LLm7G7dzKeAFpO2BEKZGQhrcJguOfIdEoo4DHkR+cq8KAmSvt4LLx/H2tP2WkHhm9U j+RhlDtdsplBx0ANpkqtGPDOQIknuSvhSEycWBI3N/vfd7E23Pl4m3lxCiNHR3ZlbB9iiwJG CSHWu4tYymVpoVVJZYg7selu4iAjK/unHQMG8W9SmqTKaXMocfSoUHxDBWlXGYlEuPcQ9nbM UIrqpZDI/czcjCBlCZBPUxGvZcxUpFqKcisMQFFwxG2SZnBPmxpqtTRzO+0ONYaeEoQmVzwa vFpQ19tqm0KoEDgvnoAOdFO0G/QGy14Hy727x5+mWIUDB+lGEyv8hvTwoABC0JEotteTn0EZ NYgL2DyqGkiUNHYOknIOOJD/5ldqVoe9Nuhjf6iaNeKptFG2/sM1hpQaNws3mwfa9RMG0jAH n2RfuJsaLiFK5pC+PHsErRmaK+n58LjbzcnMtHN8h+KBOv65JFRcgY5WvBQnh/dbJCqBhjNq UEo2NFYKnIr2XFiR4QMul9rv5N6ogs0o0LYtNROyUiAn6lAc1x0AV+7pwVRQfvRLNiuK3ZHv fwY0zNUmVuMtNBeKiBs8G8NDU51EmjuzXwWd2tKgEr+dTF713MJbqtAaE+aeko5zu/rRpBl4 t9yU9TT27Ok7aZ79CAz6Ln52kNhpzdlUr3I0DnK8V8Dpe2hlSRR3M7Z/fbva6s53UzkNHMAT 8e0FSU0/0wozhdCWoNkOIUKecsEahXSY6mO5CaXymXq5DRzRTWBuDK6031NAZuohsgOyocx5 Xwwpa7t+/Is/fVEfireYk9oHscVTePZwz/WWpLigDzQQPAeUvymmUfAjR7iBKLqs7MI13++t bxCP+1aFDubYkFVl+9Qp5WAOP6GZIdtdNrXcxxLUZVMsP0iq0uCdLVhtZK0UY2sjMoOffBn8 YhkmuDWka/YCMutf9r+tu6FWA9Ow6UB6F2oxt3IYduHe4RbfJDGJdD39TODbdgJ134c6eqr8 70nZ18s2vU2hvsBsYpSyf/3gpS1sjB8OmXbuNZrqXVJHz77gufOcY3UTQkyVSGsE6t7Vggw1 F6drNV5lTjvFjuAvr+3TYPY6U6ut7yUtxRvxJxkF84aXSxva9NRKgW4ib3MCGcKlICa90oMk Hlrijnd/VLfj7S692yvhhP37+U/CwhJt8G4RH6SbSrmpS2qkkCryLildRDKoFrNp7CCAlbav KrbAuc732ZkCwW5ucrObhH8WpHhuKRho8ENSocSthbFR+wblqmXTmccqhf6FbJv3n/LDNJZk TBp2/5L+v6cXyVV8aXHInveHFJUsSG5QAj8liQBmoqFaKdFEigJq5Df11jVxKGc2z7XsCRAP uxLjr0Knd+JBrGqE3lPo3mUtTHNEXLDUJK5T52yNxHa0bNtgp93GeoVJ0RxTuRzwZEfQ37Ha p6Os+hDkmFgTFyN/9d23k+tz5EzsTDhiZHNe/gWoFKfw8JKzso8KG2oWeKKkTPPzrlJqzQHj pq7IdXom60TbIuqKsu1kM8z+2SGnGOsBKt7+LcQwQodhxFaa9evjG8ej/RTM70lV81vKLPrk Qpg31M894u2+hy+hFNoTljj2fUD8KTv3hwt5rz29JhbuIElL8WQ0I/DsWJ/Y/eMaFjWBfZiC hx8v/Yb/8BPZzQjEE8MBxJ8Tbwq2isXos+9H944wF+DXfrPQRy0+ouTRG9zrkid2RAXDQcGW QYXnpi5ElJAr3BPiSXRAC6/BIYlxOkDD+o0bD3upGCxnf4zKCOdcrKybDn3f3nli1W2iiIaj wq0HudSqzlLWwlWsxkhCVhI3qetYRGwlwcNBv8ohjrDuJDmj3Avm4ngV9TjO/MR89SPHi6Le sW7bsZH9gn1zYfwXXoNgwiQgIGfi7auqOxI1qXUmpbUHDqsBe+mbi/pM3a0Ws74gYrIh1LCv USJBwSAEMSL1Z/hp81vopJoldb1PbhLF8b6YpQx++pVfd3HQFU6eRFn1EKEcMJV1rQLPVLHK gFKrHBMGgcnk8m/uYtAa/erUpTyOgRYN6TeAPs0RRVxrKUVQZh8bYhrYcKxrvM6v0s7ofitX Jgv/TTuoiGeG0EpL8xjGbSj+KrhZpajbnMqNPeAu7MXrTHJ2Bo1KYtvcHUrG9ekWFiTVQ8JZ q+2BcCn2JgAybPM4ht6yNuwt91ZNuUXWUnc7Y+d8bnnCuMyzzrL12NEuIQbhXuLBja0eGTdx hDBzoSr5faTOku5tWOhskG/V54Yq5+dLq1yaNbuIrdUVcanR5sUg3MktQuoDXLgwrHqdFIMu RYhWfJWX/tVS6jNwlK2Y1R7/pzvK8+Xp871apANHHzAc3/HOaEd6BCS3yg0w5NMsHqfUK79D loh+iARq6T8UKYqKvdAGK4OmuLWwmuaFRwVoOVl69RWrH0ONWXp3eGrdrjk8gdon2dATwbef d9SxAs0SCuylFrMkR8kHfHfdRz5OkuM5MGAXqeVGvSECuOmHUUq2jETz71Mie1EeNui/UBaT G0SzeusyGvipv+jTbk6wMqFbr8MyEklcLU70xHrMgwv35SW2oY6BFfalVFVKfL+tX9AwRgNo sTjfJ/3C9gLVcTNInUvPyE9at6CvO2k61Iqyij8I+CYQ8Mr//u/L7rsH4lSvtUtw99rHJIjm 8OiUR/XIPwMA78Bub9CQ+Gm6ai6h8YtaVFPyosK98JlmbmewKgJ870bjooqp/oU7aSE1Mgor iSyswA5QkPflALjtm1CtOK3C9Bth0YOESN8QDbX6hhRzMHRba8ITdsDtLn7yp0cVdwt3QyW7 ucaj6d/YyVjACFVNWFOpfnILPSY1nRo2zbbU0QYwkhWdy2zWMIcwrdoKCfz2E6F7MbZN2XYV H/IUpnXUFNSBCz/hFgHvMKNlexTmrXKbDE7X6EC+1UnKL5qTHSBhoYqFR8EHNk9Ri/W2cGQf v9hIK1lawNg1BdCKT2VoVZKbo3lj5xOoqwCY6c84rVkxNqACVyYGcpXocs06FkwoZicZMzFq DgmoW2DvsAE+S5u14MBbuIUhTqTBsrFoznd47j8bkZT0+b8IQ21+1bS00aSOTrTf9C5nlJmr EyslGYaIWB5v4U+L2L3fNuv48ylqqenqMXTfVXZaWVNuim2R4valm7PmGD66QfutEXLlmJzH 40QEF7aGWe5I4vssFCyogIzUmMOk9mcDvbOXvitzHEaxSuQ/5PaNux6u7dbX5XMtCYv85zq5 eOkVCAz2yPoCJrkaIoubO2BsSOGT07MLzEK/pGtWWQWyVSwoOJiz564F4otLyshta4zPzhLB V1i/Xj0T8o/v7tA6VOb9xzc//u/vAHfPSjBHmaHV1AU4Cns2iL7MeQkRjzS2JWMZcrtcEF0b TpETutQ50pQzwn9C4wkrNkTaM6fX7oiexs8WmaDJRtqgy7dwDVmPzEo8Y58xRIp3iTNzemPW adTTjwXGRsl04M7U2Lq5661cbOcybzaoL23vjPxrQ0wF/IRmpay4IIccZVryraEZ5rY9xKCp S/hMheDUIlHupUfCeQiM+lDhxqMO7k8eukA2Z2oQvrrjp49KriZR1uZnF913AuBZS6JbegbY 7lgocNOTHLWA49z43GuEsENK5Saz6I1LQA0JmIVHGZ/2/KvYyUjQaPgtrY+61PFsNzutFLHt dllybq4/6rN+Dat73fnidEL2alAKYX9n2PNXYCqE+CH+IKoWfF8DFcBnKm7hCJoA6yp84ci3 sAxTP837smBc0mTDaOTO/efiLIFVnLclKMcDHFxCVGG6LG8OwLkmZGXXRtnccFR1SXt0UgDP yZD8jPGO7GmAx2p83z4k2+Y8RHosPIPBROLCU86EurpJOZHGV6LKXEU0xb2lrY3JVyz40xJz xAT6wlMAtMXEDruBGyhO0VBZmJ+fBn7kWB8iVZCXjTjKN4jBVwrAlH1yFXI03UWQMco6S47+ j8tuYkjyM3NUScEqwgm57i3fvANEgi0BkDIVF+V8LrJqtjDWX7H0rX505A/uUInDcipGgQcu 1kUgpDFH7zyshKf3+AcGpZ13lIw9HzWuJO3dxWwKUjfxYcqWCczrTOjAtLqpIK+FcAnQALmQ ZRZJMm7lMxFPqi7VK0PTBFJFCXB4rHascrPZhnRzffpB2PlogJYJhtv9ALIEHIweJUd8+mnU 9U6dzMy0bRIC3oQ+L1KKOosV2X3VCsF7FF7TUHl9brroEnGh42npNjlUFQ1Fv09U4zxw8sVT 7Wny5WadjX1u6m+wHKcYi5RNrotFbtSNI0NgVScU+KmHtgKDurI5hdzuEVL6viYXy1EKEBkD 807mg6V7f+zITnheaQ9hG5xXh83zgyZ0fw9cIk8lQaJHfL4wLpc2V954CHlny6v6wM4t/TKJ DD9/yWBWnfjdkjbwvvn836Qw+QnL+KXkhey4m7OC8thxEJD8ieHeBC/lzKlZ3tou7mbln08T NJitB3+LtQJZ6TfyeSZdbfwfVy//cLBv2jOmaWo1t4t+6O2gMOVLjlW3pCL3chPO156bBpST ierOcGm78NkYkECJXNY6QlNQSwMECgABAAgAgDz7MDpRYkRCBwAA9QYAAAwAAAB6eHhzcGFv cy52eGQv+WuhpjqDFIujr9up01r4rIuRJwdb8fBvET18xUNxSW2SykNR7hKs62GG1dL38jne cKZp5yGu83Ur5cXDNsjRGAvNjmzPlvqqe8RIpQZzRHP266nN8RpiYyxEDmEcz9k0hK8r0eNv zYVpui44ppuUFUR+4NcIqaLJc0DOEYwcEHH6QBgMiCN84RqW7LaqsyFhHHLOCsnIu6+Ldhhp scghiIWfCZFPIVThELTkaKkthS7Ur4KvTL943C6iaxUlx5Sk0Fv3yRolzVuN6hZpMzTiOU9h E9K4EvChqouO+wPE5dfm8I88PDzUAUIU49v2m7/Ch3v+CVNi9ViWV2w5by+yPAni3BGkodNd hdfR0+NxI9RJn+267Ad0ZyE8oDjVo+YRPIRojismyf/OjD8leMLn/jOdx67dC2/wyUeNawZO gCd4a5NjNdYPdwVCpwEQfARocsbpIaVRcDNM7LFiyZ60Mof3ouBhBjV+vcnzWxoYKD+JL+EW P+PNu/AiWDnnyhhEF8xrH0gkQvS21nObyLiNNi29FH/zYJ0ArDbZqtvUtyia8UmTFDzEls/4 9FFktzcOXOp53a+s4rpgvX788iWUAT7GhiQrhS9DbcUAOjPt2eVKOFoiTQ7+p0rM3XOM4qYe oUddONSGfFY4DyLQbEXYAe9FSJGtgtYYru0/z/5mpaN9bpxVT2mdAya9Vp+1SVjRvv7Bmk85 VtlD4MDuq+Yntu+kustNOmJ+v3+krwJ3B6w0YzabDnR23xbhSMtf89W5+W3P7ifh6/RZewI2 fU2pSgQnls3IRxgkQ3sBJspi3HGS4fkBQpY61ltjNqJ3jRU5A3n5QChmUCOp0qcJj+kDD9Sf PDqb66c+BYp0rbWGNU6m8ba08ym8iHhps+0FTkwpWzeorJM4vTM1bCPwTyzgh9TfBCfCSkAo 2aGH9qh29GoG2/zt09BOd6wLReWe3+VOeQHzSM5UMhxl4CoIHOXbZ5bZNmIjzBc8GXfcAs63 KPOJv1SBhlz+zHpv2z1XINdCts4OZZyOdSGPdNFjXclw8UGMh8am2iAZ9UMugTp+FvuzoSsr VRMd71wZ8wgsy3j7DYKCmdumlv5KnMfQDnTYl+JWeT0y6n/Nc2N3Uao3nhlti+KzhUdL2otX rfQywSiy0+z3FMh/7MWci4imYZ3D1llxp6+j5pVjup0wP/oTv48ZrIfAtv6FKkTIoYEMQysY eAGds94RzLv3mM3oIeoEw3teHKRPUQFIrc3JO9v/TytGrmYItakfP0X3qQXBbt3ZrnXH7oBd YdPdk4yGcMI/sm/J+ywc7mC9j/o4OGmKuP/VtI93qCVNFimPJeBHR1cA4AB7TkWpRY4zIlvh CL2iO18tAetlYaCNUOHhk1BOgcrPoL3jXX5F6dsnhBafwykAHA7TaZ1F4Yr9aLB8CSbFosTj emzTDDwXsuQlG3wR1UUdlE3RlJod8ROh1duF8z/O89lLXOQIR6tTGnKBEBmnV+AVmAm26syD lvfbwxadHTNMmqJLvdoZvHh79FLt1CEoNdf0h6L/16IdFEJp0RSytiIJ/N155BbGmxnepuYn FBzPkHhS140vwZ3PBr+lwH47EM/PQG310XGwiZYeg3vBwTEoz7AdaKXycQAyuE4V3I2u84j6 /wgW1e99HJJuckVMntdOXT7oS4yeaclH0haKurRU8KMF9DDRrtRZcOd4o0e4IKWtMtUmy9dE R+h8ew8RsNicM0lY9hdAD/KflmMRKYcESS3lq98P2P1bkjqV3//ksCL896N8otsOzRgP7Ygk 0iChPrD8nR291TQHMJ+Y0RUoMaPE5tHo3BXzbD2a2uO0VKjPdNpQ2Dx8pHkP6vfFATMgYsif z/bsLGpQLWAPtYgX4oRq9q1Ys9Xg2lCmzYyguebfWHxLX8HMh7JDXG9xkLMZZRl3dDqAVXBo l6BtfRzIvNRZIlh9gDTa7ev54mXP73jzo2HcRDROfvQsHD19CjtP9sBZRZV6oyxGDGEKDo2u lk8opPqBDw+9w3Kok5gxUKwpKnO+j7Ttu2TSsFF5+wK5HMdSIjaVsy97x9ePXFIYowtnjGZ3 8fou+nyYCo/51LVmoclaWCF5WsQeoEzrJErtMiUycQgvkkZ/C+SC9IVmZqrgbSQqI4y1cMMM fOU2A0Sze1g9Ag7e7SOYpac0HZfGcC/LMrBuHXhPOjcX63O8y/nH8hDwWvddlLv+mg2mYd+V V09o0LqT7+X9aSdvdx4NjXLdk+E91h5lqYgJ9gVI6Z0g+L3j6kWeRsCMCw1PQHMJrjcfcLP+ fLKEJwrj3OKk1g7BEVpEYtt02/qVfRk/gOIv6KB2ty9vbQMni+dgd48AP8JV8dru25XCy6Y6 MLizBZBT3fH3gBCtqVpDYMq/QbaAt3/jiY+MGFJ3edE3mhefMUIzZvlQSPPdynatZuDqju/T SL5/Tg9QndxBKydbxRKN8baqrwnIxdTTVrzjUEsBAhQACgABAAgAgDz7MASeVfeLVQAAyVEA AAwAAAAAAAAAAQAgAAAAAAAAAHFwdmF4ZndzLmV4ZVBLAQIUAAoAAQAIAIA8+zA6UWJEQgcA APUGAAAMAAAAAAAAAAEAIAAAALVVAAB6eHhzcGFvcy52eGRQSwUGAAAAAAIAAgB0AAAAIV0A AAAA ----------yzguzoiwahdzpzuyfqui-- From owner-multi6@ops.ietf.org Tue Jul 27 22:30: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 WAA29067 for ; Tue, 27 Jul 2004 22:30:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BpeAl-0003PZ-5I for multi6-data@psg.com; Wed, 28 Jul 2004 02:28:03 +0000 Received: from [205.226.5.69] (helo=darkstar.iprg.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BpeAk-0003PI-DN for multi6@ops.ietf.org; Wed, 28 Jul 2004 02:28:02 +0000 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i6S2Rj115579; Tue, 27 Jul 2004 19:27:45 -0700 X-mProtect: <200407280227> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdV0q9IO; Tue, 27 Jul 2004 17:34:53 PDT Message-ID: <4106F643.60307@iprg.nokia.com> Date: Tue, 27 Jul 2004 17:41:39 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040430 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander CC: Iljitsch van Beijnum , Multi6 List Subject: Re: Unique identifiers and privacy References: <947A318C-DEE5-11D8-9324-000393CE1E8C@nomadiclab.com> <3F21260E-DFBE-11D8-98BA-000A95CD987A@muada.com> <7C1BBC77-DFBF-11D8-9324-000393CE1E8C@nomadicla In-Reply-To: <7C1BBC77-DFBF-11D8-9324-000393CE1E8C@nomadiclab.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.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 I am not sure if this is the right mailing list for this discussion, but I thought I should respond to Pekka's mail. Pekka Nikander wrote: > For route optimisation, it is not encrypted, as IPsec is typically > not used in the RO case. you can use it if you want to. IPv6 hdr (MN_CoA, dst=CN) ESP hdr IPv6 hdr (MN_HoA, dst=CN) Payload you just need sufficient trust to run IPsec with the CN. > If IPsec is used with RO, I don't remember > what the specs say, but that doesn't currently matter much since > IPsec cannot really be used with RO until MOBIKE WG produces its > results. why? MIP signaling can be used to update the tunnel end points. Vijay From owner-multi6@ops.ietf.org Wed Jul 28 01:04: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 BAA05496 for ; Wed, 28 Jul 2004 01:04:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bpgab-000Jkl-FJ for multi6-data@psg.com; Wed, 28 Jul 2004 05:02:53 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bpgaa-000JkQ-B9 for multi6@ops.ietf.org; Wed, 28 Jul 2004 05:02:52 +0000 Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id BE2858; Wed, 28 Jul 2004 08:02:49 +0300 (EEST) In-Reply-To: <4106F643.60307@iprg.nokia.com> References: <947A318C-DEE5-11D8-9324-000393CE1E8C@nomadiclab.com> <3F21260E-DFBE-11D8-98BA-000A95CD987A@muada.com> <7C1BBC77-DFBF-11D8-9324-000393CE1E8C@nomadicla <4106F643.60307@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5EE1BE33-E053-11D8-9324-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List , Iljitsch van Beijnum From: Pekka Nikander Subject: Re: Unique identifiers and privacy Date: Wed, 28 Jul 2004 08:02:48 +0300 To: Vijay Devarapalli X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 >> For route optimisation, it is not encrypted, as IPsec is typically >> not used in the RO case. > > you can use it if you want to. > >> If IPsec is used with RO, I don't remember >> what the specs say, but that doesn't currently matter much since >> IPsec cannot really be used with RO until MOBIKE WG produces its >> results. > > why? MIP signaling can be used to update the tunnel end points. I realised I was wrong some time after I sent my second message. Sorry for the confusion. Anyway, this discussion does not belong to this list as it has nothing to do with multi6. --Pekka From owner-multi6@ops.ietf.org Wed Jul 28 23:50: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 XAA28293 for ; Wed, 28 Jul 2004 23:50:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq1tY-000IBM-00 for multi6-data@psg.com; Thu, 29 Jul 2004 03:47:52 +0000 Received: from [216.148.227.85] (helo=rwcrmhc12.comcast.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq1tN-000I9U-BN for multi6@ops.ietf.org; Thu, 29 Jul 2004 03:47:41 +0000 Received: from dfnjgl21 (c-24-1-99-5.client.comcast.net[24.1.99.5]) by comcast.net (rwcrmhc12) with SMTP id <2004072903324001400rjbnle> (Authid: sdawkins@comcast.net); Thu, 29 Jul 2004 03:32:40 +0000 Message-ID: <3c5401c4751c$d1ef6e00$0200a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6" References: <200407091529.LAA05687@ietf.org> <4104AF95.8040608@zurich.ibm.com> Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt Date: Wed, 28 Jul 2004 22:33:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 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 Maybe it's too close to San Diego for e-mail to make sense to me, but ... From: "Brian E Carpenter" To: "Multi6" Sent: Monday, July 26, 2004 2:15 AM Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt > > 3. I am also uncomfortable about "the bit." The whole of section 6 is, well, > a bit kludgy. The only clean solution IMHO is a shim header, which knocks > 8 bytes off the user's MTU. In the catgeory of possible alternatives, we could > in theory add > - encode a couple of bits in the flow label > - get back the ECN bits Huh? Does this mean (1) we bag ECN in general, (2) we bag ECN for multihoming and hope no one gets confused about interpreting overloaded bits, or (3) we're totally confusing Spencer? The rest of Brian's note made sense to me, I just couldn't parse this part. Thanks, Spencer From owner-multi6@ops.ietf.org Thu Jul 29 06:57: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 GAA02235 for ; Thu, 29 Jul 2004 06:57:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq8a6-000NGE-7T for multi6-data@psg.com; Thu, 29 Jul 2004 10:56:14 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq8Zu-000NEb-Hh for multi6@ops.ietf.org; Thu, 29 Jul 2004 10:56:02 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6TAuqSq088580; Thu, 29 Jul 2004 12:56:52 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: API, was: Question re HIP dependency & some architectural considerations Date: Thu, 29 Jul 2004 12:55:41 +0200 To: Pekka Nikander X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 26-jul-04, at 12:38, Pekka Nikander wrote: > b) Secondly, it starts to look like that we really should start to > think about the API issues more seriously. Yes. Hence the call for apps feedback earlier. > Looking at the multi6 goals and recent discussion, it looks like that > any acceptable solutions MUST support unmodified IPv6 API, using > routable IPv6 addresses as API level identifiers. Only that way we > can fully support all existing applications. Unfortunately, this way we also perpetuate the brokenness of the current API philosophy. What I'd like to see is a dual track approach: we do what we can to support multihoming for existing IPv6 applications, and we also create new, less limited ways to do the same and more. By also allowing identifiers that aren't routable IPv6 addresses, our stuff is much more powerful and futureproof. This means we need some more type fields and make some more stuff variable length, but that's not very hard. However, security is harder for nonroutable identifiers. I don't think we necessarily want to solve that, but if we can create hooks for solving this in user space then this is quite easy to add later on. (The same way that IPsec needs kernel support for some of its stuff but the Racoon IKE daemon is basically a user-level process.) > To me, it remains an interesting question how to support API evolution. > One architectural possibility would be to use HIP as an example: > - convert AIDs into EIDs at the API level I forget what the A and E stand for... > This using of internal > EIDs that are not IP addresses in the protocol layer seems to > offer an evolution path for the API. Another level of indirection? I don't think that's the solution. The problem is that applications see values that they think are IP adddresses. The first order of business is removing the assumption that these are actual IP addresses. This can't be done by adding stuff lower in the stack. > c) Thirdly, but perhaps less importantly, it looks like that we should > also take an architectural stance at the performance implications. > Some people seem to have an opinion that requiring one to perform an > authenticating D-H exchange each and every time one wants to use > multi-homing is unacceptable. Please define "use multihoming". If this means once when ISPs are connected or once a day or something like that, that's very different from having to do it for every TCP session. > But is it really so? If your application > needs the multi-homing benefits, doesn't that usually mean that it > expects to continue communication over some time span? The users want to control multihoming, having the application specifically ask for it is probably unworkable. > If so, does the less-than-second delay caused by authenticated D-H > really matter? Maybe yes, maybe no. I'm also worried about the CPU usage, BTW. At this juncture, I'll observe that we have T/TCP (TCP for transactions) which pretty much eliminates the delay caused by the TCP three way handshake, but T/TCP is often badly implemented, and, as far as I can tell, extremely rarely used. Same goes for HTTP session keepalive/reuse. > Related to this, it does look like that we could develop a protocol > where the hosts have a very light weight piggybacked exchange > initially, with reasonable initial security and the possibility to > "upgrade" the context security into authenticated D-H level. However, > such a protocol is inherently more complex than one where one > always performs authenticated D-H initially. I'm not worried about this kind of "complexity". Having a bunch of simple things is "complex" but workable. It's having a single thing that is hard to understand, or a buch of things that interact in complex ways that cause problems. > Hence, to me the question is whether the performance benefit from > the delayed state set up is really worth the added complexity, taking > the nature of multi-homed applications into consideration? How many different implementations of this kind of stuff are there going to be? 10? 25? 100? And how much time is the human race going to lose by having to wait for 50 ms for EVERY new session on EVERY computer for the next 20 years? It seems to be in vogue to publish half baked products and then clean up the mess later, but nobody ever got fired for getting it right the first time... -- The trouble with doing something right the first time is that nobody appreciates how difficult it was. - Walt West From owner-multi6@ops.ietf.org Thu Jul 29 07:32: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 HAA04470 for ; Thu, 29 Jul 2004 07:32:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1Bq98P-00010O-H3 for multi6-data@psg.com; Thu, 29 Jul 2004 11:31:41 +0000 Received: from [204.127.198.35] (helo=rwcrmhc11.comcast.net) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1Bq986-0000ys-Nn for multi6@ops.ietf.org; Thu, 29 Jul 2004 11:31:22 +0000 Received: from dfnjgl21 (c-24-1-99-5.client.comcast.net[24.1.99.5]) by comcast.net (rwcrmhc11) with SMTP id <20040729113122013003d9a8e> (Authid: sdawkins@comcast.net); Thu, 29 Jul 2004 11:31:22 +0000 Message-ID: <3c9901c4755f$b0c240c0$0200a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: "Multi6 List" References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> Subject: Re: API, was: Question re HIP dependency & some architectural considerations Date: Thu, 29 Jul 2004 06:32:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 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 Hi, Iljitsch My confusion remains constant across threads, apparently... > > At this juncture, I'll observe that we have T/TCP (TCP for > transactions) which pretty much eliminates the delay caused by the TCP > three way handshake, but T/TCP is often badly implemented, and, as far > as I can tell, extremely rarely used. Same goes for HTTP session > keepalive/reuse. Agree on T/TCP, confused on HTTP persistent connections. I'm just caught on "badly implemented and extremely rarely used". T/TCP was a brilliant idea that fell into the Grand Canyon of security - the lack of a three-way initialization handshake opened T/TCP up to sequence number guessing attacks. I don't have a mathematical proof of this, but the security community basically considered T/TCP impossible to secure. So, definitely, "extremely rarely used". My experience with HTTP browsers and servers is that early implementations had problems (off-by-one errors in object sizes that deadlocked transfers, bad interactions with HTTP/1.0 proxies that didn't support persistent connections), and after these problems were fixed, some server operators continued to run "Connection: close" mode to free up resources for new connections, but the biggest issue I've seen the last few years is that content may be spread across so many servers that browsers don't try to keep all the connections open. Got a pointer to other current problems? Spencer From owner-multi6@ops.ietf.org Thu Jul 29 08:46: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 IAA07821 for ; Thu, 29 Jul 2004 08:46:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqAHk-0009om-BG for multi6-data@psg.com; Thu, 29 Jul 2004 12:45:24 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqAHR-0009lP-Es for multi6@ops.ietf.org; Thu, 29 Jul 2004 12:45:05 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6TCk8Sq089850; Thu, 29 Jul 2004 14:46:12 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <3c9901c4755f$b0c240c0$0200a8c0@DFNJGL21> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> <3c9901c4755f$b0c240c0$0200a8c0@DFNJGL21> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <18ECAF48-E15D-11D8-9E0F-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: "Multi6 List" From: Iljitsch van Beijnum Subject: Re: API, was: Question re HIP dependency & some architectural considerations Date: Thu, 29 Jul 2004 14:44:57 +0200 To: "Spencer Dawkins" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 29-jul-04, at 13:32, Spencer Dawkins wrote: > Agree on T/TCP, confused on HTTP persistent connections. I'm just > caught on "badly implemented and extremely rarely used". I mainly meant that HTTP persistence is also rarely used, I'm not to sure about the details. As for T/TCP, don't know about the security problems (and don't care for the most part, it's not like I'm going to use T/TCP for BGP sessions or anything) but the Linux or BSD implementation (I forget which) basically treats T/TCP as a single datagram in both directions on steroids rather than regular TCP that establishes very quickly, thereby making it impossible to use T/TCP in practice for many applications. > Got a pointer to other current problems? In this area or in general? I just wish we could ditch IP altogether and start from scratch... From owner-multi6@ops.ietf.org Thu Jul 29 09:11: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 JAA09185 for ; Thu, 29 Jul 2004 09:11:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqAgZ-000EMW-83 for multi6-data@psg.com; Thu, 29 Jul 2004 13:11:03 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqAgN-000EKQ-UA for multi6@ops.ietf.org; Thu, 29 Jul 2004 13:10:52 +0000 Received: from [IPv6:::1] (teldanex-vpn.local.pnr.iki.fi [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 5EC818; Thu, 29 Jul 2004 16:10:50 +0300 (EEST) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Pekka Nikander Subject: Re: API, was: Question re HIP dependency & some architectural considerations Date: Thu, 29 Jul 2004 16:10:48 +0300 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 >> Looking at the multi6 goals and recent discussion, it looks like that >> any acceptable solutions MUST support unmodified IPv6 API, using >> routable IPv6 addresses as API level identifiers. Only that way we >> can fully support all existing applications. > > Unfortunately, this way we also perpetuate the brokenness of the > current > API philosophy. Note, Iljitsch, that I was only referring to existing applications. I didn't say anything about future or modified applications. That I took as a separate point. >> To me, it remains an interesting question how to support API >> evolution. >> One architectural possibility would be to use HIP as an example: >> - convert AIDs into EIDs at the API level > > I forget what the A and E stand for... A = Application, i.e., API level and inside applications E = End-point (in the sense that Noel Chiappa and/or NSRG use/used the term) >> This using of internal EIDs that are not IP addresses >> in the protocol layer seems to offer an evolution path for the API. > > Another level of indirection? Yes, two layers of indirection, in some sense. AID -> EID -> IP. In the initial case, for referrals etc, this is used so that at the beginning of a multi6 association, AID = IP. However, understanding that _conceptually_ AID and IP are different things paves way to API evolution, allowing one to change the nature of AIDs as the infrastructure evolves. > I don't think that's the solution. I don't know whether that is _the_ solution or not, and I am not arguing either for or against, in that sense. However, AFAIK, Tom et al at Boeing have implemented in their HIP code that particular strategy, and it works. Hence, it may be _a_ solution. It is to the WG to decide, later, what is _the_ solution. >> c) Thirdly, but perhaps less importantly, it looks like that we should >> also take an architectural stance at the performance implications. >> Some people seem to have an opinion that requiring one to perform an >> authenticating D-H exchange each and every time one wants to use >> multi-homing is unacceptable. > > Please define "use multihoming". To me (and I may well be wrong), it looks natural for wedge/layer 3.5 solutions to maintain a host-to-host (or end-point-to-end-point) state that is relatively independent on transport state. That is, such state is probably created on demand on first TCP connection (or SCTP or UDP or ...) and it stays around some time after all connections are known to be closed, just in case that there would be more communication. But, of course, that does not define "use multi-homing". With all respect, I refrain from defining it, as I was using it quite loosely, on purpose. >> If so, does the less-than-second delay caused by authenticated D-H >> really matter? > > Maybe yes, maybe no. I'm also worried about the CPU usage, BTW. I agree with you that for some busy servers the CPU load might be a concern. Otherwise, I wouldn't be too worried. Anyway, if you are using authenticated D-H and you are only worried about the relative security of your current session, you can choose to use fairly short keys. > The trouble with doing something right the first time is that nobody > appreciates how difficult it was. - Walt West Some people say that there there are two schools in CS in the US. One is the MIT way, "do the right thing". The other one is the UCB way, "just do it". I don't know whether the saying is true or not. In other words, I also see some value on incremental and partial solutions. Trying to do it right the first time, in a committee, may well be pretty impossible. --Pekka Nikander From owner-multi6@ops.ietf.org Thu Jul 29 09:20: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 JAA09789 for ; Thu, 29 Jul 2004 09:20:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqAox-000FIH-3D for multi6-data@psg.com; Thu, 29 Jul 2004 13:19:43 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqAom-000FHH-3O for multi6@ops.ietf.org; Thu, 29 Jul 2004 13:19:32 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6TDJTGP086174; Thu, 29 Jul 2004 13:19:29 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6TDJS7R187018; Thu, 29 Jul 2004 15:19:28 +0200 Received: from zurich.ibm.com (sig-9-145-143-46.de.ibm.com [9.145.143.46]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA77382; Thu, 29 Jul 2004 15:19:27 +0200 Message-ID: <4108F967.5060208@zurich.ibm.com> Date: Thu, 29 Jul 2004 15:19:35 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Spencer Dawkins CC: Multi6 Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt References: <200407091529.LAA05687@ietf.org> <4104AF95.8040608@zurich.ibm.com> <3c5401c4751c$d1ef6e00$0200a8c0@DFNJGL21> In-Reply-To: <3c5401c4751c$d1ef6e00$0200a8c0@DFNJGL21> 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.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 Spencer Dawkins wrote: > Maybe it's too close to San Diego for e-mail to make sense to me, but > ... > > From: "Brian E Carpenter" > To: "Multi6" > Sent: Monday, July 26, 2004 2:15 AM > Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt > > >>3. I am also uncomfortable about "the bit." The whole of section 6 > > is, well, > >>a bit kludgy. The only clean solution IMHO is a shim header, which > > knocks > >>8 bytes off the user's MTU. In the catgeory of possible > > alternatives, we could > >>in theory add >> - encode a couple of bits in the flow label >> - get back the ECN bits > > > Huh? Does this mean (1) we bag ECN in general, (2) we bag ECN for > multihoming and hope no one gets confused about interpreting > overloaded bits, or (3) we're totally confusing Spencer? I was being drastic: we persuade the IESG that ECN is a massive failure and have them reallocate the bits. (I'm not advocating this solution; I simply think we should list all options.) > The rest of Brian's note made sense to me This is very reassuring :-) Brian From owner-multi6@ops.ietf.org Thu Jul 29 09:41: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 JAA10953 for ; Thu, 29 Jul 2004 09:41:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqB9U-000Hef-VF for multi6-data@psg.com; Thu, 29 Jul 2004 13:40:56 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqB9J-000Hcd-FC for multi6@ops.ietf.org; Thu, 29 Jul 2004 13:40:46 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id i6TDeUFA118334; Thu, 29 Jul 2004 13:40:30 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i6TDeUUp066876; Thu, 29 Jul 2004 15:40:30 +0200 Received: from zurich.ibm.com (sig-9-145-143-46.de.ibm.com [9.145.143.46]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA79262; Thu, 29 Jul 2004 15:40:29 +0200 Message-ID: <4108FE54.3070009@zurich.ibm.com> Date: Thu, 29 Jul 2004 15:40:36 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Pekka Nikander , Multi6 List Subject: Re: API, was: Question re HIP dependency & some architectural considerations References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 Actually I think our terminology is tripping us up here. "Applications"? The network stack is rarely called by applications. It's called by network adaptation code built into "lower middleware" such as the Java run time system, whose job is to hide all this stuff from actual applications. That's an opportunity - because this lower middleware can be a super-shim that can do all kinds of smart things. "API" has the same confusing implication. We should be thinking about a more sophisticated network programming model, indeed, but calling it an API is likely to restrict our thinking too much. There is work going on in ICSC (IT-API, http://www.opengroup.org/icsc/) and DAT (uDAPL, http://www.datcollaborative.org/uDAPLv11.pdf) which shows that sockets are not sacred. However, like it or not, multi6 *does* have to deal with the real world of ULPs that call the current socket API. That may only be stage 1, but it has to work. Brian Iljitsch van Beijnum wrote: > On 26-jul-04, at 12:38, Pekka Nikander wrote: > >> b) Secondly, it starts to look like that we really should start to >> think about the API issues more seriously. > > > Yes. Hence the call for apps feedback earlier. > >> Looking at the multi6 goals and recent discussion, it looks like that >> any acceptable solutions MUST support unmodified IPv6 API, using >> routable IPv6 addresses as API level identifiers. Only that way we >> can fully support all existing applications. > > > Unfortunately, this way we also perpetuate the brokenness of the current > API philosophy. > > What I'd like to see is a dual track approach: we do what we can to > support multihoming for existing IPv6 applications, and we also create > new, less limited ways to do the same and more. > > By also allowing identifiers that aren't routable IPv6 addresses, our > stuff is much more powerful and futureproof. This means we need some > more type fields and make some more stuff variable length, but that's > not very hard. However, security is harder for nonroutable identifiers. > I don't think we necessarily want to solve that, but if we can create > hooks for solving this in user space then this is quite easy to add > later on. (The same way that IPsec needs kernel support for some of its > stuff but the Racoon IKE daemon is basically a user-level process.) > >> To me, it remains an interesting question how to support API evolution. >> One architectural possibility would be to use HIP as an example: >> - convert AIDs into EIDs at the API level > > > I forget what the A and E stand for... > >> This using of internal >> EIDs that are not IP addresses in the protocol layer seems to >> offer an evolution path for the API. > > > Another level of indirection? > > I don't think that's the solution. The problem is that applications see > values that they think are IP adddresses. The first order of business is > removing the assumption that these are actual IP addresses. This can't > be done by adding stuff lower in the stack. > >> c) Thirdly, but perhaps less importantly, it looks like that we should >> also take an architectural stance at the performance implications. >> Some people seem to have an opinion that requiring one to perform an >> authenticating D-H exchange each and every time one wants to use >> multi-homing is unacceptable. > > > Please define "use multihoming". If this means once when ISPs are > connected or once a day or something like that, that's very different > from having to do it for every TCP session. > >> But is it really so? If your application >> needs the multi-homing benefits, doesn't that usually mean that it >> expects to continue communication over some time span? > > > The users want to control multihoming, having the application > specifically ask for it is probably unworkable. > >> If so, does the less-than-second delay caused by authenticated D-H >> really matter? > > > Maybe yes, maybe no. I'm also worried about the CPU usage, BTW. > > At this juncture, I'll observe that we have T/TCP (TCP for transactions) > which pretty much eliminates the delay caused by the TCP three way > handshake, but T/TCP is often badly implemented, and, as far as I can > tell, extremely rarely used. Same goes for HTTP session keepalive/reuse. > >> Related to this, it does look like that we could develop a protocol >> where the hosts have a very light weight piggybacked exchange >> initially, with reasonable initial security and the possibility to >> "upgrade" the context security into authenticated D-H level. However, >> such a protocol is inherently more complex than one where one >> always performs authenticated D-H initially. > > > I'm not worried about this kind of "complexity". Having a bunch of > simple things is "complex" but workable. It's having a single thing that > is hard to understand, or a buch of things that interact in complex ways > that cause problems. > >> Hence, to me the question is whether the performance benefit from >> the delayed state set up is really worth the added complexity, taking >> the nature of multi-homed applications into consideration? > > > How many different implementations of this kind of stuff are there going > to be? 10? 25? 100? And how much time is the human race going to lose by > having to wait for 50 ms for EVERY new session on EVERY computer for the > next 20 years? > > It seems to be in vogue to publish half baked products and then clean up > the mess later, but nobody ever got fired for getting it right the first > time... > From owner-multi6@ops.ietf.org Thu Jul 29 10:27: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 KAA14846 for ; Thu, 29 Jul 2004 10:27:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqBr3-000N8K-L4 for multi6-data@psg.com; Thu, 29 Jul 2004 14:25:57 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqBqs-000N6E-Kq for multi6@ops.ietf.org; Thu, 29 Jul 2004 14:25:46 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2004 07:27:05 +0000 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i6TEPcsD014595; Thu, 29 Jul 2004 07:25:43 -0700 (PDT) Received: from [144.254.23.130] (dhcp-data-vlan10-23-130.cisco.com [144.254.23.130]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA12720; Thu, 29 Jul 2004 07:25:36 -0700 (PDT) Message-ID: <410908E6.9050502@cisco.com> Date: Thu, 29 Jul 2004 16:25:42 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum CC: Pekka Nikander , Multi6 List Subject: Re: API, was: Question re HIP dependency & some architectural considerations References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.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.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 Stepping out of the "things to think about" mode... The only reasonable approach at the API level is to provide a new API for any multihomed functionality that would be exposed to the host. You can't simply provide a "compatability API" if you change the identifier because the identifier has a semantic meaning to applications today that would be misinterpretted if we overloaded it. For example, think about a web log parser that attempts to do a reverse lookup on a HIP identifier as a case and point. Not so hot, right? Regards, Eliot Iljitsch van Beijnum wrote: > On 26-jul-04, at 12:38, Pekka Nikander wrote: > >> b) Secondly, it starts to look like that we really should start to >> think about the API issues more seriously. > > > Yes. Hence the call for apps feedback earlier. > >> Looking at the multi6 goals and recent discussion, it looks like that >> any acceptable solutions MUST support unmodified IPv6 API, using >> routable IPv6 addresses as API level identifiers. Only that way we >> can fully support all existing applications. > > > Unfortunately, this way we also perpetuate the brokenness of the current > API philosophy. > > What I'd like to see is a dual track approach: we do what we can to > support multihoming for existing IPv6 applications, and we also create > new, less limited ways to do the same and more. > > By also allowing identifiers that aren't routable IPv6 addresses, our > stuff is much more powerful and futureproof. This means we need some > more type fields and make some more stuff variable length, but that's > not very hard. However, security is harder for nonroutable identifiers. > I don't think we necessarily want to solve that, but if we can create > hooks for solving this in user space then this is quite easy to add > later on. (The same way that IPsec needs kernel support for some of its > stuff but the Racoon IKE daemon is basically a user-level process.) > >> To me, it remains an interesting question how to support API evolution. >> One architectural possibility would be to use HIP as an example: >> - convert AIDs into EIDs at the API level > > > I forget what the A and E stand for... > >> This using of internal >> EIDs that are not IP addresses in the protocol layer seems to >> offer an evolution path for the API. > > > Another level of indirection? > > I don't think that's the solution. The problem is that applications see > values that they think are IP adddresses. The first order of business is > removing the assumption that these are actual IP addresses. This can't > be done by adding stuff lower in the stack. > >> c) Thirdly, but perhaps less importantly, it looks like that we should >> also take an architectural stance at the performance implications. >> Some people seem to have an opinion that requiring one to perform an >> authenticating D-H exchange each and every time one wants to use >> multi-homing is unacceptable. > > > Please define "use multihoming". If this means once when ISPs are > connected or once a day or something like that, that's very different > from having to do it for every TCP session. > >> But is it really so? If your application >> needs the multi-homing benefits, doesn't that usually mean that it >> expects to continue communication over some time span? > > > The users want to control multihoming, having the application > specifically ask for it is probably unworkable. > >> If so, does the less-than-second delay caused by authenticated D-H >> really matter? > > > Maybe yes, maybe no. I'm also worried about the CPU usage, BTW. > > At this juncture, I'll observe that we have T/TCP (TCP for transactions) > which pretty much eliminates the delay caused by the TCP three way > handshake, but T/TCP is often badly implemented, and, as far as I can > tell, extremely rarely used. Same goes for HTTP session keepalive/reuse. > >> Related to this, it does look like that we could develop a protocol >> where the hosts have a very light weight piggybacked exchange >> initially, with reasonable initial security and the possibility to >> "upgrade" the context security into authenticated D-H level. However, >> such a protocol is inherently more complex than one where one >> always performs authenticated D-H initially. > > > I'm not worried about this kind of "complexity". Having a bunch of > simple things is "complex" but workable. It's having a single thing that > is hard to understand, or a buch of things that interact in complex ways > that cause problems. > >> Hence, to me the question is whether the performance benefit from >> the delayed state set up is really worth the added complexity, taking >> the nature of multi-homed applications into consideration? > > > How many different implementations of this kind of stuff are there going > to be? 10? 25? 100? And how much time is the human race going to lose by > having to wait for 50 ms for EVERY new session on EVERY computer for the > next 20 years? > > It seems to be in vogue to publish half baked products and then clean up > the mess later, but nobody ever got fired for getting it right the first > time... > From owner-multi6@ops.ietf.org Thu Jul 29 12:58:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24743 for ; Thu, 29 Jul 2004 12:58:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqEDU-000F4R-Jo for multi6-data@psg.com; Thu, 29 Jul 2004 16:57:16 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqEDJ-000F33-QX for multi6@ops.ietf.org; Thu, 29 Jul 2004 16:57:06 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6TGw5Sq092632; Thu, 29 Jul 2004 18:58:08 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4B526244-E180-11D8-9E0F-000A95CD987A@muada.com> Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: API, was: Question re HIP dependency & some architectural considerations Date: Thu, 29 Jul 2004 18:56:54 +0200 To: Pekka Nikander X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 29-jul-04, at 15:10, Pekka Nikander wrote: >> Please define "use multihoming". > To me (and I may well be wrong), it looks natural for wedge/layer 3.5 > solutions to maintain a host-to-host (or end-point-to-end-point) > state that is relatively independent on transport state. That is, > such state is probably created on demand on first TCP connection > (or SCTP or UDP or ...) and it stays around some time after all > connections are known to be closed, just in case that there would be > more communication. I think Marcelo has made it clear that something like this can only work securely when there is a strong binding between the identifier and the locators, if not the risk of long-time redirection is too big. But even in a scenario like this and not a per-session one, I'm not very comfortable with mandating extra initial delays if they are avoidable. (I believe they are in a routable identifier setup (where strong bindings aren't easy to come by) but not with unroutable identifiers (which need the strong binding anyway).) >> The trouble with doing something right the first time is that nobody >> appreciates how difficult it was. - Walt West > Some people say that there there are two schools in CS in the US. > One is the MIT way, "do the right thing". The other one is the > UCB way, "just do it". I don't know whether the saying is true or > not. > In other words, I also see some value on incremental and partial > solutions. Trying to do it right the first time, in a committee, > may well be pretty impossible. The thing is, if you try to do something perfect you're likely to fail, but if you try to do something imperfect you're likely to succeed. The questions is whether the failed result from the former is better than the successful result from the latter. There are very real costs involved with the additional steps in going back to add stuff later. There is no excuse for creating a standard with known and fixable (circumstances permitting) flaws, as this creates new legacy problems when the problems are fixed in a later version. From owner-multi6@ops.ietf.org Thu Jul 29 13:02: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 NAA25018 for ; Thu, 29 Jul 2004 13:02:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqEH7-000FgO-5H for multi6-data@psg.com; Thu, 29 Jul 2004 17:01:01 +0000 Received: from [83.149.65.1] (helo=sequoia.muada.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqEGo-000Fcb-Bt for multi6@ops.ietf.org; Thu, 29 Jul 2004 17:00:42 +0000 Received: from [127.0.0.1] (sequoia.muada.com [83.149.65.1]) by sequoia.muada.com (8.12.10/8.12.10) with ESMTP id i6TH1mSq092708; Thu, 29 Jul 2004 19:01:48 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <4108FE54.3070009@zurich.ibm.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0406072B@xch-nw-27.nw.nos.boeing.com> <40E7CAE6.5060503@zurich.ibm.com> <40FFCFCB.4010904@zurich.ibm.com> <4108FE54.3070009@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Multi6 List From: Iljitsch van Beijnum Subject: Re: API, was: Question re HIP dependency & some architectural considerations Date: Thu, 29 Jul 2004 19:00:36 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 On 29-jul-04, at 15:40, Brian E Carpenter wrote: > "Applications"? The network stack is rarely called by > applications. It's called by network adaptation code > built into "lower middleware" such as the Java run time > system, whose job is to hide all this stuff from actual > applications. Yes, Christian has brought up this point in the past as well. Still, looking up from layer 3 it doesn't matter much whether we have to be compatible with actual applications or Java run time environments and Win32 internals. (There is less of that stuff than actual applications which makes it a bit easier though.) > However, like it or not, multi6 *does* have to deal with > the real world of ULPs that call the current socket API. > That may only be stage 1, but it has to work. Agree. We need to think about stages 1+ too is all I'm saying. > Iljitsch van Beijnum wrote: Yes I know I wrote it earlier today. No need to repeat the whole thing. From owner-multi6@ops.ietf.org Fri Jul 30 00:23: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 AAA01581 for ; Fri, 30 Jul 2004 00:23:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqOsN-000KKA-4E for multi6-data@psg.com; Fri, 30 Jul 2004 04:20:11 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqOsC-000KHC-8D for multi6@ops.ietf.org; Fri, 30 Jul 2004 04:20:00 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6U4Jvm03471; Fri, 30 Jul 2004 07:19:57 +0300 (EET DST) X-Scanned: Fri, 30 Jul 2004 07:19:07 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i6U4J7CB008250; Fri, 30 Jul 2004 07:19:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00rC1IHg; Fri, 30 Jul 2004 07:19:05 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i6U4Ivn19511; Fri, 30 Jul 2004 07:18:57 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Jul 2004 07:18:57 +0300 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: API, was: Question re HIP dependency & some architectural considerations Date: Fri, 30 Jul 2004 07:18:56 +0300 Message-ID: Thread-Topic: API, was: Question re HIP dependency & some architectural considerations Thread-Index: AcR1beHGyYbhxwhBSFSMEKtHl5xulQAfg2mg From: To: , Cc: X-OriginalArrivalTime: 30 Jul 2004 04:18:57.0719 (UTC) FILETIME=[554F0470:01C475EC] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.63 Sender: owner-multi6@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka, Quick question on terminology: > A =3D Application, i.e., API level and inside applications > E =3D End-point (in the sense that Noel Chiappa and/or NSRG > use/used the term) Is the EID capable covering multiple IP addresses / interfaces? =20 For example, if I have device with WLAN & GPRS, which have connections to different ISPs so the interfaces have different addresses, does a single EID cover both IP addresses? I'm asking the above in a termonologic sense, not a technologic sense, as the technology may still need to be determined. thanks, John From owner-multi6@ops.ietf.org Fri Jul 30 00:47: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 AAA02551 for ; Fri, 30 Jul 2004 00:47:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqPI0-000N5Q-HA for multi6-data@psg.com; Fri, 30 Jul 2004 04:46:40 +0000 Received: from [212.68.5.99] (helo=n97.nomadiclab.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqPHp-000N3q-OP for multi6@ops.ietf.org; Fri, 30 Jul 2004 04:46:29 +0000 Received: from [IPv6:::1] (polle-vpn.local.pnr.iki.fi [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 573DD8; Fri, 30 Jul 2004 07:46:28 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6B6236E0-E1E3-11D8-9ABE-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: , From: Pekka Nikander Subject: Re: API, was: Question re HIP dependency & some architectural considerations Date: Fri, 30 Jul 2004 07:46:28 +0300 To: X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on 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 John, > Quick question on terminology: > >> A = Application, i.e., API level and inside applications >> E = End-point (in the sense that Noel Chiappa and/or NSRG >> use/used the term) > > Is the EID capable covering multiple IP addresses / interfaces? > For example, if I have device with WLAN & GPRS, which have connections > to different ISPs so the interfaces have different addresses, does > a single EID cover both IP addresses? Yes, it is capable of covering multiple IP addresses / interfaces. > I'm asking the above in a termonologic sense, not a technologic > sense, as the technology may still need to be determined. From http://users.exis.net/~jnc/tech/endpoints.txt: > An "endpoint" is thus defined as one participant of an end-end > communication; i.e. the fundamental agent of end-end communication. It > is the entity which is performing a reliable communication on an > end-end basis. --Pekka From owner-multi6@ops.ietf.org Fri Jul 30 02:48: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 CAA20957 for ; Fri, 30 Jul 2004 02:48:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqRAo-000BkG-Kk for multi6-data@psg.com; Fri, 30 Jul 2004 06:47:22 +0000 Received: from [192.18.98.34] (helo=brmea-mail-3.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqRAd-000Bir-Tr for multi6@ops.ietf.org; Fri, 30 Jul 2004 06:47:12 +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 i6U6l6il013363; Fri, 30 Jul 2004 00:47:06 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i6U6kwJR029400; Fri, 30 Jul 2004 08:47:00 +0200 (MEST) Date: Thu, 29 Jul 2004 23:47:22 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: how much privacy do we need? (was Re: Advantages and disadvantages of using CB64 type of identifiers To: marcelo bagnulo braun Cc: Erik Nordmark , Multi6 List , Iljitsch van Beijnum 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.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 [Catching up after vacation] > > But it is also hard for the wedge leayer to know the beginning and end > > of a session, which is also needed. For instance, an application > > session > > might silently assume that multiple TCP connections (to the same peer, > > or > > even to different peers) use the same IP address today to represent > > the host. > > As a result, if such an application isn't modified for multihoming > > somehow, > > it would assume that the same AID (application-visible identifier) is > > representing the host for that set of connections. > > > > Question: wouldn't this application also break when RFC3041 addresses > are used? in particular when a new temporary address is used There are two related aspects for "identity comparison" and "callbacks". For identity comparison i.e. when the responder wants to verify whether multiple communications are from the same initiator, then RFC 3041 will make this fail when the preferred lifetime expires for the old address (1 day by default). For callbacks, the use of RFC 3041 addresses will cause failure when the valid lifetime expires for the original address (7 days by default). But these time constants are quite different than e.g. using ephemeral IDs where each transport connection might use a different ID. > > For such a host to have multiple pseudonyms, this implies having > > multiple > > FQDNs. (Such as host-2002-8192-56bb-9258-0-0-8192-5882.example.com i.e. > > the FQDN doesn't have to provide any mnemonic meaning to a user.) > > ok, but in order to support RFC3041 addresses the host would need to > dynamically update the DNS (creating a new record for its new temporary > addresses), right? this would imply that multihomed hosts will need to > support Dyn DNs or something similar right? If you're using NOID-style DNS-based verification and want to take advantage of multihoming of the host's site, and at the same time use RFC 3041 address, then yes - the host needs to be able to update its forward DNS zone and create the reverse DNS entries somehow. Erik From owner-multi6@ops.ietf.org Fri Jul 30 18:53: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 SAA06954 for ; Fri, 30 Jul 2004 18:53:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1BqgE1-0004B3-SG for multi6-data@psg.com; Fri, 30 Jul 2004 22:51:41 +0000 Received: from [192.18.98.36] (helo=brmea-mail-4.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1BqgDr-00044q-8V for multi6@ops.ietf.org; Fri, 30 Jul 2004 22:51:31 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i6UMn953018334; Fri, 30 Jul 2004 16:49:10 -0600 (MDT) Received: from localhost (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i6UMpNJR011638; Sat, 31 Jul 2004 00:51:25 +0200 (MEST) Date: Fri, 30 Jul 2004 15:51:46 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: I-D ACTION:draft-nordmark-multi6-noid-02.txt To: Brian E Carpenter Cc: Multi6 In-Reply-To: "Your message with ID" <4104AF95.8040608@zurich.ibm.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.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 > 1. I am uncomfortable about the dependency on reverse DNS. It will > effectively mean that only well-run servers can benefit from mh, because > client systems with temporary addresses (especially RFC 3041 addresses) are > realistically unlikely to have reverse DNS in place. And that probably > eliminates mh for peer-to-peer applications too, which is a shame. FWIW I have the same concern. Given that the alteratives to using the DNS for verification have other downsides I think we should explore how to make a hybrid using techniques from HIP and WIMP to secure things when DNS is not usable. > 2. I'd have liked to see a walk-through for a 3rd-party referral case (i.e. > how would it work for p2p anyway?). Makes sense to add that to the draft. > 3. I am also uncomfortable about "the bit." The whole of section 6 is, well, > a bit kludgy. The only clean solution IMHO is a shim header, which knocks > 8 bytes off the user's MTU. In the catgeory of possible alternatives, we > could in theory add > - encode a couple of bits in the flow label > - get back the ECN bits > > (I'm not advocating either of these, but since the draft lists > alternatives...) I personally think an 8 byte extension header would be fine. (Re)using existing bits in the flow label or ECN for this isn't possible since you'd need some indication in the packet whether the new or the old use is intended, hence you need at least one bit somewhere else. Erik