From multimobsec-api-bounces@ietf.org Sat Apr 22 15:39:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXNxW-00064L-9H; Sat, 22 Apr 2006 15:39:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXNxU-00064F-QD for multimobsec-api@ietf.org; Sat, 22 Apr 2006 15:39:56 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXNxT-0001yQ-Fe for multimobsec-api@ietf.org; Sat, 22 Apr 2006 15:39:56 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id CB85A3020; Sat, 22 Apr 2006 22:39:54 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 293923020 for ; Sat, 22 Apr 2006 22:39:54 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3MJdrpm029157 for ; Sat, 22 Apr 2006 22:39:54 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Sat, 22 Apr 2006 22:39:53 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: multimobsec-api@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [MULTIMOBSEC-API] first steps in APIs X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org Welcome to multimobsec-api list! I hope the list name is somehow adequate and that I got all interested people subscribed. If you don't want to be on the list, you can unscribe from: https://www1.ietf.org/mailman/listinfo/multimobsec-api We had a meeting with Shinta and Marcelo since they happen to be in the same country and city as I at the moment. We discussed about some technical details and especially how to start collaborating. Initially, we though that we could have one "core" draft which includes only the things that are common for all working groups. In the end, we though that it might be better to have a core draft that describes all "peripheral" things like general locator management, failure and reachability detection. Things really specific to individual working groups could be described in separate extension drafts. If I recall correctly, Jari suggested starting the core draft in shim6 working group. It could be at least the initial home for the draft. We can use draft-komu-native-hip-api as a base for the draft, or start from the scratch. Both approaches are fine to me. Comments? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Sat Apr 22 20:04:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXS5A-0006Sk-PU; Sat, 22 Apr 2006 20:04:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXS59-0006Sf-0Q for multimobsec-api@ietf.org; Sat, 22 Apr 2006 20:04:07 -0400 Received: from cod.sandelman.ca ([192.139.46.139] helo=lists.sandelman.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXS57-0004UV-Ek for multimobsec-api@ietf.org; Sat, 22 Apr 2006 20:04:06 -0400 Received: from sandelman.ottawa.on.ca ([24.244.240.254]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k3N03vl22486 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sat, 22 Apr 2006 20:04:03 -0400 (EDT) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 1DF2D3AD9C for ; Sat, 22 Apr 2006 20:03:56 -0400 (EDT) To: multimobsec-api@ietf.org Subject: Re: [MULTIMOBSEC-API] first steps in APIs In-Reply-To: Message from Miika Komu of "Sat, 22 Apr 2006 22:39:53 +0300." References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Sat, 22 Apr 2006 20:03:55 -0400 Message-ID: <10723.1145750635@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Miika" == Miika Komu writes: Miika> Initially, we though that we could have one "core" draft Miika> which includes only the things that are common for all Miika> working groups. In the end, we though that it might be better Miika> to have a core draft that describes all "peripheral" things Miika> like general locator management, failure and reachability Miika> detection. Things really specific to individual working Miika> groups could be described in separate extension drafts. My impression is that we actually have two commonalities, not three. I.e. the venn diagram looks like: ***************** * * .------*-----. * | * | * |IPsec * HIP | shim6 * | * | * | * | * .------*-----. * * * ***************** What does shim6 have in common with IPsec over IPv4? This question is not an argument, but rather, a genuine question. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRErEaICLcPvd0N1lAQKe8ggAtDwNIAVxePSedHddtw9osLF4IdPfusdM f4ROgImN/hi4qcfsvoV7ViTVw2dBaoRWRHYvus4KSQOqcjk3n8qolrHa6zn1aCNH aK7LU9Wyd/IQRBhrH4rjWP0UHPd689QE6zr6DGS7oe9W8pjCylvAle+wqRfOYlhU dU9/lud/VpJw/B7mrMXdnQ1o7XfArYUKUC9NN+4PmV34JEg+3Cv0ah+jmlsVlEKU n0GhXLtadFIkwvsPfghv0CBk68TdwguObg1TPJ2HVyaO6iLztQs96cCYNWCHo9j0 v/DraWNWSfgtVw6JtzYD2+UBbIRAwSml9YbquyjRW9gagk/QL6oKtQ== =MnPt -----END PGP SIGNATURE----- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Mon Apr 24 06:39:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXyTN-0000HR-B8; Mon, 24 Apr 2006 06:39:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXyTL-0000HM-90 for multimobsec-api@ietf.org; Mon, 24 Apr 2006 06:39:15 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXyTK-0003N9-OM for multimobsec-api@ietf.org; Mon, 24 Apr 2006 06:39:15 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 87048212C59; Mon, 24 Apr 2006 13:39:05 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 1F55E212C44; Mon, 24 Apr 2006 13:39:05 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id A2077BDC40; Mon, 24 Apr 2006 13:39:04 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 6B040BDC38; Mon, 24 Apr 2006 13:39:04 +0300 (EEST) In-Reply-To: <10723.1145750635@sandelman.ottawa.on.ca> References: <10723.1145750635@sandelman.ottawa.on.ca> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MULTIMOBSEC-API] first steps in APIs Date: Mon, 24 Apr 2006 13:39:08 +0300 To: Michael Richardson X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org Hi, I guess that the identified commonalities are about some mechanisms=20 that are likely to be present in multiple scenarios. For instance, it seems likely that in hip and in shim6 there will be a=20= need to deal with multiple addresses/locators. So, there seem to be=20 somo common functios w.r.t. the managment of such addresses, like=20 learning the locator set (both the local and the peer) as well as the=20 currently used locator pair. Moreover, it seems interesting to let the=20= lower layer that is handling the locator inform the upper layer that a=20= new locator pair is being used. Another issue that seems to be common in several scenarios is about=20 reachability. First of all, it seems possible to re.use the failure=20 detection and path exploration mechanism defined in the shim6 protocol=20= in other protocols other than shim6 like, mipv6 or hip. Now, in this=20 case, it seems possible to define a certain set of fucntions to allow=20 the upper layer protocols to interact with this failure detection=20 mechanism, like tunning timers, defining the number of alternative=20 paths to be explored and so on. So bottom line is, the commonality comes from these two characteristics=20= that seems to be available in the differetn scenarios: - there are multiple addresses that need to be managed - a mechanism for failure detection and path exploration is used by the=20= different protocols and it needs to be tuned/managed The functions related to such functions can be made common to all the=20 protocols. Makes any sense? regards, marcelo El 23/04/2006, a las 3:03, Michael Richardson escribi=F3: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Miika" =3D=3D Miika Komu writes: > Miika> Initially, we though that we could have one "core" draft > Miika> which includes only the things that are common for all > Miika> working groups. In the end, we though that it might be=20 > better > Miika> to have a core draft that describes all "peripheral" things > Miika> like general locator management, failure and reachability > Miika> detection. Things really specific to individual working > Miika> groups could be described in separate extension drafts. > > My impression is that we actually have two commonalities, not three. > I.e. the venn diagram looks like: > > > ***************** > * * > .------*-----. * > | * | * > |IPsec * HIP | shim6 * > | * | * > | * | * > .------*-----. * > * * > ***************** > > > What does shim6 have in common with IPsec over IPv4? > This question is not an argument, but rather, a genuine question. > > - -- > ] ON HUMILITY: to err is human. To moo, bovine. | =20 > firewalls [ > ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net=20= > architect[ > ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/=20 > |device driver[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, security=20= > guy"); [ > > "The Microsoft _Get the Facts CD_ does not work on Linux." -=20 > orospakr > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBRErEaICLcPvd0N1lAQKe8ggAtDwNIAVxePSedHddtw9osLF4IdPfusdM > f4ROgImN/hi4qcfsvoV7ViTVw2dBaoRWRHYvus4KSQOqcjk3n8qolrHa6zn1aCNH > aK7LU9Wyd/IQRBhrH4rjWP0UHPd689QE6zr6DGS7oe9W8pjCylvAle+wqRfOYlhU > dU9/lud/VpJw/B7mrMXdnQ1o7XfArYUKUC9NN+4PmV34JEg+3Cv0ah+jmlsVlEKU > n0GhXLtadFIkwvsPfghv0CBk68TdwguObg1TPJ2HVyaO6iLztQs96cCYNWCHo9j0 > v/DraWNWSfgtVw6JtzYD2+UBbIRAwSml9YbquyjRW9gagk/QL6oKtQ=3D=3D > =3DMnPt > -----END PGP SIGNATURE----- > > _______________________________________________ > MULTIMOBSEC-API mailing list > MULTIMOBSEC-API@ietf.org > https://www1.ietf.org/mailman/listinfo/multimobsec-api > _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Mon Apr 24 16:33:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7kJ-0002NV-8V; Mon, 24 Apr 2006 16:33:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7kI-0002NQ-0J for multimobsec-api@ietf.org; Mon, 24 Apr 2006 16:33:22 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY7kD-0000dU-MW for multimobsec-api@ietf.org; Mon, 24 Apr 2006 16:33:21 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id CA7F231DF; Mon, 24 Apr 2006 23:33:16 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5F4B22FBA; Mon, 24 Apr 2006 23:33:16 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3OKXDwC026761; Mon, 24 Apr 2006 23:33:16 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Mon, 24 Apr 2006 23:33:13 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Michael Richardson Subject: Re: [MULTIMOBSEC-API] first steps in APIs In-Reply-To: <10723.1145750635@sandelman.ottawa.on.ca> Message-ID: References: <10723.1145750635@sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Sat, 22 Apr 2006, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "Miika" == Miika Komu writes: > Miika> Initially, we though that we could have one "core" draft > Miika> which includes only the things that are common for all > Miika> working groups. In the end, we though that it might be better > Miika> to have a core draft that describes all "peripheral" things > Miika> like general locator management, failure and reachability > Miika> detection. Things really specific to individual working > Miika> groups could be described in separate extension drafts. > > My impression is that we actually have two commonalities, not three. > I.e. the venn diagram looks like: > > > ***************** > * * > .------*-----. * > | * | * > |IPsec * HIP | shim6 * > | * | * > | * | * > .------*-----. * > * * > ***************** > > > What does shim6 have in common with IPsec over IPv4? > This question is not an argument, but rather, a genuine question. (Probably very little.) -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Mon Apr 24 17:16:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8QH-00005n-B3; Mon, 24 Apr 2006 17:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8QH-00005i-33 for multimobsec-api@ietf.org; Mon, 24 Apr 2006 17:16:45 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8QF-0003Dk-Pq for multimobsec-api@ietf.org; Mon, 24 Apr 2006 17:16:45 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 450803105; Tue, 25 Apr 2006 00:16:43 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id D8831300A; Tue, 25 Apr 2006 00:16:42 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3OLGgWf028166; Tue, 25 Apr 2006 00:16:42 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Tue, 25 Apr 2006 00:16:42 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: marcelo bagnulo braun Subject: Re: [MULTIMOBSEC-API] first steps in APIs In-Reply-To: <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> Message-ID: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Mon, 24 Apr 2006, marcelo bagnulo braun wrote: > So bottom line is, the commonality comes from these two characteristics that > seems to be available in the differetn scenarios: > > - there are multiple addresses that need to be managed > - a mechanism for failure detection and path exploration is used by the > different protocols and it needs to be tuned/managed > > The functions related to such functions can be made common to all the > protocols. > > Makes any sense? Yes it does, at least HIP wise. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Mon Apr 24 17:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8we-0007j1-VJ; Mon, 24 Apr 2006 17:50:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY8wd-0007iw-OR for multimobsec-api@ietf.org; Mon, 24 Apr 2006 17:50:11 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY8wZ-0005Fh-4K for multimobsec-api@ietf.org; Mon, 24 Apr 2006 17:50:11 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FY8wU-0002th-8X for multimobsec-api@ietf.org; Mon, 24 Apr 2006 23:50:02 +0200 Received: from 206.219.197.100 ([206.219.197.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Apr 2006 23:50:02 +0200 Received: from mcr by 206.219.197.100 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 24 Apr 2006 23:50:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: multimobsec-api@ietf.org From: Michael Richardson Date: Mon, 24 Apr 2006 17:19:58 -0400 Lines: 43 Message-ID: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> Mime-Version: 1.0 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 206.219.197.100 User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) Cancel-Lock: sha1:+B6DrkDgPCSZYUDPqxjllCzbgv0= X-Spam-Score: 1.6 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: anonsec@postel.org Subject: [MULTIMOBSEC-API] Re: first steps in APIs X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1688800005==" Errors-To: multimobsec-api-bounces@ietf.org --===============1688800005== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= >>>>> "marcelo" == marcelo bagnulo braun writes: marcelo> So bottom line is, the commonality comes from these two marcelo> characteristics that seems to be available in the differetn marcelo> scenarios: marcelo> - there are multiple addresses that need to be managed - a marcelo> mechanism for failure detection and path exploration is used by marcelo> the different protocols and it needs to be tuned/managed marcelo> The functions related to such functions can be made common to marcelo> all the protocols. marcelo> Makes any sense? So do you feel that there is any overlap between shim6 and IPsec? I think we have two APIs here. And that's fine -- decoupling is good. The HIP folks have to coordinate twice, but we don't have to come to a consensus among three groups. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUARE1BBICLcPvd0N1lAQJorggApm0Uc5hqas50dKHsew3KLhSJzdj76zJa eRixRaIDNk8oygw61fpYc5tGEFgoKq6QPNjZsMz9GGr8qtgzCQvkyMhheF/xaRnw pcw6jDWq/egv8MjBMJLK5sUS25m66ml072bFrQHLUL0R0V3Dc79L8Z+ho/dJJjmy 9BuPaLZE2sXbomw20jUDdzIUwJKOum3F+DgYc6QbTtZs4btEusCS9NMYg+B64vN+ s34xtafbHAFxaDfGGSku+k88AdGQDeLuN3uZLMoBYtZ5+Ub1hK+6g6hg8gCKdtXO GP5GxEoCdWLuqskFYrtkOZQCpH3FyV96zM7XGbAjqimbgsyajcRpfA== =LmP8 -----END PGP SIGNATURE----- --=-=-=-- --===============1688800005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api --===============1688800005==-- From multimobsec-api-bounces@ietf.org Tue Apr 25 02:08:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYGia-00045C-Ja; Tue, 25 Apr 2006 02:08:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYGiZ-000457-9o for multimobsec-api@ietf.org; Tue, 25 Apr 2006 02:08:11 -0400 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYGiX-0003np-U0 for multimobsec-api@ietf.org; Tue, 25 Apr 2006 02:08:11 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A2F9F4D876; Tue, 25 Apr 2006 15:08:05 +0900 (JST) Date: Tue, 25 Apr 2006 09:08:04 +0300 From: Shinta Sugimoto To: Michael Richardson Subject: Re: [MULTIMOBSEC-API] first steps in APIs In-Reply-To: <10723.1145750635@sandelman.ottawa.on.ca> References: <10723.1145750635@sandelman.ottawa.on.ca> Message-Id: <20060425090109.12AA.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org Hello Michael, On Sat, 22 Apr 2006 20:03:55 -0400 Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > >>>>> "Miika" == Miika Komu writes: > Miika> Initially, we though that we could have one "core" draft > Miika> which includes only the things that are common for all > Miika> working groups. In the end, we though that it might be better > Miika> to have a core draft that describes all "peripheral" things > Miika> like general locator management, failure and reachability > Miika> detection. Things really specific to individual working > Miika> groups could be described in separate extension drafts. > > My impression is that we actually have two commonalities, not three. > I.e. the venn diagram looks like: > > > ***************** > * * > .------*-----. * > | * | * > |IPsec * HIP | shim6 * > | * | * > | * | * > .------*-----. * > * * > ***************** > > > What does shim6 have in common with IPsec over IPv4? > This question is not an argument, but rather, a genuine question. As you pointed out, currently SHIM6 only handles IPv6 addresses in its locator management. But in the future, it could also support IPv4 locator as well. It is addressed in Section 1.3 of Erik Nordmark's draft . So, there is not need to exclude IPv4 locator management from the common part, I think. Regards, Shinta _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 02:09:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYGkC-0004Lc-1k; Tue, 25 Apr 2006 02:09:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYGkA-0004LX-Bw for multimobsec-api@ietf.org; Tue, 25 Apr 2006 02:09:50 -0400 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYGk8-0003qx-Qj for multimobsec-api@ietf.org; Tue, 25 Apr 2006 02:09:50 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 925E84D924; Tue, 25 Apr 2006 15:09:46 +0900 (JST) Date: Tue, 25 Apr 2006 09:09:45 +0300 From: Shinta Sugimoto To: marcelo bagnulo braun Subject: Re: [MULTIMOBSEC-API] first steps in APIs In-Reply-To: <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> Message-Id: <20060425090850.12AD.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Michael Richardson , multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org Hi, On Mon, 24 Apr 2006 13:39:08 +0300 marcelo bagnulo braun wrote: > Hi, > > I guess that the identified commonalities are about some mechanisms > that are likely to be present in multiple scenarios. > For instance, it seems likely that in hip and in shim6 there will be a > need to deal with multiple addresses/locators. So, there seem to be > somo common functios w.r.t. the managment of such addresses, like > learning the locator set (both the local and the peer) as well as the > currently used locator pair. Moreover, it seems interesting to let the > lower layer that is handling the locator inform the upper layer that a > new locator pair is being used. > > Another issue that seems to be common in several scenarios is about > reachability. First of all, it seems possible to re.use the failure > detection and path exploration mechanism defined in the shim6 protocol > in other protocols other than shim6 like, mipv6 or hip. Now, in this > case, it seems possible to define a certain set of fucntions to allow > the upper layer protocols to interact with this failure detection > mechanism, like tunning timers, defining the number of alternative > paths to be explored and so on. > > > So bottom line is, the commonality comes from these two characteristics > that seems to be available in the differetn scenarios: > > - there are multiple addresses that need to be managed > - a mechanism for failure detection and path exploration is used by the > different protocols and it needs to be tuned/managed > > The functions related to such functions can be made common to all the > protocols. > > Makes any sense? yes, makes sense to me too. Regards, Shinta _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 02:26:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYH0b-0000gn-AG; Tue, 25 Apr 2006 02:26:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYH0a-0000gd-0u for multimobsec-api@ietf.org; Tue, 25 Apr 2006 02:26:48 -0400 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYH0Z-0004Gu-Ke for multimobsec-api@ietf.org; Tue, 25 Apr 2006 02:26:47 -0400 Received: from [193.234.219.165] (w165.nomadiclab.com [193.234.219.165]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 522AB4D924; Tue, 25 Apr 2006 15:26:44 +0900 (JST) Date: Tue, 25 Apr 2006 09:26:43 +0300 From: Shinta Sugimoto To: Miika Komu Subject: Re: [MULTIMOBSEC-API] first steps in APIs In-Reply-To: References: Message-Id: <20060425091028.12B0.SHINTA@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org Hi Miika, Sorry for replying lately. Please find my comments below. On Sat, 22 Apr 2006 22:39:53 +0300 (EEST) Miika Komu wrote: > Welcome to multimobsec-api list! I hope the list name is somehow adequate > and that I got all interested people subscribed. If you don't want to be > on the list, you can unscribe from: > > https://www1.ietf.org/mailman/listinfo/multimobsec-api > > We had a meeting with Shinta and Marcelo since they happen to be in the > same country and city as I at the moment. We discussed about some > technical details and especially how to start collaborating. > > Initially, we though that we could have one "core" draft which includes > only the things that are common for all working groups. In the end, we > though that it might be better to have a core draft that describes all > "peripheral" things like general locator management, failure and > reachability detection. Things really specific to individual working > groups could be described in separate extension drafts. > > If I recall correctly, Jari suggested starting the core draft in shim6 > working group. It could be at least the initial home for the draft. > > We can use draft-komu-native-hip-api as a base for the draft, or start > from the scratch. Both approaches are fine to me. > > Comments? Given common understanding that "common part" would be the locator mangement, failure detection and reachability exploration, we may need to start from scratch. If I understand it correctly, HIP native API is mainly about providing endpoint descriptor for application to make it more HIP-friendly way. So I am afraid that the main focus is different from the common API stuff. Regards, Shinta _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 02:42:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYHG4-0004hh-AI; Tue, 25 Apr 2006 02:42:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYHG3-0004fk-Dz for multimobsec-api@ietf.org; Tue, 25 Apr 2006 02:42:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYHG3-0004fE-6L for multimobsec-api@ietf.org; Tue, 25 Apr 2006 02:42:47 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYHFw-0004zr-VR for multimobsec-api@ietf.org; Tue, 25 Apr 2006 02:42:44 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3DB92212C5F; Tue, 25 Apr 2006 09:42:34 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id CACF4212C59; Tue, 25 Apr 2006 09:42:33 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 8FD9BBDC40; Tue, 25 Apr 2006 09:42:33 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 5AE08BDC38; Tue, 25 Apr 2006 09:42:33 +0300 (EEST) In-Reply-To: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MULTIMOBSEC-API] Re: first steps in APIs Date: Tue, 25 Apr 2006 09:42:38 +0300 To: Michael Richardson X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.6 (--) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org El 25/04/2006, a las 0:19, Michael Richardson escribi=F3: > >>>>>> "marcelo" =3D=3D marcelo bagnulo braun = writes: > marcelo> So bottom line is, the commonality comes from these two > marcelo> characteristics that seems to be available in the=20 > differetn > marcelo> scenarios: > > marcelo> - there are multiple addresses that need to be managed - = a > marcelo> mechanism for failure detection and path exploration is=20= > used by > marcelo> the different protocols and it needs to be tuned/managed > > marcelo> The functions related to such functions can be made=20 > common to > marcelo> all the protocols. > > marcelo> Makes any sense? > > So do you feel that there is any overlap between shim6 and IPsec? > I think we have two APIs here. > I don't know... what about MOBIKE? wouldn't mobike need similar locator management and=20= failure detection functions? what about MIP? (with the HA) in this case we would need to manage=20 multiple locators and deal with failure detection over the IPSec tunnel=20= with the HA... but again, i don't really know just exploring regards, marcelo > And that's fine -- decoupling is good. > The HIP folks have to coordinate twice, but we don't have to come to=20= > a > consensus among three groups. > > > > > _______________________________________________ > MULTIMOBSEC-API mailing list > MULTIMOBSEC-API@ietf.org > https://www1.ietf.org/mailman/listinfo/multimobsec-api _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 03:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYI2k-00044n-7S; Tue, 25 Apr 2006 03:33:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYI2j-0003z5-0t for multimobsec-api@ietf.org; Tue, 25 Apr 2006 03:33:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYI2i-0006Qf-Uu for multimobsec-api@ietf.org; Tue, 25 Apr 2006 03:33:04 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYHXb-00058L-TC for multimobsec-api@ietf.org; Tue, 25 Apr 2006 03:00:57 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 282763258; Tue, 25 Apr 2006 10:00:55 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A9DC131D4; Tue, 25 Apr 2006 10:00:54 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3P70p4u008076; Tue, 25 Apr 2006 10:00:54 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Tue, 25 Apr 2006 10:00:51 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: marcelo bagnulo braun Subject: Re: [MULTIMOBSEC-API] Re: first steps in APIs In-Reply-To: <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Message-ID: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.6 (--) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, 25 Apr 2006, marcelo bagnulo braun wrote: > I don't know... I think there is some overlap even between shim6 and btns, but the overlap is somewhat marginal. Consider these examples: * You could request current IPsec security parameters from shim6 module and it would tell you that there is none * To set-up BTNS IPsec policies and associations, you also need locators However, there is no reason why these APIs couldn't be decoupled. > what about MOBIKE? wouldn't mobike need similar locator management and > failure detection functions? > > what about MIP? (with the HA) in this case we would need to manage > multiple locators and deal with failure detection over the IPSec tunnel > with the HA... > > but again, i don't really know just exploring There is some overlap, but I think it is possible to abstract it. HIP is the common denominator, so HIP people need to make sure that the "gray area" is covered in the drafts. In any case, it would be very useful for everyone to review all drafts with a close attention what their working group wants from the APIs. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 05:13:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYJc3-0000IE-7U; Tue, 25 Apr 2006 05:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYJc1-0000I9-1V for multimobsec-api@ietf.org; Tue, 25 Apr 2006 05:13:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYI2n-0006Qf-VX for multimobsec-api@ietf.org; Tue, 25 Apr 2006 03:33:10 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYHM6-000531-Cy for multimobsec-api@ietf.org; Tue, 25 Apr 2006 02:49:05 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 1A9B53331; Tue, 25 Apr 2006 09:49:01 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9E4853313; Tue, 25 Apr 2006 09:49:00 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3P6mufv007511; Tue, 25 Apr 2006 09:48:59 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Tue, 25 Apr 2006 09:48:56 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Michael Richardson In-Reply-To: Message-ID: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: -2.6 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: multimobsec-api@ietf.org, anonsec@postel.org Subject: [MULTIMOBSEC-API] Re: [anonsec] first steps in APIs X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Mon, 24 Apr 2006, Michael Richardson wrote: >>>>>> "marcelo" == marcelo bagnulo braun writes: > marcelo> So bottom line is, the commonality comes from these two > marcelo> characteristics that seems to be available in the differetn > marcelo> scenarios: > > marcelo> - there are multiple addresses that need to be managed - a > marcelo> mechanism for failure detection and path exploration is used by > marcelo> the different protocols and it needs to be tuned/managed > > marcelo> The functions related to such functions can be made common to > marcelo> all the protocols. > > marcelo> Makes any sense? > > So do you feel that there is any overlap between shim6 and IPsec? > I think we have two APIs here. > > And that's fine -- decoupling is good. > The HIP folks have to coordinate twice, but we don't have to come to a > consensus among three groups. So, it seeems like we would have two APIs: one for security (IPsec) and the other one for locators. We'd need consensus between BTNS-HIP and SHIM6-HIP. It might even make things easier. If we split things already at this point, it may not make sense to create "core" drafts. Otherwise, we may end up with too many documents (?): * locator core * SHIM6 locator extensions * HIP locator extensions * IPsec security core * BTNS security extensions * HIP security extensions On the other hand, this separation might be better for other lower layer protocols as well. Comments, opinions? -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 05:33:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYJuw-0005fx-8z; Tue, 25 Apr 2006 05:33:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYJuu-0005fs-Hn for multimobsec-api@ietf.org; Tue, 25 Apr 2006 05:33:08 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYJut-0004vu-1p for multimobsec-api@ietf.org; Tue, 25 Apr 2006 05:33:08 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 59429212C61; Tue, 25 Apr 2006 12:33:05 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id E6B61212C59; Tue, 25 Apr 2006 12:33:04 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id AC88EBDC40; Tue, 25 Apr 2006 12:33:04 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 77811BDC38; Tue, 25 Apr 2006 12:33:04 +0300 (EEST) In-Reply-To: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3480b9f0b0744a8fba1c40218ae8efb8@it.uc3m.es> Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Subject: Re: [MULTIMOBSEC-API] Re: [anonsec] first steps in APIs Date: Tue, 25 Apr 2006 12:33:10 +0300 To: Miika Komu X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org > > So, it seeems like we would have two APIs: one for security (IPsec) > and the other one for locators. We'd need consensus between BTNS-HIP > and SHIM6-HIP. It might even make things easier. > ok, i am not familiar with what BTNS is doing, but if you say so... > If we split things already at this point, it may not make sense to > create "core" drafts. Otherwise, we may end up with too many documents > (?): > > * locator core > * SHIM6 locator extensions > * HIP locator extensions > * IPsec security core > * BTNS security extensions > * HIP security extensions > i would add: * Reachability detection core * Reachability detection shim6 * Reachability detection HIP regards, marcelo > On the other hand, this separation might be better for other lower > layer protocols as well. Comments, opinions? > > -- > Miika Komu miika@iki.fi http://www.iki.fi/miika/ > > _______________________________________________ > MULTIMOBSEC-API mailing list > MULTIMOBSEC-API@ietf.org > https://www1.ietf.org/mailman/listinfo/multimobsec-api > _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 05:42:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYK3k-0007aN-9T; Tue, 25 Apr 2006 05:42:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYK3j-0007aI-5E for multimobsec-api@ietf.org; Tue, 25 Apr 2006 05:42:15 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYK3h-0005iz-L1 for multimobsec-api@ietf.org; Tue, 25 Apr 2006 05:42:15 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id EDA0C212C61; Tue, 25 Apr 2006 12:42:12 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8178E212C59; Tue, 25 Apr 2006 12:42:09 +0300 (EEST) In-Reply-To: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs Date: Tue, 25 Apr 2006 12:41:15 +0300 To: Miika Komu X-Mailer: Apple Mail (2.746.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org To me, one of the more important parts of this exercise is to see whether, from an application's point of view, one could more or less implement HIP-functionality with BTNS+CGA+SHIM6. In other words, my gut feeling is that that it would be good if HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff. --Pekka On Apr 25, 2006, at 10:00, Miika Komu wrote: > On Tue, 25 Apr 2006, marcelo bagnulo braun wrote: > >> I don't know... > > I think there is some overlap even between shim6 and btns, but the > overlap > is somewhat marginal. Consider these examples: > > * You could request current IPsec security parameters from shim6 > module > and it would tell you that there is none > * To set-up BTNS IPsec policies and associations, you also need > locators > > However, there is no reason why these APIs couldn't be decoupled. > >> what about MOBIKE? wouldn't mobike need similar locator management >> and >> failure detection functions? >> >> what about MIP? (with the HA) in this case we would need to manage >> multiple locators and deal with failure detection over the IPSec >> tunnel >> with the HA... >> >> but again, i don't really know just exploring > > There is some overlap, but I think it is possible to abstract it. > HIP is > the common denominator, so HIP people need to make sure that the "gray > area" is covered in the drafts. > > In any case, it would be very useful for everyone to review all drafts > with a close attention what their working group wants from the APIs. > > -- > Miika Komu miika@iki.fi http://www.iki.fi/miika/ > _______________________________________________ > _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 08:53:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYN2y-00053h-6a; Tue, 25 Apr 2006 08:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYN2w-00053c-Qn for multimobsec-api@ietf.org; Tue, 25 Apr 2006 08:53:38 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYN2v-000695-Go for multimobsec-api@ietf.org; Tue, 25 Apr 2006 08:53:38 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id CB579333A; Tue, 25 Apr 2006 15:53:36 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 4DAC3323B; Tue, 25 Apr 2006 15:53:36 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3PCrSPB027315; Tue, 25 Apr 2006 15:53:28 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Tue, 25 Apr 2006 15:53:27 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Pekka Nikander Subject: Re: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs In-Reply-To: Message-ID: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, 25 Apr 2006, Pekka Nikander wrote: > To me, one of the more important parts of this exercise is to see whether, > from an application's point of view, one could more or less implement > HIP-functionality with BTNS+CGA+SHIM6. In other words, my gut feeling is > that that it would be good if > > HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff. This would work for me. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 09:22:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNUb-00062Z-MJ; Tue, 25 Apr 2006 09:22:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNUa-00062T-6U for multimobsec-api@ietf.org; Tue, 25 Apr 2006 09:22:12 -0400 Received: from cod.sandelman.ca ([192.139.46.139] helo=lists.sandelman.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNUY-0008E6-Py for multimobsec-api@ietf.org; Tue, 25 Apr 2006 09:22:12 -0400 Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k3PDM1Z29613 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Tue, 25 Apr 2006 09:22:07 -0400 (EDT) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id E50FD3AD9C for ; Tue, 25 Apr 2006 09:22:00 -0400 (EDT) To: multimobsec-api@ietf.org Subject: Re: [MULTIMOBSEC-API] first steps in APIs In-Reply-To: Message from Shinta Sugimoto of "Tue, 25 Apr 2006 09:08:04 +0300." <20060425090109.12AA.SHINTA@sfc.wide.ad.jp> References: <10723.1145750635@sandelman.ottawa.on.ca> <20060425090109.12AA.SHINTA@sfc.wide.ad.jp> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Tue, 25 Apr 2006 09:22:00 -0400 Message-ID: <26345.1145971320@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Shinta" == Shinta Sugimoto writes: >> What does shim6 have in common with IPsec over IPv4? This >> question is not an argument, but rather, a genuine question. Shinta> As you pointed out, currently SHIM6 only handles IPv6 Shinta> addresses in its locator management. But in the future, it Shinta> could also support IPv4 locator as well. It is addressed in ... Shinta> So, there is not need to exclude IPv4 locator management Shinta> from the common part, I think. I still see an empty set with IPsec over IPv4, as we don't deal with locators at all. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRE4id4CLcPvd0N1lAQJvGAf/XhnmLna/v4s+09xmb7lvSqG7EZ8TEbzX Mlu9+7mdOzrPyDXaImkTFbs9EuLWmckuu8M9JtkBtMqe+KxcVNoTCeBIvurbWUji JzH4TYTvEYlDcIfOYbQMyAQN0JExJbsJUz9WLer3vfTkBvQ2VRMJlihobaShw5R3 ONQVN0NaljM1yco+/WM6+prLSFx+TeWh9HbGsaq7GWhjOeuUa32gSB4JFDZIyH3L Duamzte/2V0/ugIk6BgfGiqDHEJ2WuDhNxSPx0j71TNZnzxV/YHfV5TeIQeaZ6/2 GocGLGJHXThxdnvqqWOgSLCb3yvkFZd2cnRQMC+b+QyVKSlb/009QQ== =4vUB -----END PGP SIGNATURE----- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 09:25:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNXW-0007Hv-Kx; Tue, 25 Apr 2006 09:25:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNXU-0007Hq-R1 for multimobsec-api@ietf.org; Tue, 25 Apr 2006 09:25:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNXU-0008Lv-Os for multimobsec-api@ietf.org; Tue, 25 Apr 2006 09:25:12 -0400 Received: from cod.sandelman.ca ([192.139.46.139] helo=lists.sandelman.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYNXT-000172-Lj for multimobsec-api@ietf.org; Tue, 25 Apr 2006 09:25:12 -0400 Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id k3PDOwh29652 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 25 Apr 2006 09:25:04 -0400 (EDT) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 86CEB3AD9C; Tue, 25 Apr 2006 09:24:58 -0400 (EDT) To: marcelo bagnulo braun Subject: Re: [MULTIMOBSEC-API] Re: first steps in APIs In-Reply-To: Message from marcelo bagnulo braun of "Tue, 25 Apr 2006 09:42:38 +0300." <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Tue, 25 Apr 2006 09:24:58 -0400 Message-ID: <26520.1145971498@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: -2.6 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "marcelo" == marcelo bagnulo braun writes: marcelo> what about MOBIKE? wouldn't mobike need similar locator marcelo> management and failure detection functions? MOBIKE is about moving the outer part of an IPsec tunnel around. The addresses inside (the identifiers if you prefer), remain the same, so applications do not see any change. A MOBIKE daemon *itself* might benefit from the mechanisms provided by shim6 (if it were available for IPv4), but the end-user application would never see the changes. That's the purpose of MOBIKE. As for MIP, again, the point of the effort is to maintain the same set of identifiers for the application. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRE4jJoCLcPvd0N1lAQJiNgf+KwUNs2RdKnIat0zoc0cBQXLtwbHa27ds v78cuzEtG28uq9IQ0lGngSlcNqouGM4taIVOvThQ2jEs9GG/2pSYgXON1VNbj2nG N7A+wuDC0EI5i7Qim/d4TplwGcmbHcPL+zCslKBf+KtU/UsKQ3WuIFkiNgJnmGIZ W1paC9g00X0p1QFOLfwlvgFVctHPBE2THLv4pDFb5/r3j2z7iCL7wGvwqSw3rTKK lzQjKhsi7g72pPPXyAty6CzQ4iYcsBcCyaorgH7FJurxh6SBPxpE4yX8pMK6hn+N DstQvQJzXx5QAr9OKkQHeLNfa57cbZ0Nc0p53ZMwHBkKeBxMP+RuuQ== =mm+X -----END PGP SIGNATURE----- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 10:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYOAu-0008So-ND; Tue, 25 Apr 2006 10:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYO2D-0007oT-BK for multimobsec-api@ietf.org; Tue, 25 Apr 2006 09:56:57 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNoC-0000n6-6T for multimobsec-api@ietf.org; Tue, 25 Apr 2006 09:42:29 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id A0198333B; Tue, 25 Apr 2006 16:42:27 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 3EEAC30F9; Tue, 25 Apr 2006 16:42:27 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3PDgQHD000249; Tue, 25 Apr 2006 16:42:26 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Tue, 25 Apr 2006 16:42:26 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Michael Richardson Subject: Re: [MULTIMOBSEC-API] first steps in APIs In-Reply-To: <26345.1145971320@sandelman.ottawa.on.ca> Message-ID: References: <10723.1145750635@sandelman.ottawa.on.ca> <20060425090109.12AA.SHINTA@sfc.wide.ad.jp> <26345.1145971320@sandelman.ottawa.on.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, 25 Apr 2006, Michael Richardson wrote: > Shinta> So, there is not need to exclude IPv4 locator management > Shinta> from the common part, I think. > > I still see an empty set with IPsec over IPv4, as we don't deal with > locators at all. Perhaps I did not understand this properly. At least in BEET IPsec mode, you will have HITs in security policies and IP addresses (=locators) in security associations. Before packet leaves the host, the HITs are replaced with locators as specified in IPsec SPs and SAs. In addition, you can have a single security policy mapping to several security associations in IPv4 multihoming (or multi-SAing), HIP handles also the case where you have IPsec over IPv6 addresses. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 15:40:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTOU-0002Ef-Hs; Tue, 25 Apr 2006 15:40:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTOU-0002DL-0e for multimobsec-api@ietf.org; Tue, 25 Apr 2006 15:40:18 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYTOR-0002PO-H2 for multimobsec-api@ietf.org; Tue, 25 Apr 2006 15:40:17 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FYTOE-00005c-Nz for multimobsec-api@ietf.org; Tue, 25 Apr 2006 21:40:02 +0200 Received: from desk.marajade.sandelman.ca ([205.150.200.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Apr 2006 21:40:02 +0200 Received: from mcr by desk.marajade.sandelman.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Apr 2006 21:40:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: multimobsec-api@ietf.org From: Michael Richardson Date: Tue, 25 Apr 2006 15:29:55 -0400 Lines: 42 Message-ID: References: <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: desk.marajade.sandelman.ca User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) Cancel-Lock: sha1:0AyNeXOC1kbE/njEXV0Gepi+VBA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: anonsec@postel.org Subject: [MULTIMOBSEC-API] Re: btns-ipsec-apireq.txt X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org >>>>> "Miika" == Miika Komu writes: Miika> We have now three layers of identifiers now: Miika> * application layer: endpoint descriptor Miika> * transport layer: initial shim6 locator (ULP), or some kind of CGA (HIT) Miika> * network layer: current (shim6) locator So, in the IPsec space we have: a) principal - DN,SPKI Id,PGP identity,public key b) IKE layer - certificate/public key and/or hash of same. c) transport layer - ULP (could be HIT) d) IPsec layer - SPI# (SA bundle and pair) e) network layer - current (shim6) locator It is an explicit non-goal to provide access to (d). We already think we have access to (c) via current API. It is (b) and (a) that we are trying to get access to. Does this mean that there is in fact more commonality? Miika> So, I would say that we should return transport layer id in Miika> getsockname/getpeername, and use a separate API for the locators. Good. Principle of least surprise. Miika> Shinta is referring to case 1b with sendmsg and recmsg. However, Pekka Miika> said that it might be better to use some other function, perhaps something Miika> like NETLINK socket to receive this information. This way, data transfer Miika> would be decoupled better from locator/security related events. you need to have cmsg attached to sendmsg/recvmsg if you expect to support connectionless protocols. Each message may well have a different answer. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 15:45:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTTB-0003jk-6L; Tue, 25 Apr 2006 15:45:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTTA-0003je-Dy for multimobsec-api@ietf.org; Tue, 25 Apr 2006 15:45:08 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYTTA-0002iP-0w for multimobsec-api@ietf.org; Tue, 25 Apr 2006 15:45:08 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FYTT3-000115-PQ for multimobsec-api@ietf.org; Tue, 25 Apr 2006 21:45:01 +0200 Received: from desk.marajade.sandelman.ca ([205.150.200.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Apr 2006 21:45:01 +0200 Received: from mcr by desk.marajade.sandelman.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Apr 2006 21:45:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: multimobsec-api@ietf.org From: Michael Richardson Date: Tue, 25 Apr 2006 15:32:03 -0400 Lines: 38 Message-ID: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Mime-Version: 1.0 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: desk.marajade.sandelman.ca User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) Cancel-Lock: sha1:2IeLBEJF13geT+KzPCFAxvlreDU= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: anonsec@postel.org Subject: [MULTIMOBSEC-API] Re: [anonsec] Re: first steps in APIs X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1275625687==" Errors-To: multimobsec-api-bounces@ietf.org --===============1275625687== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= >>>>> "Pekka" == Pekka Nikander writes: Pekka> To me, one of the more important parts of this exercise is to see Pekka> whether, from an application's point of view, one could more or less Pekka> implement HIP-functionality with BTNS+CGA+SHIM6. In other words, my Pekka> gut feeling is that that it would be good if Pekka> HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff. So, you do not so much want us to find common pieces, but rather to delinate clearly where one starts and one ends. -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUARE55N4CLcPvd0N1lAQIKSAgAjuPbOKogAnMlhAbsMrzLtTSy7RfLsEo0 v8tTVI5e6jhE5s5XGcRtGu534oa0V91L7S/UKqJsyaR6hQ+fJnO9Zwc60iAACq8r F3ujjl+eUhLl8UDTIJgJQZfhYjmzV1HXeinbGBvq4X77UFIIj2OaAwt5J1fAXL3Q ydQtKAhWvc2Xw0UIVvet07KoXW56vbRyU41Xe93BUN60Km1O2valmF5icELcLAM0 wGkB6EXXQKpW61n7txNJLhf9iM10pqY7PGQyqeiB8EmdpigCQ4nwrbb50uQSWrrt d+5HvbeEGiaqzVmwrvUG7WdExYnVZmrmx9SmPPk5oCPVmn2m3UgrSQ== =MEZo -----END PGP SIGNATURE----- --=-=-=-- --===============1275625687== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api --===============1275625687==-- From multimobsec-api-bounces@ietf.org Tue Apr 25 16:39:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYUK4-00045j-As; Tue, 25 Apr 2006 16:39:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYUK2-00045e-NW for multimobsec-api@ietf.org; Tue, 25 Apr 2006 16:39:46 -0400 Received: from nwkea-mail-4.sun.com ([192.18.42.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYUK0-0006oD-8i for multimobsec-api@ietf.org; Tue, 25 Apr 2006 16:39:46 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k3PKdhUm021818 for ; Tue, 25 Apr 2006 13:39:43 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3PKdgca024454 for ; Tue, 25 Apr 2006 14:39:43 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PKdgCW005097 for ; Tue, 25 Apr 2006 15:39:42 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PKdgS1005096 for multimobsec-api@ietf.org; Tue, 25 Apr 2006 15:39:42 -0500 (CDT) Date: Tue, 25 Apr 2006 15:39:42 -0500 From: Nicolas Williams To: multimobsec-api@ietf.org Message-ID: <20060425203942.GQ4000@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [MULTIMOBSEC-API] List settings X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org This list got Cc'ed on a thread in a different IETF list, so when I reply I get these automated replies telling me that my posts need moderator approval, blah, blah, blah. Missing from these unhelpful e-mails: a URL where I could go subscribe. I found the subscription page in a few minutes, which brings up a second issue: I shouldn't have to subscribe just to post, particularly given that I subscribe to umpteen IETF lists. Not friendly list behaviour. Nico -- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 16:46:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYUQs-0006Up-Gk; Tue, 25 Apr 2006 16:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYUQr-0006Uk-NQ for multimobsec-api@ietf.org; Tue, 25 Apr 2006 16:46:49 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYUQr-0007FM-F8 for multimobsec-api@ietf.org; Tue, 25 Apr 2006 16:46:49 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3PKkn3i002651 for ; Tue, 25 Apr 2006 14:46:49 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3PKkmca027939 for ; Tue, 25 Apr 2006 14:46:48 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PKklZC005104 for ; Tue, 25 Apr 2006 15:46:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PKklak005103 for multimobsec-api@ietf.org; Tue, 25 Apr 2006 15:46:47 -0500 (CDT) Date: Tue, 25 Apr 2006 15:46:47 -0500 From: Nicolas Williams To: multimobsec-api@ietf.org Subject: Re: [MULTIMOBSEC-API] List settings Message-ID: <20060425204647.GR4000@binky.Central.Sun.COM> References: <20060425203942.GQ4000@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060425203942.GQ4000@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org Also, the mailman archive is password protected, but the list archive can be fetched via anonymous FTP. Worse: the mailman archive is day-by-day, so I have to click on each day one by one (the list has been up for four days). Please remove the password protection, it's pointless. Or fix the anon FTP situation. Please fix the archive -- it's very painful to use. Nico -- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Tue Apr 25 17:10:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYUne-00071Q-KZ; Tue, 25 Apr 2006 17:10:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYUne-00070M-6K for multimobsec-api@ietf.org; Tue, 25 Apr 2006 17:10:22 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYUnb-0008QO-OL for multimobsec-api@ietf.org; Tue, 25 Apr 2006 17:10:22 -0400 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FYUnK-0001lX-0W for multimobsec-api@ietf.org; Tue, 25 Apr 2006 23:10:02 +0200 Received: from desk.marajade.sandelman.ca ([205.150.200.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Apr 2006 23:10:01 +0200 Received: from mcr by desk.marajade.sandelman.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Apr 2006 23:10:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: multimobsec-api@ietf.org From: Michael Richardson Subject: Re: [MULTIMOBSEC-API] Re: first steps in APIs Date: Tue, 25 Apr 2006 17:05:43 -0400 Lines: 49 Message-ID: References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> <20060425152234.GN4000@binky.Central.Sun.COM> Mime-Version: 1.0 X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: desk.marajade.sandelman.ca User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) Cancel-Lock: sha1:hzTMgMD5s14/IvAvqKg0/jV4mD0= X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1640275274==" Errors-To: multimobsec-api-bounces@ietf.org --===============1640275274== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Yes, but I think there's a point where they may meet: at the API Nicolas> for obtaining the end-point IDs of a latched connection, and, Nicolas> therefore, the Nicolas> representation of these IDs (IKEv2-style representation, + BTNS Nicolas> publickey ID type, + HITs). When you receive a latched connection that was accepted due to BTNS, and the ID that was asserted in IKE was ID_IPV6 (recalling that BTNS made you not care that much about how valid it was for them to assert that), would you expect to see the end-point ID be: a) the IPV6 that was asserted via IKE. b) the HIT that the transport/shim6 layer asserted Aren't these two different things? Particularly when the IE in IKE was in fact FQDN or something. I can see applications that take a connection the first time, set up some kind of account, have the account validated by out-of-band method (e.g. the user paid for the service), and recall the public key used to sign on. Subsequent sign-ons are authenticated nicely by public alone. -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ "The Microsoft _Get the Facts CD_ does not work on Linux." - orospakr --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUARE6PK4CLcPvd0N1lAQK4MAf9HgzQuNjO7hCyK5hxpgqsYz7fJJ6aZ4+C VTz991b59kkEK+LWGv4PxKfnB4iStunR4C4LhFJe3cx2cdzvku5WwCQ7gIZdgYgN Jlk/OhdX+iPRRg8wdwq19ODUmHpyRLbvo4nFvGIu2Ae5UyiBbZ5yClFZlqkhdsX0 QDrer9dcy2SDpSydy2hwjozGstaQ2ImkoZD9LKkfl8syyn0kAWDETSlyUlp3KKVG 2Lmx6QIrkTE+mw09q/kG36guB7n1EY3uIB8vOyAUiHyX+Bci8U4fzYxcfCSM8Wuw 46WFhDty0IQ/d4X3l2rsATh5tfQnRfMMgYGmtYugBj04NAXKcfj6yA== =dn5d -----END PGP SIGNATURE----- --=-=-=-- --===============1640275274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api --===============1640275274==-- From multimobsec-api-bounces@ietf.org Tue Apr 25 17:15:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYUt2-00015q-FD; Tue, 25 Apr 2006 17:15:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYUt2-00015l-41 for multimobsec-api@ietf.org; Tue, 25 Apr 2006 17:15:56 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYUt0-0000DM-Fu for multimobsec-api@ietf.org; Tue, 25 Apr 2006 17:15:56 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3PLFr3i018906 for ; Tue, 25 Apr 2006 15:15:53 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3PLFrca011844 for ; Tue, 25 Apr 2006 15:15:53 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PLFqbU005704; Tue, 25 Apr 2006 16:15:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PLFqo1005703; Tue, 25 Apr 2006 16:15:52 -0500 (CDT) Date: Tue, 25 Apr 2006 16:15:52 -0500 From: Nicolas Williams To: Michael Richardson Subject: Re: [MULTIMOBSEC-API] Re: first steps in APIs Message-ID: <20060425211552.GS4000@binky.Central.Sun.COM> Mail-Followup-To: Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> <20060425152234.GN4000@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, Apr 25, 2006 at 05:05:43PM -0400, Michael Richardson wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> Yes, but I think there's a point where they may meet: at the API > Nicolas> for obtaining the end-point IDs of a latched connection, and, > Nicolas> therefore, the > Nicolas> representation of these IDs (IKEv2-style representation, + BTNS > Nicolas> publickey ID type, + HITs). > > When you receive a latched connection that was accepted due to BTNS, > and the ID that was asserted in IKE was ID_IPV6 (recalling that BTNS > made you not care that much about how valid it was for them to assert that), > would you expect to see the end-point ID be: > a) the IPV6 that was asserted via IKE. > b) the HIT that the transport/shim6 layer asserted > > Aren't these two different things? > Particularly when the IE in IKE was in fact FQDN or something. You would expect to get the coerced peer ID, the BTNS publickey ID whose value is the peer's public key. You want to see the IP addresses? Sure, you can do that today. You want to see your NATed address, Ok, that's something new. > I can see applications that take a connection the first time, set > up some kind of account, have the account validated by out-of-band method > (e.g. the user paid for the service), and recall the public key used to sign > on. Subsequent sign-ons are authenticated nicely by public alone. Yes, exactly, that's ad-hoc authentication based on enrolment of BTNS public keys. _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Wed Apr 26 03:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYeJ3-0001Jx-8W; Wed, 26 Apr 2006 03:19:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYe7o-0000NO-7J for multimobsec-api@ietf.org; Wed, 26 Apr 2006 03:07:48 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYdyA-0007y7-Dz for multimobsec-api@ietf.org; Wed, 26 Apr 2006 02:57:52 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 3B37B212C8D; Wed, 26 Apr 2006 09:57:47 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 03D82212C61; Wed, 26 Apr 2006 09:57:47 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id B9A1DBDC40; Wed, 26 Apr 2006 09:57:46 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 83F62BDC38; Wed, 26 Apr 2006 09:57:46 +0300 (EEST) In-Reply-To: <26520.1145971498@sandelman.ottawa.on.ca> References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> <26520.1145971498@sandelman.ottawa.on.ca> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <21761f7c6ecea7a890e85bbfccd1fa28@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MULTIMOBSEC-API] Re: first steps in APIs Date: Wed, 26 Apr 2006 09:57:53 +0300 To: Michael Richardson X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org El 25/04/2006, a las 16:24, Michael Richardson escribi=F3: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>>>>> "marcelo" =3D=3D marcelo bagnulo braun = writes: > marcelo> what about MOBIKE? wouldn't mobike need similar locator > marcelo> management and failure detection functions? > > MOBIKE is about moving the outer part of an IPsec tunnel around. > > The addresses inside (the identifiers if you prefer), remain the=20 > same, > so applications do not see any change. > > A MOBIKE daemon *itself* might benefit from the mechanisms provided=20= > by > shim6 (if it were available for IPv4), but the end-user application > would never see the changes. That's the purpose of MOBIKE. > > As for MIP, again, the point of the effort is to maintain the same=20= > set > of identifiers for the application. > exactly, this is also the case for shim6 and for hip, but the point of=20= an API extension for this cases is that shim6/hip/mobike/mip aware=20 applications can be aware of locators and reachability of those because=20= they want to have more control about them. In particular, this is=20 important in the case of reachability, because the application is more=20= capable of determining when a failure has occurred (at least what the=20 app considers a failure to be) So, i guess the point is that while all these allow a transparent=20 behaviour for the apps, the goal of the API is to allow access to more=20= detailed information for those apps that can handle it regards, marcelo > - -- > ] ON HUMILITY: to err is human. To moo, bovine. | =20 > firewalls [ > ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net=20= > architect[ > ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/=20 > |device driver[ > ] panic("Just another Debian GNU/Linux using, kernel hacking, security=20= > guy"); [ > > "The Microsoft _Get the Facts CD_ does not work on Linux." -=20 > orospakr > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Finger me for keys > > iQEVAwUBRE4jJoCLcPvd0N1lAQJiNgf+KwUNs2RdKnIat0zoc0cBQXLtwbHa27ds > v78cuzEtG28uq9IQ0lGngSlcNqouGM4taIVOvThQ2jEs9GG/2pSYgXON1VNbj2nG > N7A+wuDC0EI5i7Qim/d4TplwGcmbHcPL+zCslKBf+KtU/UsKQ3WuIFkiNgJnmGIZ > W1paC9g00X0p1QFOLfwlvgFVctHPBE2THLv4pDFb5/r3j2z7iCL7wGvwqSw3rTKK > lzQjKhsi7g72pPPXyAty6CzQ4iYcsBcCyaorgH7FJurxh6SBPxpE4yX8pMK6hn+N > DstQvQJzXx5QAr9OKkQHeLNfa57cbZ0Nc0p53ZMwHBkKeBxMP+RuuQ=3D=3D > =3Dmm+X > -----END PGP SIGNATURE----- > _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Wed Apr 26 04:50:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYfjY-00034u-43; Wed, 26 Apr 2006 04:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYfjW-00034j-Me for multimobsec-api@ietf.org; Wed, 26 Apr 2006 04:50:50 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYfjV-0007D0-Cc for multimobsec-api@ietf.org; Wed, 26 Apr 2006 04:50:50 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id C216532E6; Wed, 26 Apr 2006 11:50:48 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5CAA832C7; Wed, 26 Apr 2006 11:50:48 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3Q8olTe002188; Wed, 26 Apr 2006 11:50:47 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Wed, 26 Apr 2006 11:50:46 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Nicolas Williams Subject: Re: [MULTIMOBSEC-API] List settings In-Reply-To: <20060425203942.GQ4000@binky.Central.Sun.COM> Message-ID: References: <20060425203942.GQ4000@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, 25 Apr 2006, Nicolas Williams wrote: > This list got Cc'ed on a thread in a different IETF list, so when I > reply I get these automated replies telling me that my posts need > moderator approval, blah, blah, blah. Missing from these unhelpful > e-mails: a URL where I could go subscribe. > > I found the subscription page in a few minutes, which brings up a second > issue: I shouldn't have to subscribe just to post, particularly given > that I subscribe to umpteen IETF lists. > > Not friendly list behaviour. Sorry about this. This is the first time I am managing a list at the IETF. I've seen the approval messages, but I don't have the admin password but I have requested it. It might have been in the first welcome email but I may have just deleted it by accident. Please accept my embarrassed apologies. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Wed Apr 26 04:52:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYfkr-0003Q3-DR; Wed, 26 Apr 2006 04:52:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYfkq-0003Py-JZ for multimobsec-api@ietf.org; Wed, 26 Apr 2006 04:52:12 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYfkq-0007E7-A1 for multimobsec-api@ietf.org; Wed, 26 Apr 2006 04:52:12 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id CB01B32E6; Wed, 26 Apr 2006 11:52:11 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5014532E0; Wed, 26 Apr 2006 11:52:11 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3Q8qBgP002234; Wed, 26 Apr 2006 11:52:11 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Wed, 26 Apr 2006 11:52:10 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Nicolas Williams Subject: Re: [MULTIMOBSEC-API] List settings In-Reply-To: <20060425204647.GR4000@binky.Central.Sun.COM> Message-ID: References: <20060425203942.GQ4000@binky.Central.Sun.COM> <20060425204647.GR4000@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, 25 Apr 2006, Nicolas Williams wrote: > Also, the mailman archive is password protected, but the list archive > can be fetched via anonymous FTP. > > Worse: the mailman archive is day-by-day, so I have to click on each day > one by one (the list has been up for four days). > > Please remove the password protection, it's pointless. Or fix the anon > FTP situation. > > Please fix the archive -- it's very painful to use. Will do as soon as I get an admin password. Sorry for the inconviniency. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Wed Apr 26 11:41:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYm8a-0006L0-Jk; Wed, 26 Apr 2006 11:41:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYm8Z-0006Ku-Ep for multimobsec-api@ietf.org; Wed, 26 Apr 2006 11:41:07 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYm8X-0003bL-Q7 for multimobsec-api@ietf.org; Wed, 26 Apr 2006 11:41:07 -0400 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k3QFf54d001428 for ; Wed, 26 Apr 2006 09:41:05 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3QFf4ca029276 for ; Wed, 26 Apr 2006 09:41:04 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3QFf0WE007984; Wed, 26 Apr 2006 10:41:00 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3QFexH8007983; Wed, 26 Apr 2006 10:40:59 -0500 (CDT) Date: Wed, 26 Apr 2006 10:40:59 -0500 From: Nicolas Williams To: Miika Komu Subject: Re: [MULTIMOBSEC-API] List settings Message-ID: <20060426154058.GY4000@binky.Central.Sun.COM> References: <20060425203942.GQ4000@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Wed, Apr 26, 2006 at 11:50:46AM +0300, Miika Komu wrote: > On Tue, 25 Apr 2006, Nicolas Williams wrote: > >Not friendly list behaviour. > > Sorry about this. This is the first time I am managing a list at the IETF. Ah, sorry, I figured these settings were intentional (and misguided). > I've seen the approval messages, but I don't have the admin password but I > have requested it. It might have been in the first welcome email but I may > have just deleted it by accident. Please accept my embarrassed apologies. Well, I apologize for the stridence of my complaint; I should have noticed that you were the list admin and sent private e-mail. Thanks, Nico -- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Thu Apr 27 05:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ318-0007YD-KW; Thu, 27 Apr 2006 05:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPbf-00052M-Dv for multimobsec-api@ietf.org; Tue, 25 Apr 2006 11:37:39 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPbY-0005j1-7R for multimobsec-api@ietf.org; Tue, 25 Apr 2006 11:37:39 -0400 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3PFbVaN027978 for ; Tue, 25 Apr 2006 09:37:31 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3PFbVca024915 for ; Tue, 25 Apr 2006 09:37:31 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PFbU3x004650; Tue, 25 Apr 2006 10:37:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PFbU9s004649; Tue, 25 Apr 2006 10:37:30 -0500 (CDT) Date: Tue, 25 Apr 2006 10:37:30 -0500 From: Nicolas Williams To: Pekka Nikander Subject: Re: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs Message-ID: <20060425153730.GP4000@binky.Central.Sun.COM> Mail-Followup-To: Pekka Nikander , Miika Komu , marcelo bagnulo braun , Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Thu, 27 Apr 2006 05:42:33 -0400 Cc: Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, Apr 25, 2006 at 12:41:15PM +0300, Pekka Nikander wrote: > To me, one of the more important parts of this exercise is to see > whether, from an application's point of view, one could more or less > implement HIP-functionality with BTNS+CGA+SHIM6. In other words, my > gut feeling is that that it would be good if > > HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff. What is CGA? Anyways, what you call "BNTS api" is really an IPsec API: - APIs for getting latched connection peer IDs (enough for channel bindings and application-driven LoF and enrolment) - APIs for requesting services beyond what the SPD requires (e.g., confidentiality where the SPD requires only integrity protection, or any protection at all where the SPD allows bypassing) - APIs for requesting bypass (requiring privilege, of course) - APIs for editing the IPsec policy databases (PAD, SPD) (which could be used for application-driven LoF and enrolment, but this is a much bigger hammer than the above) Given a canonical tokenization of IKE/IPsec/BTNS IDs and HITs I think this comes very close to a basic HIP API. Still needed: - additional APIs to deal with mobility/NAT (again, this would be fairly generic) - APIs to locate peers (this being rather specific to HIP). Nico -- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Thu Apr 27 05:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ318-0007Y6-I2; Thu, 27 Apr 2006 05:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPNJ-0006ng-LS for multimobsec-api@ietf.org; Tue, 25 Apr 2006 11:22:49 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPNA-00055N-4y for multimobsec-api@ietf.org; Tue, 25 Apr 2006 11:22:49 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3PFMd3i021837 for ; Tue, 25 Apr 2006 09:22:39 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3PFMcca019015 for ; Tue, 25 Apr 2006 09:22:39 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PFMcah004634; Tue, 25 Apr 2006 10:22:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PFMbiI004633; Tue, 25 Apr 2006 10:22:37 -0500 (CDT) Date: Tue, 25 Apr 2006 10:22:35 -0500 From: Nicolas Williams To: Miika Komu Subject: Re: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs Message-ID: <20060425152234.GN4000@binky.Central.Sun.COM> Mail-Followup-To: Miika Komu , marcelo bagnulo braun , Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Thu, 27 Apr 2006 05:42:33 -0400 Cc: Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, Apr 25, 2006 at 10:00:51AM +0300, Miika Komu wrote: > I think there is some overlap even between shim6 and btns, but the overlap > is somewhat marginal. Consider these examples: > > * You could request current IPsec security parameters from shim6 module > and it would tell you that there is none > * To set-up BTNS IPsec policies and associations, you also need locators Er, let's be careful and avoid confusion on the BTNS list about this: - BTNS is, at its core, about NOT authenticating peers - BTNS allows for anonymity and pseudonymity - (BTNS pseudonymity && (application-driven enrolment || application-driven leap-of-faith)) == ad-hoc IPsec authentication - Some BTNS applications (channel bindings) don't care for pseudonymity, and, therefore, don't care for ad-hoc IPsec authentication. So, BTNS can be said to have locators, but it isn't strictly the case that it does have locators -- "BTNS locators" are an application construct, not a fundamental BTNS construct. > However, there is no reason why these APIs couldn't be decoupled. Yes, but I think there's a point where they may meet: at the API for obtaining the end-point IDs of a latched connection, and, therefore, the representation of these IDs (IKEv2-style representation, + BTNS publickey ID type, + HITs). Nico -- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Thu Apr 27 05:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ318-0007YD-KW; Thu, 27 Apr 2006 05:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPbf-00052M-Dv for multimobsec-api@ietf.org; Tue, 25 Apr 2006 11:37:39 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPbY-0005j1-7R for multimobsec-api@ietf.org; Tue, 25 Apr 2006 11:37:39 -0400 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3PFbVaN027978 for ; Tue, 25 Apr 2006 09:37:31 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3PFbVca024915 for ; Tue, 25 Apr 2006 09:37:31 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PFbU3x004650; Tue, 25 Apr 2006 10:37:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PFbU9s004649; Tue, 25 Apr 2006 10:37:30 -0500 (CDT) Date: Tue, 25 Apr 2006 10:37:30 -0500 From: Nicolas Williams To: Pekka Nikander Subject: Re: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs Message-ID: <20060425153730.GP4000@binky.Central.Sun.COM> Mail-Followup-To: Pekka Nikander , Miika Komu , marcelo bagnulo braun , Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Thu, 27 Apr 2006 05:42:33 -0400 Cc: Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, Apr 25, 2006 at 12:41:15PM +0300, Pekka Nikander wrote: > To me, one of the more important parts of this exercise is to see > whether, from an application's point of view, one could more or less > implement HIP-functionality with BTNS+CGA+SHIM6. In other words, my > gut feeling is that that it would be good if > > HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff. What is CGA? Anyways, what you call "BNTS api" is really an IPsec API: - APIs for getting latched connection peer IDs (enough for channel bindings and application-driven LoF and enrolment) - APIs for requesting services beyond what the SPD requires (e.g., confidentiality where the SPD requires only integrity protection, or any protection at all where the SPD allows bypassing) - APIs for requesting bypass (requiring privilege, of course) - APIs for editing the IPsec policy databases (PAD, SPD) (which could be used for application-driven LoF and enrolment, but this is a much bigger hammer than the above) Given a canonical tokenization of IKE/IPsec/BTNS IDs and HITs I think this comes very close to a basic HIP API. Still needed: - additional APIs to deal with mobility/NAT (again, this would be fairly generic) - APIs to locate peers (this being rather specific to HIP). Nico -- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Thu Apr 27 05:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ318-0007Y6-I2; Thu, 27 Apr 2006 05:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYPNJ-0006ng-LS for multimobsec-api@ietf.org; Tue, 25 Apr 2006 11:22:49 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYPNA-00055N-4y for multimobsec-api@ietf.org; Tue, 25 Apr 2006 11:22:49 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3PFMd3i021837 for ; Tue, 25 Apr 2006 09:22:39 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3PFMcca019015 for ; Tue, 25 Apr 2006 09:22:39 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PFMcah004634; Tue, 25 Apr 2006 10:22:38 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PFMbiI004633; Tue, 25 Apr 2006 10:22:37 -0500 (CDT) Date: Tue, 25 Apr 2006 10:22:35 -0500 From: Nicolas Williams To: Miika Komu Subject: Re: [anonsec] [MULTIMOBSEC-API] Re: first steps in APIs Message-ID: <20060425152234.GN4000@binky.Central.Sun.COM> Mail-Followup-To: Miika Komu , marcelo bagnulo braun , Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Thu, 27 Apr 2006 05:42:33 -0400 Cc: Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, Apr 25, 2006 at 10:00:51AM +0300, Miika Komu wrote: > I think there is some overlap even between shim6 and btns, but the overlap > is somewhat marginal. Consider these examples: > > * You could request current IPsec security parameters from shim6 module > and it would tell you that there is none > * To set-up BTNS IPsec policies and associations, you also need locators Er, let's be careful and avoid confusion on the BTNS list about this: - BTNS is, at its core, about NOT authenticating peers - BTNS allows for anonymity and pseudonymity - (BTNS pseudonymity && (application-driven enrolment || application-driven leap-of-faith)) == ad-hoc IPsec authentication - Some BTNS applications (channel bindings) don't care for pseudonymity, and, therefore, don't care for ad-hoc IPsec authentication. So, BTNS can be said to have locators, but it isn't strictly the case that it does have locators -- "BTNS locators" are an application construct, not a fundamental BTNS construct. > However, there is no reason why these APIs couldn't be decoupled. Yes, but I think there's a point where they may meet: at the API for obtaining the end-point IDs of a latched connection, and, therefore, the representation of these IDs (IKEv2-style representation, + BTNS publickey ID type, + HITs). Nico -- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Thu Apr 27 05:42:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ318-0007ZG-Qi; Thu, 27 Apr 2006 05:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYUBA-0000WA-28 for multimobsec-api@ietf.org; Tue, 25 Apr 2006 16:30:36 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYUB7-0006Kq-Il for multimobsec-api@ietf.org; Tue, 25 Apr 2006 16:30:36 -0400 Received: from centralmail1brm.Central.Sun.COM (centralmail1brm.central.sun.com [129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k3PKUXaN020512 for ; Tue, 25 Apr 2006 14:30:33 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3PKUWca020178 for ; Tue, 25 Apr 2006 14:30:32 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PKUWld005084; Tue, 25 Apr 2006 15:30:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PKUWV4005083; Tue, 25 Apr 2006 15:30:32 -0500 (CDT) Date: Tue, 25 Apr 2006 15:30:32 -0500 From: Nicolas Williams To: Michael Richardson Message-ID: <20060425203031.GP4000@binky.Central.Sun.COM> Mail-Followup-To: Michael Richardson , anonsec@postel.org, multimobsec-api@ietf.org References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Thu, 27 Apr 2006 05:42:33 -0400 Cc: multimobsec-api@ietf.org, anonsec@postel.org Subject: [MULTIMOBSEC-API] Re: [anonsec] first steps in APIs X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, Apr 25, 2006 at 03:32:03PM -0400, Michael Richardson wrote: > Pekka> HIP api == BNTS api + SHIM6 api + possibly some CGA-related stuff. > > So, you do not so much want us to find common pieces, but rather to > delinate clearly where one starts and one ends. Dunno about Pekka, but, I see what he termed "BTNS api" above as a generic IPsec API, which I describe, in broad terms, in the BTNS connection latching I-D[0]. Given this I think we're talking about a well-delineated generic IPsec API[1] that is commonly useful in the BTNS, HIP and SHIM6 spaces. [0] http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-latching-00.txt [1] There's another proposed IPsec API for editing IPsec policy databases, but I think this API would not be common to the BTNS, HIP and SHIM6 spaces. Nico -- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Thu Apr 27 05:42:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ318-0007YM-NE; Thu, 27 Apr 2006 05:42:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTul-0008T9-I0 for multimobsec-api@ietf.org; Tue, 25 Apr 2006 16:13:39 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYTuH-0004zn-EP for multimobsec-api@ietf.org; Tue, 25 Apr 2006 16:13:39 -0400 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k3PKD83i014030 for ; Tue, 25 Apr 2006 14:13:08 -0600 (MDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k3PKD7da015599 for ; Tue, 25 Apr 2006 14:13:08 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k3PKD7Y4005048; Tue, 25 Apr 2006 15:13:07 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k3PKD7d3005047; Tue, 25 Apr 2006 15:13:07 -0500 (CDT) Date: Tue, 25 Apr 2006 15:13:07 -0500 From: Nicolas Williams To: Michael Richardson Message-ID: <20060425201306.GM4000@binky.Central.Sun.COM> Mail-Followup-To: Michael Richardson , anonsec@postel.org, multimobsec-api@ietf.org References: <20060413143834.A4B6.SHINTA@sfc.wide.ad.jp> <20060425102448.12B6.SHINTA@sfc.wide.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-Mailman-Approved-At: Thu, 27 Apr 2006 05:42:33 -0400 Cc: multimobsec-api@ietf.org, anonsec@postel.org Subject: [MULTIMOBSEC-API] Re: [anonsec] btns-ipsec-apireq.txt X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, Apr 25, 2006 at 03:29:55PM -0400, Michael Richardson wrote: > So, in the IPsec space we have: > > a) principal - DN,SPKI Id,PGP identity,public key > b) IKE layer - certificate/public key and/or hash of same. > c) transport layer - ULP (could be HIT) > d) IPsec layer - SPI# (SA bundle and pair) > e) network layer - current (shim6) locator > > It is an explicit non-goal to provide access to (d). Indeed. Connection latching should obviate the need for applications to care about SPIs. > We already think we have access to (c) via current API. > It is (b) and (a) that we are trying to get access to. Yes! The BTNS connection latching I-D discusses this somewhat. (a) could be any of the ID types discussed in RFC4301, which relate fairly closely to IKEv2 ID types, which relate somewhat to credentials. (b) would be, IMO, only public keys or fingerprints thereof. I see entire certs as useful for granular authorization, but not necessary for the kinds of applications discussed in the BTNS WG. Note that (a) and (b) pretty much imply connection latching (to see why see the post-Vancouver, pre-Dallas threads on the BTNS WG list). > Does this mean that there is in fact more commonality? I think so. Nico -- _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Thu Apr 27 05:49:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ37d-0004TD-AU; Thu, 27 Apr 2006 05:49:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ37b-0004Ln-Jj for multimobsec-api@ietf.org; Thu, 27 Apr 2006 05:49:15 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ37a-00015Y-9M for multimobsec-api@ietf.org; Thu, 27 Apr 2006 05:49:15 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 66AA231E2; Thu, 27 Apr 2006 12:49:13 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.1.1-niksula20060321 (2006-03-10) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.1-niksula20060321 X-Spam-Niksula: No Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id BA86D2F7F; Thu, 27 Apr 2006 12:49:12 +0300 (EEST) Received: from localhost (mkomu@localhost) by kekkonen.cs.hut.fi (8.13.4+Sun/8.13.3) with ESMTP id k3R9nBwh023837; Thu, 27 Apr 2006 12:49:12 +0300 (EEST) X-Authentication-Warning: kekkonen.cs.hut.fi: mkomu owned process doing -bs Date: Thu, 27 Apr 2006 12:49:11 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Nicolas Williams Subject: Re: [MULTIMOBSEC-API] List settings In-Reply-To: <20060425204647.GR4000@binky.Central.Sun.COM> Message-ID: References: <20060425203942.GQ4000@binky.Central.Sun.COM> <20060425204647.GR4000@binky.Central.Sun.COM> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: multimobsec-api@ietf.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org On Tue, 25 Apr 2006, Nicolas Williams wrote: > Also, the mailman archive is password protected, but the list archive > can be fetched via anonymous FTP. > > Worse: the mailman archive is day-by-day, so I have to click on each day > one by one (the list has been up for four days). > > Please remove the password protection, it's pointless. Or fix the anon > FTP situation. > > Please fix the archive -- it's very painful to use. Fixed now. -- Miika Komu miika@iki.fi http://www.iki.fi/miika/ _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api From multimobsec-api-bounces@ietf.org Thu Apr 27 06:28:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ3js-0002v2-9I; Thu, 27 Apr 2006 06:28:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ3jq-0002ux-Id for multimobsec-api@ietf.org; Thu, 27 Apr 2006 06:28:46 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ3jp-00033Y-3D for multimobsec-api@ietf.org; Thu, 27 Apr 2006 06:28:46 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2C3DB212C8E; Thu, 27 Apr 2006 13:28:44 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id EA3A7212C8D; Thu, 27 Apr 2006 13:28:43 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id AD040BDC40; Thu, 27 Apr 2006 13:28:43 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 7697EBDC38; Thu, 27 Apr 2006 13:28:43 +0300 (EEST) In-Reply-To: <20060425203031.GP4000@binky.Central.Sun.COM> References: <10723.1145750635@sandelman.ottawa.on.ca> <94fc702121d17ada1f6bdce3eafcf2a1@it.uc3m.es> <5176de9ac186aff75b7e0319b12672eb@it.uc3m.es> <20060425203031.GP4000@binky.Central.Sun.COM> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [MULTIMOBSEC-API] Re: [anonsec] first steps in APIs Date: Thu, 27 Apr 2006 13:28:51 +0300 To: Nicolas Williams X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Michael Richardson , multimobsec-api@ietf.org, anonsec@postel.org X-BeenThere: multimobsec-api@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Multihoming, mobility and security APIs" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: multimobsec-api-bounces@ietf.org El 25/04/2006, a las 23:30, Nicolas Williams escribi=F3: > On Tue, Apr 25, 2006 at 03:32:03PM -0400, Michael Richardson wrote: >> Pekka> HIP api =3D=3D BNTS api + SHIM6 api + possibly some =20 >> CGA-related stuff. >> >> So, you do not so much want us to find common pieces, but rather to >> delinate clearly where one starts and one ends. > > Dunno about Pekka, but, I see what he termed "BTNS api" above as a > generic IPsec API, which I describe, in broad terms, in the BTNS > connection latching I-D[0]. > > Given this I think we're talking about a well-delineated generic IPsec > API[1] that is commonly useful in the BTNS, HIP and SHIM6 spaces. > but shim6 is layered below IPSec, so actually you only need to access =20= to the shim6 layer in case that you want richer information about =20 locators, failures and this kind of stuff... I mean, shim6 should be transparent to IPSec, which is not the case of =20= HIP and BTNS AFAICT.... In other words, in general IPSec should be exactly the same with or =20 without the shim. Regards, marcelo > [0] =20 > http://www.ietf.org/internet-drafts/draft-ietf-btns-connection-=20 > latching-00.txt > > [1] There's another proposed IPsec API for editing IPsec policy > databases, but I think this API would not be common to the BTNS, =20= > HIP > and SHIM6 spaces. > > Nico > --=20 > > _______________________________________________ > MULTIMOBSEC-API mailing list > MULTIMOBSEC-API@ietf.org > https://www1.ietf.org/mailman/listinfo/multimobsec-api > _______________________________________________ MULTIMOBSEC-API mailing list MULTIMOBSEC-API@ietf.org https://www1.ietf.org/mailman/listinfo/multimobsec-api