From hipsec-bounces@lists.ietf.org Tue May 08 11:57:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlS4Y-0003Op-HX; Tue, 08 May 2007 11:57:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlS4X-0003Ok-Aw for hipsec@ietf.org; Tue, 08 May 2007 11:57:53 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlS4W-0006z0-3I for hipsec@ietf.org; Tue, 08 May 2007 11:57:53 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l48FvppC001306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 8 May 2007 10:57:51 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l48Fvp2O003810; Tue, 8 May 2007 10:57:51 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l48Fvn8I003756; Tue, 8 May 2007 10:57:50 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 08:57:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] RE: comments on native HIP API draft Date: Tue, 8 May 2007 08:57:46 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040492EE@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040492BF@XCH-NW-5V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] RE: comments on native HIP API draft Thread-Index: AceLAc8lDA/ni4DJRlSyHYPANKBK7gAImMsgAZlKjuA= From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 08 May 2007 15:57:47.0411 (UTC) FILETIME=[9F654630:01C79189] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Readers of this thread may be interested to note that discussion has spilled over to two additional lists: apps-discuss (thread starts here: http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html) RAM (thread starts here: http://www1.ietf.org/mail-archive/web/ram/current/msg01331.html)=20 -Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 14 03:41:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnVB0-0007NY-Go; Mon, 14 May 2007 03:41:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnVAz-0007NS-Hc for hipsec@ietf.org; Mon, 14 May 2007 03:41:01 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnVAx-0002Sp-Qk for hipsec@ietf.org; Mon, 14 May 2007 03:41:01 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 026F420720; Mon, 14 May 2007 09:40:40 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-63-464812778b71 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DDE9E206BB; Mon, 14 May 2007 09:40:39 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 09:40:39 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 09:40:39 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5354A24D7; Mon, 14 May 2007 10:40:39 +0300 (EEST) Message-ID: <46481276.6050401@ericsson.com> Date: Mon, 14 May 2007 10:40:38 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] RE: comments on native HIP API draft References: <77F357662F8BFA4CA7074B0410171B6D040492EE@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040492EE@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2007 07:40:39.0554 (UTC) FILETIME=[2B15FE20:01C795FB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, it is good to have discussions on the API draft. We also need to schedule the start of its WGLC. How does the beginning of June sound? That would give us two weeks to have a stable version of the draft before WGLCing it. If you think this time plan is too aggressive, let me know. Cheers, Gonzalo Henderson, Thomas R wrote: > Readers of this thread may be interested to note that discussion has > spilled over to two additional lists: > > apps-discuss (thread starts here: > http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html) > RAM (thread starts here: > http://www1.ietf.org/mail-archive/web/ram/current/msg01331.html) > > -Tom > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 14 06:30:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnXoa-0004H8-Di; Mon, 14 May 2007 06:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnXoY-0004Gw-Si for hipsec@ietf.org; Mon, 14 May 2007 06:30:02 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnXoX-0001rF-8I for hipsec@ietf.org; Mon, 14 May 2007 06:30:02 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id WAA05984; Mon, 14 May 2007 22:29:57 +1200 In-Reply-To: <46481276.6050401@ericsson.com> References: <77F357662F8BFA4CA7074B0410171B6D040492EE@XCH-NW-5V1.nw.nos.boeing.com> <46481276.6050401@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <530F4842-279B-4E8B-9AFA-FF882C923BD6@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [Hipsec] RE: comments on native HIP API draft Date: Mon, 14 May 2007 22:31:59 +1200 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org I think the substance of the comments so far require a fair bit of a rethink, or else a new draft to follow on more general C API matters. So maybe it's premature to WGLC it yet before we can differentiate those two paths. Andrew On 14/05/2007, at 7:40 PM, Gonzalo Camarillo wrote: > Hi, > > it is good to have discussions on the API draft. We also need to > schedule the start of its WGLC. How does the beginning of June > sound? That would give us two weeks to have a stable version of the > draft before WGLCing it. > > If you think this time plan is too aggressive, let me know. > > Cheers, > > Gonzalo > > Henderson, Thomas R wrote: >> Readers of this thread may be interested to note that discussion has >> spilled over to two additional lists: >> apps-discuss (thread starts here: >> http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html) >> RAM (thread starts here: >> http://www1.ietf.org/mail-archive/web/ram/current/msg01331.html) -Tom >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 14 07:48:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZ2S-0002d7-K2; Mon, 14 May 2007 07:48:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZ2R-0002Xa-Qu for hipsec@ietf.org; Mon, 14 May 2007 07:48:27 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnZ2P-0000O5-1b for hipsec@ietf.org; Mon, 14 May 2007 07:48:27 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 54E482D7E; Mon, 14 May 2007 14:48:24 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 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 6C4D22D4D; Mon, 14 May 2007 14:48:23 +0300 (EEST) Date: Mon, 14 May 2007 14:48:23 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Andrew McGregor Subject: Re: [Hipsec] RE: comments on native HIP API draft In-Reply-To: <530F4842-279B-4E8B-9AFA-FF882C923BD6@indranet.co.nz> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D040492EE@XCH-NW-5V1.nw.nos.boeing.com> <46481276.6050401@ericsson.com> <530F4842-279B-4E8B-9AFA-FF882C923BD6@indranet.co.nz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 14 May 2007, Andrew McGregor wrote: Agree. The design is going to change quite much because the apps folks seemed to think that the ULID should be HIT, and not endpoint descriptor. I would like to have an intermediate version for proper review and polishing. The two week timeframe is too short for me, would it be fine to follow the normal IETF cut-off DL? I'll make also a pre-version for early comments. > I think the substance of the comments so far require a fair bit of a rethink, > or else a new draft to follow on more general C API matters. So maybe it's > premature to WGLC it yet before we can differentiate those two paths. > > Andrew > > On 14/05/2007, at 7:40 PM, Gonzalo Camarillo wrote: > >> Hi, >> >> it is good to have discussions on the API draft. We also need to schedule >> the start of its WGLC. How does the beginning of June sound? That would >> give us two weeks to have a stable version of the draft before WGLCing it. >> >> If you think this time plan is too aggressive, let me know. >> >> Cheers, >> >> Gonzalo >> >> Henderson, Thomas R wrote: >>> Readers of this thread may be interested to note that discussion has >>> spilled over to two additional lists: >>> apps-discuss (thread starts here: >>> http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html) >>> RAM (thread starts here: >>> http://www1.ietf.org/mail-archive/web/ram/current/msg01331.html) -Tom >>> _______________________________________________ >>> Hipsec mailing list >>> Hipsec@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/hipsec >> >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/hipsec >> > > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 14 08:14:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZRK-0001Lw-I9; Mon, 14 May 2007 08:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnZRJ-0001Lq-5q for hipsec@ietf.org; Mon, 14 May 2007 08:14:09 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnZRH-0002Zc-4H for hipsec@ietf.org; Mon, 14 May 2007 08:14:09 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 92FA2206E9; Mon, 14 May 2007 14:14:06 +0200 (CEST) X-AuditID: c1b4fb3c-ac51ebb0000073d5-23-4648528e5e4f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 814B9206AB; Mon, 14 May 2007 14:14:06 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 14:14:06 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 14:14:06 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D8B1924D7; Mon, 14 May 2007 15:14:05 +0300 (EEST) Message-ID: <4648528C.8000500@ericsson.com> Date: Mon, 14 May 2007 15:14:04 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Miika Komu Subject: Re: [Hipsec] RE: comments on native HIP API draft References: <77F357662F8BFA4CA7074B0410171B6D040492EE@XCH-NW-5V1.nw.nos.boeing.com> <46481276.6050401@ericsson.com> <530F4842-279B-4E8B-9AFA-FF882C923BD6@indranet.co.nz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 May 2007 12:14:06.0155 (UTC) FILETIME=[5E2EA1B0:01C79621] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, what I would like to have is a rough time plan so that I can update our charter appropriately. Cheers, Gonzalo Miika Komu wrote: > On Mon, 14 May 2007, Andrew McGregor wrote: > > Agree. The design is going to change quite much because the apps folks > seemed to think that the ULID should be HIT, and not endpoint descriptor. > I would like to have an intermediate version for proper review and > polishing. The two week timeframe is too short for me, would it be fine to > follow the normal IETF cut-off DL? I'll make also a pre-version for early > comments. > > > I think the substance of the comments so far require a fair bit of a > rethink, > > or else a new draft to follow on more general C API matters. So > maybe it's > > premature to WGLC it yet before we can differentiate those two paths. > > > > Andrew > > > > On 14/05/2007, at 7:40 PM, Gonzalo Camarillo wrote: > > > >> Hi, > >> > >> it is good to have discussions on the API draft. We also need to > schedule > >> the start of its WGLC. How does the beginning of June sound? That would > >> give us two weeks to have a stable version of the draft before > WGLCing it. > >> > >> If you think this time plan is too aggressive, let me know. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> Henderson, Thomas R wrote: > >>> Readers of this thread may be interested to note that discussion has > >>> spilled over to two additional lists: > >>> apps-discuss (thread starts here: > >>> http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html) > >>> RAM (thread starts here: > >>> http://www1.ietf.org/mail-archive/web/ram/current/msg01331.html) -Tom > >>> _______________________________________________ > >>> Hipsec mailing list > >>> Hipsec@lists.ietf.org > >>> https://www1.ietf.org/mailman/listinfo/hipsec > >> > >> > >> _______________________________________________ > >> Hipsec mailing list > >> Hipsec@lists.ietf.org > >> https://www1.ietf.org/mailman/listinfo/hipsec > >> > > > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/hipsec > > -- > Miika Komu http://www.iki.fi/miika/ > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 14 10:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbGh-0007wM-FB; Mon, 14 May 2007 10:11:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbGg-0007w8-0v for hipsec@ietf.org; Mon, 14 May 2007 10:11:18 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbGe-0001d3-Kt for hipsec@ietf.org; Mon, 14 May 2007 10:11:18 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 1164A2D81; Mon, 14 May 2007 17:11:09 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 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 F33D82D80; Mon, 14 May 2007 17:11:06 +0300 (EEST) Date: Mon, 14 May 2007 17:11:06 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Gonzalo Camarillo Subject: Re: [Hipsec] RE: comments on native HIP API draft In-Reply-To: <4648528C.8000500@ericsson.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D040492EE@XCH-NW-5V1.nw.nos.boeing.com> <46481276.6050401@ericsson.com> <530F4842-279B-4E8B-9AFA-FF882C923BD6@indranet.co.nz> <4648528C.8000500@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 14 May 2007, Gonzalo Camarillo wrote: I'd suggest the Chicago IETF as DL for the next revision of the draft. The WGLC could the Vancouver IETF because I doubt how much feedback we'll receive during summer time. If necessary, we can make the second DL earlier, but not the first one. > Hi, > > what I would like to have is a rough time plan so that I can update our > charter appropriately. > > Cheers, > > Gonzalo > > Miika Komu wrote: >> On Mon, 14 May 2007, Andrew McGregor wrote: >> >> Agree. The design is going to change quite much because the apps folks >> seemed to think that the ULID should be HIT, and not endpoint descriptor. >> I would like to have an intermediate version for proper review and >> polishing. The two week timeframe is too short for me, would it be fine to >> follow the normal IETF cut-off DL? I'll make also a pre-version for early >> comments. >> >> > I think the substance of the comments so far require a fair bit of a >> rethink, >> > or else a new draft to follow on more general C API matters. So maybe >> it's >> > premature to WGLC it yet before we can differentiate those two paths. >> > >> > Andrew >> > >> > On 14/05/2007, at 7:40 PM, Gonzalo Camarillo wrote: >> > >> >> Hi, >> >> >> >> it is good to have discussions on the API draft. We also need to >> schedule >> >> the start of its WGLC. How does the beginning of June sound? That would >> >> give us two weeks to have a stable version of the draft before WGLCing >> it. >> >> >> >> If you think this time plan is too aggressive, let me know. >> >> >> >> Cheers, >> >> >> >> Gonzalo >> >> >> >> Henderson, Thomas R wrote: >> >>> Readers of this thread may be interested to note that discussion has >> >>> spilled over to two additional lists: >> >>> apps-discuss (thread starts here: >> >>> http://www1.ietf.org/mail-archive/web/discuss/current/msg00496.html) >> >>> RAM (thread starts here: >> >>> http://www1.ietf.org/mail-archive/web/ram/current/msg01331.html) -Tom >> >>> _______________________________________________ >> >>> Hipsec mailing list >> >>> Hipsec@lists.ietf.org >> >>> https://www1.ietf.org/mailman/listinfo/hipsec >> >> >> >> >> >> _______________________________________________ >> >> Hipsec mailing list >> >> Hipsec@lists.ietf.org >> >> https://www1.ietf.org/mailman/listinfo/hipsec >> >> >> > >> > >> > _______________________________________________ >> > Hipsec mailing list >> > Hipsec@lists.ietf.org >> > https://www1.ietf.org/mailman/listinfo/hipsec >> >> -- >> Miika Komu http://www.iki.fi/miika/ >> > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 14 10:57:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbzN-0005Yg-J4; Mon, 14 May 2007 10:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnbzM-0005Ya-6H for hipsec@ietf.org; Mon, 14 May 2007 10:57:28 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnbzL-0008O5-Uh for hipsec@ietf.org; Mon, 14 May 2007 10:57:28 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l4EEvNjR027514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 14 May 2007 09:57:24 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l4EEvNXp009701; Mon, 14 May 2007 07:57:23 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l4EEvDCw009243; Mon, 14 May 2007 07:57:14 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 May 2007 07:57:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] RE: comments on native HIP API draft Date: Mon, 14 May 2007 07:57:11 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0404932D@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <530F4842-279B-4E8B-9AFA-FF882C923BD6@indranet.co.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] RE: comments on native HIP API draft Thread-Index: AceWEtOFN/lRF2wPQQGLIEcfwk+9ewAI3JrQ From: "Henderson, Thomas R" To: "Gonzalo Camarillo" X-OriginalArrivalTime: 14 May 2007 14:57:11.0799 (UTC) FILETIME=[26E16870:01C79638] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > On 14/05/2007, at 7:40 PM, Gonzalo Camarillo wrote: >=20 > > Hi, > > > > it is good to have discussions on the API draft. We also need to =20 > > schedule the start of its WGLC. How does the beginning of June =20 > > sound? That would give us two weeks to have a stable=20 > version of the =20 > > draft before WGLCing it. > > > > If you think this time plan is too aggressive, let me know. > > > > Cheers, > > > > Gonzalo > -----Original Message----- > From: Andrew McGregor [mailto:andrew@indranet.co.nz]=20 > Sent: Monday, May 14, 2007 3:32 AM > To: Gonzalo Camarillo > Cc: Henderson, Thomas R; hipsec@ietf.org > Subject: Re: [Hipsec] RE: comments on native HIP API draft >=20 > I think the substance of the comments so far require a fair bit of a =20 > rethink, or else a new draft to follow on more general C API =20 > matters. So maybe it's premature to WGLC it yet before we can =20 > differentiate those two paths. >=20 > Andrew >=20 I agree. Based on the feedback, there are probably two documents eventually needed (C-based API with HITs explicit, and longer term, higher-level API that is more abstracted than the present draft). We have a draft right now that sits somewhere in the middle of those two goals, based on the feedback on the other lists. It seems to me that both approaches are worthwhile to do, but we have drafts of neither right now. So I think that June is too aggressive. I would like to see the explicit HIT-based API done this year, and I think the other one will take a bit longer and require some prototyping. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 15 10:19:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnxrt-00087H-2D; Tue, 15 May 2007 10:19:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnawB-00082F-Dt; Mon, 14 May 2007 09:50:07 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnawB-0003TK-7H; Mon, 14 May 2007 09:50:07 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 1B23626EDD; Mon, 14 May 2007 13:50:07 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HnawB-0006Rs-0P; Mon, 14 May 2007 09:50:07 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 14 May 2007 09:50:07 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Tue, 15 May 2007 10:19:11 -0400 Cc: hipsec@ietf.org Subject: [Hipsec] Last Call: draft-ietf-hip-applications (Using the Host Identity Protocol with Legacy Applications) to Experimental RFC X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Using the Host Identity Protocol with Legacy Applications ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-05-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hip-applications-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15488&rfc_flag=0 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 15 10:19:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnxrt-00088H-9V; Tue, 15 May 2007 10:19:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnaws-0000nj-Jn; Mon, 14 May 2007 09:50:50 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnaws-0003n5-DD; Mon, 14 May 2007 09:50:50 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5058326E9F; Mon, 14 May 2007 13:50:50 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hnaws-0006TN-7V; Mon, 14 May 2007 09:50:50 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Mon, 14 May 2007 09:50:50 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Tue, 15 May 2007 10:19:11 -0400 Cc: hipsec@ietf.org Subject: [Hipsec] Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org The IESG has received a request from the Host Identity Protocol WG (hip) to consider the following document: - 'Host Identity Protocol (HIP) Domain Name System (DNS) Extensions ' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-05-28. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12489&rfc_flag=0 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 16 03:33:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoE0V-000479-C9; Wed, 16 May 2007 03:33:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoE0T-000471-G4 for hipsec@ietf.org; Wed, 16 May 2007 03:33:09 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoE0R-0006jd-Vr for hipsec@ietf.org; Wed, 16 May 2007 03:33:09 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7A62720478; Wed, 16 May 2007 09:33:07 +0200 (CEST) X-AuditID: c1b4fb3e-b1a1dbb0000061ca-98-464ab3b3eb49 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6BD1220245; Wed, 16 May 2007 09:33:07 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 09:33:07 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 09:33:06 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7A1F32495; Wed, 16 May 2007 10:33:06 +0300 (EEST) Message-ID: <464AB3B2.4050606@ericsson.com> Date: Wed, 16 May 2007 10:33:06 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] RE: comments on native HIP API draft References: <77F357662F8BFA4CA7074B0410171B6D0404932D@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D0404932D@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2007 07:33:06.0689 (UTC) FILETIME=[71FBC710:01C7978C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, > I agree. Based on the feedback, there are probably two documents > eventually needed (C-based API with HITs explicit, and longer term, > higher-level API that is more abstracted than the present draft). what are the arguments to write the long-term draft in the WG, as opposed to doing it in the RG? Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 16 03:34:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoE27-0004eE-Dm; Wed, 16 May 2007 03:34:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoE26-0004cW-4I for hipsec@ietf.org; Wed, 16 May 2007 03:34:50 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoE23-0007E6-J1 for hipsec@ietf.org; Wed, 16 May 2007 03:34:50 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 14F1920FCB; Wed, 16 May 2007 09:34:47 +0200 (CEST) X-AuditID: c1b4fb3e-ad9eabb0000061ca-88-464ab4170424 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 00E6F20245; Wed, 16 May 2007 09:34:47 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 09:34:46 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 May 2007 09:34:46 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D2F972495; Wed, 16 May 2007 10:34:45 +0300 (EEST) Message-ID: <464AB415.6000302@ericsson.com> Date: Wed, 16 May 2007 10:34:45 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2007 07:34:46.0230 (UTC) FILETIME=[AD508760:01C7978C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Hipsec] Timeframe for NAT traversal draft X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Folks, we need a new estimation for the completion of the NAT traversal draft in order to update our charter. Does the end of the year sound reasonable? Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 16 03:36:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoE3x-0005TU-So; Wed, 16 May 2007 03:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HoE3w-0005TE-DD for hipsec@ietf.org; Wed, 16 May 2007 03:36:44 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HoE3v-0007Tt-3O for hipsec@ietf.org; Wed, 16 May 2007 03:36:44 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 5DC6F2CFF; Wed, 16 May 2007 10:36:40 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 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 E742F2CFA; Wed, 16 May 2007 10:36:39 +0300 (EEST) Date: Wed, 16 May 2007 10:36:39 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Gonzalo Camarillo Subject: Re: [Hipsec] Timeframe for NAT traversal draft In-Reply-To: <464AB415.6000302@ericsson.com> Message-ID: References: <464AB415.6000302@ericsson.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Wed, 16 May 2007, Gonzalo Camarillo wrote: > Folks, > > we need a new estimation for the completion of the NAT traversal draft in > order to update our charter. Does the end of the year sound reasonable? Yes, it is fine. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri May 18 06:22:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hozbq-0001lB-00; Fri, 18 May 2007 06:22:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hozbo-0001l0-BE for hipsec@ietf.org; Fri, 18 May 2007 06:22:52 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hozbm-00013d-QE for hipsec@ietf.org; Fri, 18 May 2007 06:22:52 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3516020B2A; Fri, 18 May 2007 12:22:50 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-32-464d7e7a872a Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2827020B2B; Fri, 18 May 2007 12:22:50 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 12:22:49 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 18 May 2007 12:22:49 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2906F232C; Fri, 18 May 2007 13:22:49 +0300 (EEST) Message-ID: <464D7E78.30306@ericsson.com> Date: Fri, 18 May 2007 13:22:48 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2007 10:22:49.0411 (UTC) FILETIME=[7C2F5930:01C79936] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Hipsec] Does the HIP WG need to meet in Chicago? X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, it has been a while since our last face-to-face meeting. Do people feel the need to have one in Chicago? The agenda could include discussions on the API draft(s) and NAT traversal draft. Cheers, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 21 01:23:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq0Ml-0004b5-VM; Mon, 21 May 2007 01:23:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq0Ml-0004b0-Bf for hipsec@ietf.org; Mon, 21 May 2007 01:23:31 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq0Mk-0000xo-2o for hipsec@ietf.org; Mon, 21 May 2007 01:23:31 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l4L5NMV3000362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 May 2007 22:23:23 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l4L5NMJ0010292; Sun, 20 May 2007 22:23:22 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l4L5NMF2010289; Sun, 20 May 2007 22:23:22 -0700 (PDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.46]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 20 May 2007 22:23:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Does the HIP WG need to meet in Chicago? Date: Sun, 20 May 2007 22:23:21 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049378@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <464D7E78.30306@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Does the HIP WG need to meet in Chicago? Thread-Index: AceZNoLsCXzNGldGTkCYolzZlNQt8wCMSTig From: "Henderson, Thomas R" To: "Gonzalo Camarillo" , "HIP" X-OriginalArrivalTime: 21 May 2007 05:23:22.0775 (UTC) FILETIME=[26798270:01C79B68] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Friday, May 18, 2007 3:23 AM > To: HIP > Subject: [Hipsec] Does the HIP WG need to meet in Chicago? >=20 > Hi, >=20 > it has been a while since our last face-to-face meeting. Do=20 > people feel=20 > the need to have one in Chicago? >=20 > The agenda could include discussions on the API draft(s) and NAT=20 > traversal draft. >=20 > Cheers, >=20 > Gonzalo >=20 Gonzalo,=20 I would be interested in such a meeting, and on possibly seeing some revised drafts and reviewing the status of all of the ones that are in various stages of approval. It could probably be a short meeting, or it could also be done via email too. I will be suggesting also a HIP RG meeting in Chicago. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 21 04:23:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq3As-0000Pq-3y; Mon, 21 May 2007 04:23:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hq3Aq-0000Ph-4F for hipsec@ietf.org; Mon, 21 May 2007 04:23:24 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hq3Am-0000mO-9Q for hipsec@ietf.org; Mon, 21 May 2007 04:23:24 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9A68D2093C; Mon, 21 May 2007 10:23:19 +0200 (CEST) X-AuditID: c1b4fb3c-a84eabb0000073d5-21-465156f7cc87 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 867EF208A1; Mon, 21 May 2007 10:23:19 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 May 2007 10:23:19 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 May 2007 10:23:18 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 30BF4246A; Mon, 21 May 2007 11:23:18 +0300 (EEST) Message-ID: <465156F6.4090407@ericsson.com> Date: Mon, 21 May 2007 11:23:18 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] Does the HIP WG need to meet in Chicago? References: <77F357662F8BFA4CA7074B0410171B6D04049378@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049378@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 May 2007 08:23:18.0445 (UTC) FILETIME=[493205D0:01C79B81] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: HIP X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, Miika, who is one of the main contributors, just informed me that he will not be in Chicago. He indicated that, considering the pace at which the drafts are progressing, it would probably be better to have a face-to-face meeting at the IETF after Chicago instead. Unless somebody has a serious problem with this plan, let's aim to meet in December in Vancouver then. Cheers, Gonzalo Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Friday, May 18, 2007 3:23 AM >> To: HIP >> Subject: [Hipsec] Does the HIP WG need to meet in Chicago? >> >> Hi, >> >> it has been a while since our last face-to-face meeting. Do >> people feel >> the need to have one in Chicago? >> >> The agenda could include discussions on the API draft(s) and NAT >> traversal draft. >> >> Cheers, >> >> Gonzalo >> > > Gonzalo, > I would be interested in such a meeting, and on possibly seeing some > revised drafts and reviewing the status of all of the ones that are in > various stages of approval. It could probably be a short meeting, or it > could also be done via email too. I will be suggesting also a HIP RG > meeting in Chicago. > > Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 22 12:22:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqX7j-00038I-E4; Tue, 22 May 2007 12:22:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqX7i-00038D-IU for hipsec@ietf.org; Tue, 22 May 2007 12:22:10 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqX7h-0001Pz-9h for hipsec@ietf.org; Tue, 22 May 2007 12:22:10 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l4MGM4nR021088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 May 2007 09:22:05 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l4MGM4qU024716; Tue, 22 May 2007 11:22:04 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l4MGLuSN024362; Tue, 22 May 2007 11:22:04 -0500 (CDT) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.46]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 09:21:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] RE: comments on native HIP API draft Date: Tue, 22 May 2007 09:21:59 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049397@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <464AB3B2.4050606@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] RE: comments on native HIP API draft Thread-Index: AceXjHQXkIBSv8TJRlyi3P3mBGRuDwE/94Yw From: "Henderson, Thomas R" To: "Gonzalo Camarillo" X-OriginalArrivalTime: 22 May 2007 16:21:59.0866 (UTC) FILETIME=[52E8D1A0:01C79C8D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: Wednesday, May 16, 2007 12:33 AM > To: Henderson, Thomas R > Cc: hipsec@ietf.org; Andrew McGregor > Subject: Re: [Hipsec] RE: comments on native HIP API draft >=20 > Hi, >=20 > > I agree. Based on the feedback, there are probably two documents > > eventually needed (C-based API with HITs explicit, and longer term, > > higher-level API that is more abstracted than the present draft). >=20 > what are the arguments to write the long-term draft in the WG, as=20 > opposed to doing it in the RG? >=20 > Cheers, >=20 > Gonzalo Gonzalo, I forgot to reply to this message from last week. It seems to me that the WG ought to first see what revised draft(s) emerge before deciding this question. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 23 02:14:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqk7D-0006RL-Cq; Wed, 23 May 2007 02:14:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqk7C-0006ON-5r for hipsec@ietf.org; Wed, 23 May 2007 02:14:30 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqk7A-000470-At for hipsec@ietf.org; Wed, 23 May 2007 02:14:30 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id F386F20864; Wed, 23 May 2007 08:14:26 +0200 (CEST) X-AuditID: c1b4fb3c-a9cedbb0000073d5-dc-4653dbc2d87c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E0B18206FF; Wed, 23 May 2007 08:14:26 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 08:14:26 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 May 2007 08:14:26 +0200 Received: from [131.160.36.58] (E000FB0F665DD.lmf.ericsson.se [131.160.36.58]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 30D3D2593; Wed, 23 May 2007 09:14:26 +0300 (EEST) Message-ID: <4653DBC2.2080907@ericsson.com> Date: Wed, 23 May 2007 09:14:26 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Henderson, Thomas R" Subject: Re: [Hipsec] RE: comments on native HIP API draft References: <77F357662F8BFA4CA7074B0410171B6D04049397@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D04049397@XCH-NW-5V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 May 2007 06:14:26.0425 (UTC) FILETIME=[9D60E690:01C79D01] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi, well, scope decisions could be made before writing the drafts... but anyway, we can wait until the drafts are out there. No problem. Cheers, Gonzalo Henderson, Thomas R wrote: > > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: Wednesday, May 16, 2007 12:33 AM >> To: Henderson, Thomas R >> Cc: hipsec@ietf.org; Andrew McGregor >> Subject: Re: [Hipsec] RE: comments on native HIP API draft >> >> Hi, >> >>> I agree. Based on the feedback, there are probably two documents >>> eventually needed (C-based API with HITs explicit, and longer term, >>> higher-level API that is more abstracted than the present draft). >> what are the arguments to write the long-term draft in the WG, as >> opposed to doing it in the RG? >> >> Cheers, >> >> Gonzalo > > Gonzalo, I forgot to reply to this message from last week. It seems to > me that the WG ought to first see what revised draft(s) emerge before > deciding this question. > > Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri May 25 07:59:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYRz-0002O6-I7; Fri, 25 May 2007 07:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYRy-0002Ny-41 for hipsec@ietf.org; Fri, 25 May 2007 07:59:18 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrYRw-0008HA-Mt for hipsec@ietf.org; Fri, 25 May 2007 07:59:18 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1490E212E1E; Fri, 25 May 2007 14:59:15 +0300 (EEST) Received: from [127.0.0.1] (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id CF4A3212DFC; Fri, 25 May 2007 14:59:14 +0300 (EEST) Message-ID: <4656CF92.5060104@nomadiclab.com> Date: Fri, 25 May 2007 14:59:14 +0300 From: Petri Jokela User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Sam Hartman Subject: [Hipsec] HIP Base draft - ECHO signed/unsigned issue X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hello everybody, During IESG evaluation, the following comment (among others) was given by Sam: "In a discussion with secdir, Pekka N said that one of the motivations behind the unsigned echo and echo response is for middleboxes. I don't think this is well defined enough to be interoperable as only one of these parameters can exist in a packet. What happens if a middle box wants to add one of these and cannot do so because it already exists?" The document seems to require some modifications. Currently the definition says that there can be either one signed or one unsigned echo request. To support (multiple) middle-boxes, this should be modified so that the packet can contain zero or more unsigned echo requests, even if there is already one signed echo request in the packet. Is there any problems with multiple echo requests in one packet arriving at the HIP host? It just has to respond to all of them. Checksum calculations and signatures should be handled correctly using the current HIP base definitions. If the following modification is ok, do we need even more description about the possible middle-box operation (adding / removing parameters) or is this enough? Modified text: 5.2.18. ECHO_REQUEST_UNSIGNED ... Type 63661 Length variable Opaque data Opaque data, supposed to be meaningful only to the node that sends ECHO_REQUEST_UNSIGNED and receives a corresponding ECHO_RESPONSE_UNSIGNED. The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters MAY be used for any purpose where a node wants to carry some state in a request packet and get it back in a response packet. The ECHO_REQUEST_UNSIGNED is not covered by the HMAC and SIGNATURE. A HIP packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. It is possible that middle-boxes add ECHO_REQUEST_UNSIGNED parameters in HIP packets passing by. The sender has to create the Opaque field so that it can later identify the corresponding ECHO_RESPONSE_UNSIGNED parameter. The ECHO_REQUEST_UNSIGNED parameter MUST be responded with an ECHO_RESPONSE_UNSIGNED parameter. 5.3.2. R1 - the HIP Responder Packet ... IP ( HIP ( [ R1_COUNTER, ] ... <, ECHO_REQUEST_UNSIGNED >i) 5.3.3. I2 - the Second HIP Initiator Packet ... IP ( HIP ( [R1_COUNTER,] ... <, ECHO_RESPONSE_UNSIGNED>i ) ) BR, Petri -- Petri Jokela Phone: +358 44 299 2413 Research Scientist Fax: +358 9 299 3535 Ericsson Research, NomadicLab E-mail: petri.jokela@nomadiclab.com Finland _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri May 25 08:26:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYsI-0003wG-Gl; Fri, 25 May 2007 08:26:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrYsG-0003rj-Sm for hipsec@ietf.org; Fri, 25 May 2007 08:26:28 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrYsF-0003jc-CP for hipsec@ietf.org; Fri, 25 May 2007 08:26:28 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 8F57D2D02; Fri, 25 May 2007 15:26:24 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 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 B7A982CCB; Fri, 25 May 2007 15:26:22 +0300 (EEST) Date: Fri, 25 May 2007 15:26:22 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Petri Jokela Subject: Re: [Hipsec] HIP Base draft - ECHO signed/unsigned issue In-Reply-To: <4656CF92.5060104@nomadiclab.com> Message-ID: References: <4656CF92.5060104@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: hipsec@ietf.org, Sam Hartman X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Fri, 25 May 2007, Petri Jokela wrote: Hi, I think the editorial modification you proposed is fine. I don't see any issues in having multiple ECHO parameters within a single message. > Hello everybody, > > During IESG evaluation, the following comment (among others) was given > by Sam: > > "In a discussion with secdir, Pekka N said that one of the motivations > behind the unsigned echo and echo response is for middleboxes. I > don't think this is well defined enough to be interoperable as only > one of these parameters can exist in a packet. What happens if a > middle box wants to add one of these and cannot do so because it > already exists?" > > The document seems to require some modifications. > > Currently the definition says that there can be either one signed or one > unsigned echo request. To support (multiple) middle-boxes, this should > be modified so that the packet can contain zero or more unsigned echo > requests, even if there is already one signed echo request in the > packet. Is there any problems with multiple echo requests in one packet > arriving at the HIP host? It just has to respond to all of them. > > Checksum calculations and signatures should be handled correctly using > the current HIP base definitions. > > If the following modification is ok, do we need even more description > about the possible middle-box operation (adding / removing parameters) > or is this enough? Modified text: > > 5.2.18. ECHO_REQUEST_UNSIGNED > ... > Type 63661 > Length variable > Opaque data Opaque data, supposed to be meaningful only to the > node that sends ECHO_REQUEST_UNSIGNED and receives a > corresponding ECHO_RESPONSE_UNSIGNED. > > The ECHO_REQUEST_UNSIGNED and corresponding echo response parameters MAY > be used for any purpose where a node wants to carry some state in a > request packet and get it back in a response packet. The > ECHO_REQUEST_UNSIGNED is not covered by the HMAC and SIGNATURE. A HIP > packet can contain one or more ECHO_REQUEST_UNSIGNED parameters. It is > possible that middle-boxes add ECHO_REQUEST_UNSIGNED parameters in > HIP packets passing by. The sender has to create the Opaque field so > that it can later identify the corresponding ECHO_RESPONSE_UNSIGNED > parameter. > > The ECHO_REQUEST_UNSIGNED parameter MUST be responded with an > ECHO_RESPONSE_UNSIGNED parameter. > > > > 5.3.2. R1 - the HIP Responder Packet > ... > IP ( HIP ( [ R1_COUNTER, ] > ... > <, ECHO_REQUEST_UNSIGNED >i) > > > 5.3.3. I2 - the Second HIP Initiator Packet > ... > IP ( HIP ( [R1_COUNTER,] > ... > <, ECHO_RESPONSE_UNSIGNED>i ) ) > > > > BR, Petri > > -- > Petri Jokela Phone: +358 44 299 2413 > Research Scientist Fax: +358 9 299 3535 > Ericsson Research, NomadicLab E-mail: petri.jokela@nomadiclab.com > Finland > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec > -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 29 01:24:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsuBd-00078F-UI; Tue, 29 May 2007 01:24:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsuBb-00077s-Q4; Tue, 29 May 2007 01:23:59 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsuBZ-00058A-Kw; Tue, 29 May 2007 01:23:59 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l4T5NoFC013469; Tue, 29 May 2007 08:23:50 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l4T5NnqA013466; Tue, 29 May 2007 08:23:50 +0300 Date: Tue, 29 May 2007 08:23:49 +0300 (EEST) From: Pekka Savola To: ietf@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.2/3315/Tue May 29 03:04:17 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: hipsec@ietf.org Subject: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 14 May 2007, The IESG wrote: > The IESG has received a request from the Host Identity Protocol WG (hip) > to consider the following document: > > - 'Host Identity Protocol (HIP) Domain Name System (DNS) Extensions ' > as an Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2007-05-28. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-hip-dns-09.txt It's still May 28th in some parts of the world, I guess :-) Here's my review. I wonder if there are privacy or operational considerations with publishing one's rendezvous servers in the DNS, but I can't think of anything serious. I wonder if there are precedents to publishing similar "proxy" configurations in the DNS, and whether there is anything to learn of past experiences with that. My main issues are with expressing HIT in the wire format, and a doubt about whether an authoritative DNS servers must support Base{16,64} algorithms and how to apply them to create wire-representation of HIP RR zone data, i.e., can any authoritative DNS server implementation _today_ support HIP RRs? substantial ----------- 1) what if HIP RRs are not queried first? In the following we assume that the initiator first queries for HIP resource records at the responder FQDN. ==> what if it does not? Should you phrase this differently, i.e., as a mandatory requirement for the implementations that conform to this spec? On the other hand, if it's not a mandatory requirement, then you should describe how this will work, at least on a high level. (There is a reason I ask this: some implementations already look up A records before AAAA records to prevent damage from badly behaving DNS implementations; I'd expect that a resolver might do the same with HIP RRs.) 2) usage scenarios Depending on the combinations of answers the situations described in Section 3.1 and Section 3.2 can occur. ... 3.1. Simple static singly homed end-host 3.2. Mobile end-host ==> these are the two described usage scenarios. I was left wondering a bit what about the rest, for example, a dual-homed (static) end-host. I guess that scenario is similar to the mobile end-host. I further guess the list of scenarios is not meant to be exhaustive but more explicit text might not hurt. 3) a premature optimization of HIT lookup tags Upon return of a HIP RR, a host MUST always calculate the HI- derivative HIT to be used in the HIP exchange, as specified in Section 3 of the HIP base specification [I-D.ietf-hip-base], while the HIT possibly embedded along SHOULD only be used as an optimization (e.g. table lookup). .. and in section 8.2: [...] This is why a HIP end-node implementation SHOULD NOT authenticate its HIP peers based solely on a HIT retrieved from the DNS, but SHOULD rather use HI- based authentication. ==> this seems like a premature optimization. The cost of producing a hash of a public key is irrelevant compared to the computing overhead and latency caused by DNS lookups. As such, using the HIT as an on-the-wire optimization should probably be removed from the spec. It should also be removed from the resource record format as well as from the wire. The problem if we go forward as it is, is what to do with this extra information. We could make it stronger (e.g., "MUST ignore") but then it would be only wasted bits. If there aren't too many implementations already (given that the RR type hasn't been allocated) this might be changeable. If you go forward as it is, I think the spec needs to be more explicit on 1) what happens when HIT received from the DNS does not match the hash but the hash is checked; 2) what are the threats if HIT is used as-is without hash-checking (as allowed by the spec at the moment) when a) the DNS-HIT points to something used by another HI, and b) the DNS-HIT doesn't exist. 4) more protective specification needed Section 5 The HIT length, PK algorithm, PK length, HIT and Public Key field are REQUIRED. The Rendezvous Servers field is OPTIONAL. Section 5.6 The domain names MUST NOT be compressed. ==> this spec is written to be conservative what it generates, but receiver behaviour on malformed behaviour is unspecified. Does it need to be? 5) HIP wire format vs zone representation The HIT field is represented as the Base16 encoding [RFC4648] (a.k.a. hex or hexadecimal) of the HIT. The encoding MUST NOT contain whitespaces to be able to distinguish it from the public key field. The Public Key field is represented as the Base64 encoding [RFC4648] of the public key. The encoding MUST NOT contain whitespace(s) to be able to distinguish from the Rendezvous Servers field. ==> I may me misunderstanding this, but doesn't that imply that the authoritative DNS servers must implement Base16 and Base64 decoding support so that they can convert from BaseXX to the on-the-wire format? Is this a new requirement on DNS nameserver implementations, or are DNS servers already required to do it? Is this a typical way to represent and distribute binary data on DNS? Does this require the authoratative DNS server to know how to parse the zone representation format, i.e., "support for HIP RRs"? My question here would be, how would DNS authoritative servers support HIP RRs under RFC3597 ("Handling of Unknown DNS Resource Record (RR) Types")? editorial --------- o A set of IP address(es) through A [RFC1035] and AAAA [RFC3596] RR sets (RRSets [RFC2181]). ==> you'll probably want to rephrase this as: o A set of IP address(es) through A [RFC1035] and AAAA [RFC3596] resource record sets (RRSets [RFC2181]). .. or remove "(RRsets ..") and just keep the 2181 reference. The RDATA for a HIP RR consists of a public key algorithm type, the HIT length, a HIT, a public key, and optionally one or more rendezvous server(s). ==> s/algorithm type/algorithm type and length/ The complete representation of the HPIHI record is: ==> s/HPIHI/HIPHI/ (?) -- the same elsewhere The HIP RR contains public keying material in the form of the named peer's public key (the HI) and its secure hash (the HIT). Both of these are not sensitive to attacks where an adversary gains knowledge of them. ==> s/Both of these are not/Neither of these are/ ? Hannu Flinck, Olafur Gu[eth]mundsson, Tom Henderson, Peter Koch, Olaf ==> Olafur's surname might need ascii-fication.. Julien Laganier is partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks project or the European Commission. ==> is such a long boilerplate really necessary? I'd hate to start seeing these on each I-D, for each author for different sponsors, etc. A shorter, 3 lines maximum, acknowledgement should be sufficient. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 29 05:49:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsyKq-0005TK-9Z; Tue, 29 May 2007 05:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsyKp-0005Rh-Om for hipsec@lists.ietf.org; Tue, 29 May 2007 05:49:47 -0400 Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HsyKo-00021o-Do for hipsec@lists.ietf.org; Tue, 29 May 2007 05:49:47 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 6D2332CBE; Tue, 29 May 2007 12:49:43 +0300 (EEST) X-Spam-Checker-Version: SpamAssassin 3.2.0-niksula20070322 (2007-05-01) on twilight.cs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.2.0-niksula20070322 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 EFEA72C86 for ; Tue, 29 May 2007 12:49:42 +0300 (EEST) Date: Tue, 29 May 2007 12:49:42 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: hipsec@lists.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: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Hipsec] hip-nat-traversal-02-pre5 X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi folks, here is a preversion of ICE-based NAT traversal draft: http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre5.txt I rewrote it practically from scratch, so the text is not very well polished yet (work in progress). Please send early comments already now to the mailing list. -- Miika Komu http://www.iki.fi/miika/ _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 29 09:10:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1Sk-0004aK-OL; Tue, 29 May 2007 09:10:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht1Sj-0004aB-9Z; Tue, 29 May 2007 09:10:09 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht1Sh-0001lx-S3; Tue, 29 May 2007 09:10:09 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 69D05212E13; Tue, 29 May 2007 16:10:06 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 33AAA212DFC; Tue, 29 May 2007 16:10:06 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6498B3B5-3627-4959-9051-3C288647C97D@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC Date: Tue, 29 May 2007 16:10:02 +0300 To: Pekka Savola X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: hipsec@ietf.org, ietf@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Hi Pekka, I don't have answers to all of your questions/remarks, but I'd take forward a few: > 1) what if HIP RRs are not queried first? > > In the following we assume that the initiator first queries for HIP > resource records at the responder FQDN. > > ==> what if it does not? Remember that this is an experimental spec. So, taking it the reverse, why should id specify what to do if someone has a reason to do it in another way? I don't see any specific reason to make any MUSTs or even SHOULDs here: I don't see here any danger for the Internet nor interoperability. But maybe I just don't understand the dangers you have in your mind. > 3) a premature optimization of HIT lookup tags > > Upon return of a HIP RR, a host MUST always calculate the HI- > derivative HIT to be used in the HIP exchange, as specified in > Section 3 of the HIP base specification [I-D.ietf-hip-base], while > the HIT possibly embedded along SHOULD only be used as an > optimization (e.g. table lookup). > > .. and in section 8.2: > > [...] This is why a HIP > end-node implementation SHOULD NOT authenticate its HIP peers based > solely on a HIT retrieved from the DNS, but SHOULD rather use HI- > based authentication. > > ==> this seems like a premature optimization. Note that these RRs may need to be indexed also by other boxes but the end-nodes. For them, using the HIT as an index and doing a simple memory comparison instead of calculating a hash may be a win. Further note that both the sections you quote above discuss only host/ end-note behaviour. > If you go forward as it is, I think the spec needs to be more > explicit on 1) > what happens when HIT received from the DNS does not match the hash > but the hash > is checked; I agree. FWIW, either ignore the HIT or drop the record. I think the latter would be the right option, but I may be wrong. > 2) what are the threats if HIT is used as-is without > hash-checking (as allowed by the spec at the moment) when a) the > DNS-HIT > points to something used by another HI, and b) the DNS-HIT doesn't > exist. I don't understand what you are saying here. --Pekka (the other one) _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 29 15:09:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht74l-0007wd-3a; Tue, 29 May 2007 15:09:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht74k-0007wX-Kr for hipsec@lists.ietf.org; Tue, 29 May 2007 15:09:46 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht74i-0008WK-QW for hipsec@lists.ietf.org; Tue, 29 May 2007 15:09:46 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 29 May 2007 12:09:40 -0700 X-IronPort-AV: i="4.14,589,1170662400"; d="scan'208"; a="158539195:sNHT66500685" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l4TJ9eWE019528; Tue, 29 May 2007 12:09:40 -0700 Received: from dwingwxp ([10.32.240.194]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l4TJ9dV1000272; Tue, 29 May 2007 19:09:39 GMT From: "Dan Wing" To: "'Miika Komu'" Subject: RE: [Hipsec] hip-nat-traversal-02-pre5 Date: Tue, 29 May 2007 12:09:39 -0700 Message-ID: <092601c7a224$e8522b50$c6f0200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: Thread-Index: Aceh1rhFaZHV6m6ZSvu+0tvz+OpX5wANiXZg DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11475; t=1180465780; x=1181329780; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Hipsec]=20hip-nat-traversal-02-pre5 |Sender:=20; bh=0+WoeShTxg4wsnEyLSgnRbkqRsa1iGxCnAY6Jx514aM=; b=AsLitrKZi4d0A68gIU1eepxZj59TF0EHObYdZfPyzkqq1AehiRWvY0rt/JTm9iOcysbf4RMv QgnVUI2VQSl8uYjacHM329JDbPf5qpMy0A+xTKGtIjMgwgiZejrs/B1E; Authentication-Results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c Cc: simon.schuetz@netlab.nec.de, hipsec@lists.ietf.org, 'Jonathan Rosenberg' X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org Thanks for the opportunity to review this document before publication. Comments: 1. section 3: This section describes NAT traversal between two HIP end-hosts. A successful NAT traversal requires at least the Responder to register to a relay server. The base exchange is relayed through the relay server. In the introduction you described three cases -- where the initiator is behind a NAT, where the terminator is behind a NAT, and where both are behind (different) NATs. In the second case, where the terminator (HIP Responder, I presume?) is not behind a NAT but is on a public network, is it true that it still needs to register to a relay server? 2. section 3: The end-hosts need a fixed transport layer port number to be able to communicate with each other. The end-hosts MUST accept incoming HIP and ESP traffic arriving at UDP port 50500 (future extensions may use the same port number for TCP). It is RECOMMENDED that an Initiator selects a random port number between 49152-65535 for initiating a base exchange even for registration. However, the allocated port MUST be maintained until all of the corresponding Host Associations are closed. Alternatively, a host MAY also use source port 50500 for initiating a base exchange. The RECOMMENDED transport layer protocol is UDP. >From this requirement, I can only assume that HIP doesn't communicate the port number across th HIP rendezvous server. Is my assumption corrrect? 3. section 3.1: When the ESP relay registration was successful, the relay server uses the source IP address and port (typically 50500) of the R2 to relay ESP traffic with the client. This address-port pair of the relay is referred as "leased transport locator" in this document. Please delete "(typically 50500)", because earlier text allows using 50500 as the source address or using the 49152-65535 range as the source address. But more importantly, a NAT may be unable to retain whatever UDP port the host chose because another host is already using that same UDP port, or because the NAT doesn't like to retain source UDP ports. So -- what is the significance of this choice of ephemeral port? 4. Section 3.2: The relay MUST change the transport source and destination of the message to match the one the Responder used when registrating to the relay. Does this mean the relay spoofs the IP address? That is how I read it... If you're referring to transport source and destination addresses inside of HIP itself, the text needs to be clarified. If you really do want the relay to spoof IP addresses, I think the design is flawed. 5. Section 3.2: The base exchange was concluded by I2 and R2 messages over transport layer that contained RELAY_TO parameters. After this, the state of the HIP associations is ESTABLISHED, but the hosts MUST NOT allow any ESP traffic until the connectivity tests described in the next section are performed successfully. But the next section (3.3) describes cases where there aren't connectivity tests, even if there was a RELAY_TO. This needs to be cleaned up. I suggest moving the last two paragraphs of 3.2 into 3.3, and not described ESTABLISHED as some-state-that-isn't-quite-like-ESTABLISHED. I think you need to transition to a different state (such as perhaps UNVERIFIED?), and describe the rules for when you enter that state and when you can skip that state and go directly to ESTABLISHED. 6. Section 3.2: I don't think the FROM_PEER is sufficient to identify peers. Consider, for example, that almost every consumer-grade NAT in the world uses 192.168.1.0 as its private (internal) network, and the first host is typically assigned 192.168.1.1, the second host .2, and so forth. Two HIP hosts behind their own NATs could easily have the same private IP address, and could be trying to establish communication with each other. In this case, FROM_PEER isn't useful to distinguish connectivity checks from yourself versus from your peer. Rather than using IP address, ICE uses a USERNAME, half of which is chosen by each peer, to provide this distinguisher. I suggest using a peer-selected value to identify each peer is superior to IP address as a peer identifier. 7. Section 3.3: If the FROM_PEER and TO_PEER do not match, the Responder is behind a "p2p-unfriendly" NAT [I-D.ietf-behave-p2p-state]. I believe there are two cases where you'll still encounter that situation, even if you are behind 100% p2p-friendly NATs. Case 1: you're behind two p2p-friendly NATs ("nested NATs"). Case 2: if you have a network topology like this, with 100% p2p-friendly NATs, I believe they'll also not match: Rendezvous Server / \ / \ / \ Intiator------------NAT----Router | Responder That is, where a NAT is only on-path between the Initator and Responder, but isn't on-path between Responder and its Rendezvous Server. There could be a different NAT that is on-path between the Responder and its Rendezvous Server. Such a situation can occur (and does occur) with NATs inside enterprises. This situation is why ICE has 'triggered checks': for situations where the ICE endpoint doesn't know its traffic will traverse a NAT because the NAT isn't on-path with the ICE endpoint's STUN server. I encourage you to not use IP addresses as identifiers, especially for NAT traversal. 8. The first paragraph of section 3.3 burdens public hosts with NAT keepalives: They MUST NOT follow the extensions of this draft, except for the NAT keepalives described in a later section. You don't need to create that burden: only the hosts behind NATs need to be burdened with keeping their NAT pinholes alive. 9. The NAT keepalive section (section 3.6) needs to describe how often the keepalives need to be sent. As I mentioned above, you don't need to burden everyone with NAT keepalives -- just the hosts that are behind NATs. 10. Section 5, firewall traversal: There is an odd statement about NAT traversal that is included in the firewall traversal section: The NAT traversal mechanisms described in Section 3 require that the firewall - stateful or not - allow inbound UDP traffic to port 50500 and allow outbound UDP traffic to arbitrary UDP ports. If necessary for firewall traversal, ports reserved for IKE MAY be used for initiating new connections, but the implementation MUST be able to listen for UDP packets from port 50500. This needs to be made clearer. Here is an example of a topology that wouldn't work if all the firewall did was the above paragraph: Rendezvous Server \ \ Firewall | NAT | Responder The Rendezvous server would listen for traffic on UDP/50500. --- Nits: Nit 1: Introduction: This document specifies how HIP can traverse through such NAT middleboxes which are neither HIP-aware or ESP-aware without manual configuration of the NAT devices. You're using the term "NAT middlebox" and "NAT devices" in the same sentence. You should use one. I also found the "without manual configuration" awkward to read; inserting a comma might help separate out the two awareness clauses. Like this: ... neither HIP-aware or ESP aware, without manual ... ^ Nit 2: The paragraph starting with: "The new namespace of HIP has some additional benefits." seems to need a transitional phrase or something; it sort of sticks out there by itself. I think before that paragraph you need an introductory paragraph describing the "HIP namespace". Nit 3: OLD: The protocol extensions in this document make NEW: The HIP extensions in this document make ^^^ Nit 4: OLD: the behavior of the NAT devices to make NAT traversal to work even NEW: the behavior of the NAT devices so that NAT traversal will work even ^^^^^^^ ^^^^ Nit 5: Instead of repeating the procedure to choose the source port (50500 or in that port range), how about describing it once in a tiny section and then referring to that section everywhere in the document. It would be useful if the suggestion for 49152-65535 was clarified: does something break if I were to use 49151, for example? (I found a discussion in section 5, "firewall traversal", which seemed to describe why the selection of source port was useful. This should be consolidated into one place.) Nit 6: Section 3.2: The source port is chosen randomly between the range 49152-65535 and destination port is 50500. The destination address is the relay address. The source address is one of the addresses of the link, which are also referenced to as "unreflexive locators" in ^^^^^^^^ this document. "Links" don't have addresses; I think this should be 'one of the routable addresses for the host' or something like that?? (I'm not sure) Nit 7: Section 3.3: In the case of direct path, the hosts prefer a path without transport layer encapsulation which means that the hosts have no legacy NAT between them. This encapsulation has not previously been described in the document. Question: is legacy NAT the only reason for UDP encapsulation? I would think a firewall that doesn't like the HIP protocol number might also be another reason. And perhaps also another case is an operating system that doesn't understand HIP, where HIP is done entirely by the application? I do not know HIP well enough to answer these two questions. Nit 8: Section 3.3: The Initiator MUST pace the NOTIFY messages sequentially 20 ms apart (as explained in [I-D.ietf-mmusic-ice]). FYI, this ICE pacing algorithm is going to be changed. See Sally Floyd's response to my email about those upcoming changes at: http://www1.ietf.org/mail-archive/web/tsv-area/current/msg00085.html Nit 9: section 8: Thanks for Jonathan Rosenberg and the rest of the ICE WG folks for the excellent work on ^^^^^^ ICE. ICE is a product of the MMUSIC working group. -d > -----Original Message----- > From: Miika Komu [mailto:miika@iki.fi] > Sent: Tuesday, May 29, 2007 2:50 AM > To: hipsec@lists.ietf.org > Subject: [Hipsec] hip-nat-traversal-02-pre5 > > Hi folks, > > here is a preversion of ICE-based NAT traversal draft: > > http://www.iki.fi/miika/docs/draft-ietf-hip-nat-traversal-02-pre5.txt > > I rewrote it practically from scratch, so the text is not very well > polished yet (work in progress). Please send early comments > already now > to the mailing list. > > -- > Miika Komu > http://www.iki.fi/miika/ > > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 29 16:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht89C-0003jP-8R; Tue, 29 May 2007 16:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ht7tH-0000BT-Gv; Tue, 29 May 2007 16:02:00 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ht7qs-0001pB-2G; Tue, 29 May 2007 15:59:37 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l4TJwN4F011586; Tue, 29 May 2007 22:58:23 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l4TJwNiF011583; Tue, 29 May 2007 22:58:23 +0300 Date: Tue, 29 May 2007 22:58:23 +0300 (EEST) From: Pekka Savola To: Pekka Nikander Subject: Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC In-Reply-To: <6498B3B5-3627-4959-9051-3C288647C97D@nomadiclab.com> Message-ID: References: <6498B3B5-3627-4959-9051-3C288647C97D@nomadiclab.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.2/3315/Tue May 29 03:04:17 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: hipsec@ietf.org, ietf@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Tue, 29 May 2007, Pekka Nikander wrote: > I don't have answers to all of your questions/remarks, but I'd take forward a > few: > >> 1) what if HIP RRs are not queried first? >> >> In the following we assume that the initiator first queries for HIP >> resource records at the responder FQDN. >> >> ==> what if it does not? > > Remember that this is an experimental spec. So, taking it the reverse, why > should id specify what to do if someone has a reason to do it in another way? > > I don't see any specific reason to make any MUSTs or even SHOULDs here: I > don't see here any danger for the Internet nor interoperability. But maybe I > just don't understand the dangers you have in your mind. I have personally no big problems if the spec were to say that "HIP-after-A-or-AAAA" were to be left out of scope of this document. However, what I'm a bit uncomfortable with is that this assumption is apparently made in Section 3, "Usage Scenarios", which seems to be a section with no normative content. As such I believe such a statement/assumption (if made) should be made in a more prominent place in the spec. >> 3) a premature optimization of HIT lookup tags >> >> Upon return of a HIP RR, a host MUST always calculate the HI- >> derivative HIT to be used in the HIP exchange, as specified in >> Section 3 of the HIP base specification [I-D.ietf-hip-base], while >> the HIT possibly embedded along SHOULD only be used as an >> optimization (e.g. table lookup). >> >> .. and in section 8.2: >> >> [...] This is why a HIP >> end-node implementation SHOULD NOT authenticate its HIP peers based >> solely on a HIT retrieved from the DNS, but SHOULD rather use HI- >> based authentication. >> >> ==> this seems like a premature optimization. > > Note that these RRs may need to be indexed also by other boxes but the > end-nodes. For them, using the HIT as an index and doing a simple memory > comparison instead of calculating a hash may be a win. Further note that > both the sections you quote above discuss only host/end-note behaviour. This is makes me even more afraid. If most end-nodes use mechanism A but others are expected to maybe use another mechanism B, I foresee problems with both mechanisms especially in middleboxes. It certainly won't improve the reliability of the protocol.. >> If you go forward as it is, I think the spec needs to be more >> explicit on 1) what happens when HIT received from the DNS does not >> match the hash but the hash is checked; > > I agree. FWIW, either ignore the HIT or drop the record. I think the latter > would be the right option, but I may be wrong. > >> 2) what are the threats if HIT is used as-is without >> hash-checking (as allowed by the spec at the moment) when a) the DNS-HIT >> points to something used by another HI, and b) the DNS-HIT doesn't exist. > > I don't understand what you are saying here. Maybe I was trying to be too terse or I'm missing an assumption about how HIT vs HI is validated in other parts of HIP infrastructure. Let's say I publish a HIPRR with HIT=hash(Y) and HI=X. Someone else has HI=Y, and I choose HIT above so that HIT=hash(Y), i.e., create an intentional conflict. Given that the spec does not mandate that the implementations check that HIT will correspond to the HI, what's going to happen in this case? Will a middlebox overwrite the index at hash(Y) with HI=X? If yes, what is the result? Will it be a DoS on the host that used HI=Y? That was the scenario 2.a) above and 2.b) is when HITs don't conflict (a more trivial case) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 30 03:25:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtIYt-0007xA-2e; Wed, 30 May 2007 03:25:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtIYq-0007wm-O0; Wed, 30 May 2007 03:25:36 -0400 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtIYq-0006Rx-3h; Wed, 30 May 2007 03:25:36 -0400 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.13.8/8.13.8) with ESMTP id l4U7PSsu027253; Wed, 30 May 2007 10:25:29 +0300 Received: from localhost (pekkas@localhost) by netcore.fi (8.13.8/8.13.8/Submit) with ESMTP id l4U7PSQ2027250; Wed, 30 May 2007 10:25:28 +0300 Date: Wed, 30 May 2007 10:25:28 +0300 (EEST) From: Pekka Savola To: ietf@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.90.2/3324/Wed May 30 03:51:08 2007 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED, AWL, BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: hipsec@ietf.org Subject: [Hipsec] Re: Last Call: draft-ietf-hip-applications (Using the Host Identity Protocol with Legacy Applications) to Experimental RFC X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org On Mon, 14 May 2007, The IESG wrote: > The IESG has received a request from the Host Identity Protocol WG (hip) > to consider the following document: > > - 'Using the Host Identity Protocol with Legacy Applications ' > as an Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2007-05-28. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. Some slightly late comments below. My main (meta-) issue with the draft is that it's not clear from how the draft is written what is the goal of the draft. It seems it's providing an informative overview of different approaches for HIP experiments; it does not aim to provide any normative specification for HIP implementations or applications, even to make the experiments using different approaches to use more uniform methods. Is this correct? If yes, maybe this could be made more explicit, e.g., by adding 'Overview on' at the start of the title and similar other modifications. On the other hand, if this spec is intended to be used somehow by HIP or application implementations, I believe text would likely need significant rework; there is very little explicit guidance or explicit specification as it is and very little text that would help in creating interoperable implementations. substantial ----------- While the text below concentrates on the use of the sockets connect system call, the same argument is also valid for other system calls using socket addresses. ==> I'm not sure if I will accept this assumption at its face value without a reference. Are you sure all the socket-operating system calls are basically equivalent? Has this been studied somewhere (Miika/Mika's Master's thesis as one example?) more extensively? For example, what does listen(LSI) or bind(LSI) mean? Section 3.4 seems to discuss this a bit implying that all the socket system calls aren't necessarily similar. Using DNS to map IP addresses to HIs: If the responder has host identifiers registered in the forward DNS zone and has a PTR record in the reverse zone, the initiating system could perform a reverse+forward lookup to learn the HIT associated with the address. [...] ==> does this cause a recursion problem with DNS resolver IP addresses? I.e., you try to look up HIP records by reverse+forward of node X by doing queries to DNS servers A and B, but end up querying DNS reverse+forward records of A and B through DNS first. I think this should work under normal circumstances but I can see some potential reliability issues; at least if the DNS server addresses are provisioned with HIP records but they don't support HIP, you might end up hosing all your DNS lookups if the fallback from trying HIP to no-HIP isn't reliable. Is there already sufficient experience of these kind of potential bootstrap problems? Is a warning that such a bootstrap mechanism may want to avoid looking up DNS server addresses warranted? DNS with security extensions (DNSSEC) [6], if trusted, may be able to provide some additional initial authentication, but at a cost of initial resolution latency. ==> maybe remove 'additional' as it appears opportunistic HIP has no initial authentication at all as described in the previous sentence. It might also be useful to quantify 'some' as I belive it's not clearly discussed anywhere though more generic and longer text can probably be found in DNSSEC documents; security considerations only mentions that 'if DNSSEC zones are considered trustworthy enough'. Basically as you describe using DNSSEC with reverse DNS, the delegation chain from the reverse IP root should be trusted (typical trust anchor issues) but this is not typically an issue; and that the DNS zone administrators in charge of the netblock should be trusted to put in the right information. editorial --------- upgraded. This informational document discusses implementation and API issues relating to using HIP in situations in which the system is ==> spell out 'API' (done in Introduction but not here apparently) Fully deployed, the HIP architecture will permit applications to explicitly request the ==> feeling optimistic? :-) Maybe 'would' would be slightly more neutral (Section 1.1.6 of [2]) in that the ESP association formed by HIP is ==> spell out ESP. [3] Nikander, P., "An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)", draft-laganier-ipv6-khi-07 (work in progress), February 2007. ==> RFC now. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 30 04:20:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJQ0-0008Le-DF; Wed, 30 May 2007 04:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtJPy-0008JM-A3; Wed, 30 May 2007 04:20:30 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtJPx-0003dQ-RW; Wed, 30 May 2007 04:20:30 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0E58F212E13; Wed, 30 May 2007 11:20:28 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A2AE3212DFC; Wed, 30 May 2007 11:20:27 +0300 (EEST) In-Reply-To: References: <6498B3B5-3627-4959-9051-3C288647C97D@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E351801-AD14-4F2D-9ACD-1357D855EF3F@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol (HIP) Domain Name System (DNS) Extensions) to Experimental RFC Date: Wed, 30 May 2007 11:20:26 +0300 To: Pekka Savola X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: hipsec@ietf.org, ietf@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org >>> 1) what if HIP RRs are not queried first? > > I have personally no big problems if the spec were to say that "HIP- > after-A-or-AAAA" were to be left out of scope of this document. > > However, what I'm a bit uncomfortable with is that this assumption > is apparently made in Section 3, "Usage Scenarios", which seems to > be a section with no normative content. As such I believe such a > statement/assumption (if made) should be made in a more prominent > place in the spec. A suitable restriction of the scope, at an appropriate place, would be fine with me. >>> 3) a premature optimization of HIT lookup tags >>> >>> Upon return of a HIP RR, a host MUST always calculate the HI- >>> derivative HIT to be used in the HIP exchange, as specified in >>> Section 3 of the HIP base specification [I-D.ietf-hip-base], >>> while >>> the HIT possibly embedded along SHOULD only be used as an >>> optimization (e.g. table lookup). >>> .. and in section 8.2: >>> >>> [...] This is why a HIP >>> end-node implementation SHOULD NOT authenticate its HIP peers >>> based >>> solely on a HIT retrieved from the DNS, but SHOULD rather use HI- >>> based authentication. >>> ==> this seems like a premature optimization. >> >> Note that these RRs may need to be indexed also by other boxes but >> the end-nodes. For them, using the HIT as an index and doing a >> simple memory comparison instead of calculating a hash may be a >> win. Further note that both the sections you quote above discuss >> only host/end-note behaviour. > > This is makes me even more afraid. If most end-nodes use mechanism > A but others are expected to maybe use another mechanism B, I > foresee problems with both mechanisms especially in middleboxes. > It certainly won't improve the reliability of the protocol.. So, maybe add a paragraph about the usability of the HIT for middle boxes. IIRC, the context of discussion was HIP-aware firewalls. Such firewalls could simply snoop HIT RRs as they pass by (or even query them if there is a suitable reverse DNS hierarchy, which the draft does NOT specify, IIRC). Then, when they see HIP I2/R2 packets passing by, they could use the cached keys, as indexed by the HITs, to verify the signatures in the messages. For such use, I don't see any need of verifying the cryptographic relationship between the HIT and HI. If the signatures in the I2/R2 don't match, then the firewall doesn't open the connection, and it is the user's problem. No security dangers, AFAICS. Indeed, it would be beneficial if the firewall did NOT try to establish any crypto relationship between the HIT and HI, since that would allow the relationship to evolve without mandating firewall code updates. >>> 2) what are the threats if HIT is used as-is without >>> hash-checking (as allowed by the spec at the moment) when a) the >>> DNS-HIT >>> points to something used by another HI, and b) the DNS-HIT >>> doesn't exist. >> >> I don't understand what you are saying here. > > Maybe I was trying to be too terse or I'm missing an assumption > about how HIT vs HI is validated in other parts of HIP infrastructure. > > Let's say I publish a HIPRR with HIT=hash(Y) and HI=X. Someone else > has HI=Y, and I choose HIT above so that HIT=hash(Y), i.e., create > an intentional conflict. > > Given that the spec does not mandate that the implementations check > that HIT will correspond to the HI, what's going to happen in this > case? You will fail to gain the channel binding property of HIP. In other words, you shoot to your own foot. > Will a middlebox overwrite the index at hash(Y) with HI=X? If yes, > what is the result? Will it be a DoS on the host that used HI=Y? Well, nothing if the middlebox is implemented correctly. HIT collisions are possible, anyway. Hence, in such a case the middlebox should cache both HI=X and HI=Y, indexed by the HIT. The fact that HIT!=hash(X) shouldn't matter. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 30 13:59:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtSSN-0002Ka-L3; Wed, 30 May 2007 13:59:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtSSL-0002KV-Qj for hipsec@ietf.org; Wed, 30 May 2007 13:59:33 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtSSK-0007U9-JT for hipsec@ietf.org; Wed, 30 May 2007 13:59:33 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l4UHxT3c011815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 May 2007 12:59:30 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l4UHxShL021315; Wed, 30 May 2007 10:59:28 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l4UHxNYu021085; Wed, 30 May 2007 10:59:28 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.55]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 May 2007 10:59:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol(HIP) Domain Name System (DNS) Extensions) to Experimental RFC Date: Wed, 30 May 2007 10:59:20 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB404AD7853@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Hipsec] Re: Last Call: draft-ietf-hip-dns (Host Identity Protocol(HIP) Domain Name System (DNS) Extensions) to Experimental RFC Thread-Index: AcehsZhzsJ/PNc8hQWSc0x7bETUuKgBMTA8g References: From: "Ahrenholz, Jeffrey M" To: "Pekka Savola" X-OriginalArrivalTime: 30 May 2007 17:59:20.0965 (UTC) FILETIME=[3FC7CB50:01C7A2E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: hipsec@ietf.org X-BeenThere: hipsec@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the official IETF Mailing List for the HIP Working Group." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: hipsec-bounces@lists.ietf.org > My main issues are with expressing HIT in the wire format,=20 > and a doubt=20 > about whether an authoritative DNS servers must support Base{16,64}=20 > algorithms and how to apply them to create wire-representation of HIP=20 > RR zone data, i.e., can any authoritative DNS server implementation=20 > _today_ support HIP RRs? >=20 We've implemented a previous version on this draft as a patch to ISC's BIND 9.x implementation. I don't know whether or not authoritative DNS servers are running BIND, but it does have functions such as isc_hex_totext() and isc_base64_totext() for Base(16,64) conversions. This doesn't seem very different than RFC4025 (IPSECKEY RR). -Jeff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec