From hipsec-bounces@lists.ietf.org Sun May 01 03:38:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS92F-0001KO-53; Sun, 01 May 2005 03:38:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DS92D-0001KE-Nk for hipsec@megatron.ietf.org; Sun, 01 May 2005 03:38:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02008 for ; Sun, 1 May 2005 03:38:36 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DS9Fd-0002J5-Sk for hipsec@ietf.org; Sun, 01 May 2005 03:52:30 -0400 Received: from esealmw126.eemea.ericsson.se ([153.88.254.123]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j417cTh5029121 for ; Sun, 1 May 2005 09:38:29 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 09:38:29 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.13]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sun, 1 May 2005 09:38:29 +0200 Received: from [131.160.126.43] (rvi2-126-43.lmf.ericsson.se [131.160.126.43]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EA6F518AAA for ; Sun, 1 May 2005 10:38:28 +0300 (EEST) Message-ID: <42748773.4060103@ericsson.com> Date: Sun, 01 May 2005 10:38:27 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2005 07:38:29.0584 (UTC) FILETIME=[C4B1E500:01C54E20] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] TEST, please ignore 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Testing the new HIP WG mailing list. Please ignore this message. Gonzalo HIP co-chair _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 09 13:23:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVByg-0005dm-5a; Mon, 09 May 2005 13:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVBye-0005dh-Ny for hipsec@megatron.ietf.org; Mon, 09 May 2005 13:23:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08722 for ; Mon, 9 May 2005 13:23:29 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVCDm-0001DA-UW for hipsec@ietf.org; Mon, 09 May 2005 13:39:12 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA03218; Mon, 9 May 2005 10:23:18 -0700 (PDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j49HNHG16356; Mon, 9 May 2005 12:23:17 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 10:23:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 May 2005 10:23:17 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D7EE3@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: more clarifications to the base draft Thread-Index: AcVUu8lknZvzg/GrSUSlNVYXk3PZZQ== From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" X-OriginalArrivalTime: 09 May 2005 17:23:17.0435 (UTC) FILETIME=[C9FD10B0:01C554BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org Subject: [Hipsec] more clarifications to the base 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Petri, I have some comments/suggestions after reviewing the packet formats and packet processing sections of the base draft, while going over our implementation. Checksum - It's a little confusing that the HIP header's IPV6 next header should be IPPROTO_NONE=3D59 but when computing the HIP checksum the = pseudo-header is IPPROTO_HIP=3D99. These values make sense though, so I'm not = suggesting any changes. General note: may want to consistently write "Initiator" versus "initiator", and "Responder" versus "responder" TLV format - mentions transport formats using values 2048 to 4095 "Currently, one transport format is defined: the ESP transport format [23]." What does this mean, since ESP does not use parameters that are 2048-4095? HIP_TRANSFORM Although it says there are 6 maximum suite IDs, this is for the R1, and the I2 HIP_TRANSFORM contains 1 maximum suite ID (the chosen suite actually used in the I2.) HMAC Can there be both types of ECHO_REQUESTs (covered/not covered by HMAC+SIG) in a HIP packet? In the section on the I2 Packet, the "either" hints at there being only one possible type, but I think this came up once during an interop. CER The description for this packet seems unclear and may need to be rewritten. These two statements seem slightly contradictory: (Processing incoming I1) Under no circumstances does the HIP state machine transition upon sending an R1. (R1 management) An implementation MAY keep state about received I1s and match the received I2s against the state, as discussed in Section 4.1.1. Instead of RFC 2451, when referring to AES we probably want RFC 3602. (RFC 2451 is older and contains no mention of AES.) -Jeff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri May 13 08:16:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZ5z-0007zW-I4; Fri, 13 May 2005 08:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZ5x-0007zQ-5U for hipsec@megatron.ietf.org; Fri, 13 May 2005 08:16:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08723 for ; Fri, 13 May 2005 08:16:43 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWZLq-0004XI-Cm for hipsec@ietf.org; Fri, 13 May 2005 08:33:12 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 7EE2E2E62; Fri, 13 May 2005 15:16:32 +0300 (EEST) Received: from kekkonen.cs.hut.fi (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id DDF282E40; Fri, 13 May 2005 15:16:30 +0300 (EEST) Received: (from mkomu@localhost) by kekkonen.cs.hut.fi (8.11.7p1+Sun/8.10.2) id j4DCGUc23196; Fri, 13 May 2005 15:16:30 +0300 (EEST) Date: Fri, 13 May 2005 15:16:30 +0300 (EEST) From: Miika Komu X-X-Sender: mkomu@kekkonen.cs.hut.fi To: Petri Jokela Subject: Re: [Hipsec] changes to base spec? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.3-niksula20040914 (2005-04-27) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.3-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: hipsec@ietf.org, Tuomas Aura 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Wed, 11 May 2005, Petri Jokela wrote: > Problem 1 & solution: > > Adding the nonce to I1 and R1 is not a big problem, but I currently > can't see much help of it. The attacker should know when the I1 is sent > from the initiator and send the R1 at a suitable moment. The attacker, > being not on the path, does not know when the I1 is sent, so it must > just guess when to attack. Maybe there are cases, when this is easy to > do and I just can't see them now... > > If the attacker is on the path, it gets the nonce in I1, in which case > there is naturally no protection from that. Agree, seems like this is rather difficult to achieve in practice because there are so many obstacles for the attack (prebuilt R1 lifetime, prebuilt R1 indexing based on IP addreses, guessing the proper attack time, expiration time of existing SAs). Maybe it should be at least mentioned in the appendix. -- Miika Komu miika@iki.fi 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 13 09:06:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZry-0007fb-OR; Fri, 13 May 2005 09:06:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWZrx-0007fS-Sk for hipsec@megatron.ietf.org; Fri, 13 May 2005 09:06:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12450 for ; Fri, 13 May 2005 09:06:19 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWa7s-0006U9-Ek for hipsec@ietf.org; Fri, 13 May 2005 09:22:50 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id EE856212C90 for ; Fri, 13 May 2005 16:06:08 +0300 (EEST) Message-ID: <4284A640.9010705@nomadiclab.com> Date: Fri, 13 May 2005 16:06:08 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hipsec] Pre-version: ESP and Base drafts 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, Pre-versions of both the HIP ESP and Base drafts are available at http://hip4inter.net/drafts.php draft-ietf-hip-base-03-pre130505 draft-ietf-hip-esp-00-pre130505 I didn't make diffs to previous versions, because the changes were so big= . Base draft: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The draft has been modified quite a lot since -02, b=FAt the changes are mostly related to the structure of the document. The old one was difficult to read and understand, and the new structure should be better. Thanks to Tom for the main work. I have made some modifications to the draft based on Aura's comments in their research paper. There haven't been too much discussion on the list about the proposed changes. Please read and comment now: Problem 2: the KEYMAT generation has now been modified so that I and J values are also included in the keying material generation. Due to possible rekeying, implementations must now keep the I and J values as long as the HIP association exists. Problem 6: The HI encryption is now optional. Problem 7 & 8: modifications to state machine and to packet handlings (processing I1 and I2 packets). I have not yet done anything related to problems 1, 3, 4, and 5. Please, give comments on those. Problems 3,4, and 5 seem to affect the appendix describing puzzles. ESP draft: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There are no conceptual packets any longer. Basic idea is now roughly: 1) Create HIP association as well as ESP association during base exchange (ESP SA can be with NULL encryption). This would be mandatory, and solves the problem how data packets are identified. In previous version when the ESP SA could be setup later, you couln't identify data packets after base exchange, if no ESP SA was set up (no SPIs to look at). 2) Use UPDATE to make ESP SA update, including change in transform family and rekeying. Rekeying: UPDATE(ESP_INFO, [DH]) -----------------------> UPDATE(ESP_INFO, [DH]) <----------------------- Transform update UPDATE(ESP_INFO, ESP_TRANSFORM, [DH]) ---------------------------------------> UPDATE(ESP_INFO, ESP_TRANSFORM, [DH]) <--------------------------------------- And UPDATE acks naturally in both cases. There can still be conflicting things due to big changes. Please read=20 and comment. /petri --=20 Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 16 14:44:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkZU-0002ur-OR; Mon, 16 May 2005 14:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXkZT-0002uV-0H for hipsec@megatron.ietf.org; Mon, 16 May 2005 14:44:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22132 for ; Mon, 16 May 2005 14:44:05 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXkq3-00081S-Lb for hipsec@ietf.org; Mon, 16 May 2005 15:01:16 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA17390; Mon, 16 May 2005 13:43:51 -0500 (CDT) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4GIhoN17040; Mon, 16 May 2005 11:43:50 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 16 May 2005 11:43:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Pre-version: ESP and Base drafts Date: Mon, 16 May 2005 11:42:55 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D7EF0@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Pre-version: ESP and Base drafts Thread-Index: AcVXvN4hX1rcmzMyS/6hX5au2aDPuwCiHVvQ From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" , X-OriginalArrivalTime: 16 May 2005 18:43:49.0656 (UTC) FILETIME=[331BB980:01C55A47] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I have some comments after reviewing the esp-00 draft, please see below. = I think it looks a lot better now without the conceptual packets. Petri, = I'll send an xml diff of typos/minor edits separately. - section "ESP packet processing" "As these mechanisms can be located..." - this sentence is unclear to = me, but I do not have a suggested rewrite. - For all AES references (3 occurrences), RFC 2451 should be RFC 3602; = RFC 2451 contains no mention of AES, should be removed from references - The 64-bit sequence number is interesting, but: To implement it, you = just keep an additional 32-bit counter representing the upper bits? Upon = rollover of the lower 32-bits, you increment the upper. What is the = usefulness of this? i.e. how can the replay window be enforced if it is = not part of each packet? Maybe we could have more text on this or an = appropriate reference. - For the sentence "...exchange information about the used protocols and = other...", is there another term besides "used protocols" that should be = used here, such as "transforms used"? - the key index field of the ESP_INFO parameter is mentioned for the = rekeying section, but not in the preceding section when discussing the = ESP_INFO. - When talking about the IP address to HIT conversion, what about the = IPv4 case? Should LSIs be mentioned also? - In the "finalizing rekeying" section it says to use the lowest Keymat = Index of the two ESP_INFO parameters, but earlier in the = "transform_reply" section, is says "it is RECOMMENDED that the system = use the greater value received from the peer" ??? - It should be noted somewhere that HIP packets should bypass IPsec = policies, i.e. UPDATE packet transmitted in the clear even though an = active association is in place, or all protocol 99 packets bypass IPsec = processing, etc. -Jeff > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Friday, May 13, 2005 6:06 AM > To: hipsec@ietf.org > Subject: [Hipsec] Pre-version: ESP and Base drafts >=20 >=20 > Folks, >=20 > Pre-versions of both the HIP ESP and Base drafts are available at >=20 > http://hip4inter.net/drafts.php >=20 > draft-ietf-hip-base-03-pre130505 > draft-ietf-hip-esp-00-pre130505 >=20 > I didn't make diffs to previous versions, because the changes=20 > were so big. >=20 >=20 > Base draft: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The draft has been modified quite a lot since -02, b=FAt the changes > are mostly related to the structure of the document. The old one was > difficult to read and understand, and the new structure should be > better. Thanks to Tom for the main work. >=20 > I have made some modifications to the draft based on Aura's=20 > comments in > their research paper. There haven't been too much discussion=20 > on the list > about the proposed changes. Please read and comment now: >=20 > Problem 2: the KEYMAT generation has now been modified so that I and J > values are also included in the keying material generation. Due to > possible rekeying, implementations must now keep the I and J values > as long as the HIP association exists. >=20 > Problem 6: The HI encryption is now optional. >=20 > Problem 7 & 8: modifications to state machine and to packet handlings > (processing I1 and I2 packets). >=20 > I have not yet done anything related to problems 1, 3, 4, and=20 > 5. Please, > give comments on those. Problems 3,4, and 5 seem to affect=20 > the appendix > describing puzzles. >=20 >=20 > ESP draft: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > There are no conceptual packets any longer. Basic idea is now > roughly: >=20 > 1) Create HIP association as well as ESP association during base > exchange (ESP SA can be with NULL encryption). >=20 > This would be mandatory, and solves the problem how data packets are > identified. In previous version when the ESP SA could be setup later, > you couln't identify data packets after base exchange, if no=20 > ESP SA was > set up (no SPIs to look at). >=20 > 2) Use UPDATE to make ESP SA update, including change in transform > family and rekeying. >=20 > Rekeying: > UPDATE(ESP_INFO, [DH]) > -----------------------> >=20 > UPDATE(ESP_INFO, [DH]) > <----------------------- >=20 > Transform update > UPDATE(ESP_INFO, ESP_TRANSFORM, [DH]) > ---------------------------------------> >=20 > UPDATE(ESP_INFO, ESP_TRANSFORM, [DH]) > <--------------------------------------- >=20 > And UPDATE acks naturally in both cases. >=20 > There can still be conflicting things due to big changes. Please read=20 > and comment. >=20 > /petri >=20 > --=20 > Petri Jokela Tel: +358 9 299 2413 > Research scientist Fax: +358 9 299 3535 > NomadicLab, Ericsson Research Mobile: +358 44 299 2413 > Oy L M Ericsson Ab email: petri.jokela@ericsson.com >=20 > _______________________________________________ > Hipsec mailing list > Hipsec@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/hipsec >=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 16 15:12:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXl19-0000ZB-QZ; Mon, 16 May 2005 15:12:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXl18-0000Z6-35 for hipsec@megatron.ietf.org; Mon, 16 May 2005 15:12:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26215 for ; Mon, 16 May 2005 15:12:40 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXlHh-0000xE-Tp for hipsec@ietf.org; Mon, 16 May 2005 15:29:51 -0400 Received: from [192.168.1.50] (194.2.144.31) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 425309D501ACD36D for hipsec@ietf.org; Mon, 16 May 2005 21:12:30 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] changes to base spec? User-Agent: KMail/1.7 References: <426C950A.3020706@cs.helsinki.fi> <4281FE74.2030207@nomadiclab.com> In-Reply-To: <4281FE74.2030207@nomadiclab.com> MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 16 May 2005 21:13:11 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200505162113.11273.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, On Wednesday 11 May 2005 14:45, Petri Jokela wrote: > Andrei Gurtov wrote: > > Hi, > > > > Tuomas and Aarthi wrote a paper on the Analysis of the HIP Base > > Exchange Protocol that will appear in ACISP'05, July 2005. > > http://www.cs.helsinki.fi/u/gurtov/papers/analysis_hip.pdf > > > > They suggest several changes to the HIP specs for improving > > security. Do you think we should adopt any of the changes for the > > base spec? > > Few comments: > > Problem 1 & solution: > > Adding the nonce to I1 and R1 is not a big problem, but I currently > can't see much help of it. The attacker should know when the I1 is > sent from the initiator and send the R1 at a suitable moment. The > attacker, being not on the path, does not know when the I1 is sent, > so it must just guess when to attack. Maybe there are cases, when > this is easy to do and I just can't see them now... > > If the attacker is on the path, it gets the nonce in I1, in which > case there is naturally no protection from that. There is a related problem when an opportunistic initiator tries to reach a node via its rendezvous server. The initiator sends an I1 to the NULL destination HIT at the RVS IP address, which relays it to the responder. If the responder replies an R1 directly to the initiator, there's currently no way for the initiator to identify the correct context, apart from the RVS IP address included in an optional VIA_RVS parameter. A similar problem exists if an opportunistic initiator which accept from an off-path attacker an R1 containing its HIT and a LOCATOR parameter pointing to its own location (like below in the figure 10 excerpted from hip-mm-01). Having nonce in I1/R1 would help w.r.t. to this scenario, and can be implemented with ECHO_REQUEST in I1, and an ECHO_REPLY placed after the R1's SIGNATURE. What do you think? Thanks. --julien ---------------------------------------------------------------- Initiator Responder R1 with LOCATOR <----------------------------------- record additional addresses change responder address I2 with new SPI in SPI parameter -----------------------------------> (process R2 normally) <----------------------------------- (process normally) Figure 10: LOCATOR inclusion in R1 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 17 15:41:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wq-0006kX-5c; Tue, 17 May 2005 15:41:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wn-0006gh-VB for hipsec@megatron.ietf.org; Tue, 17 May 2005 15:41:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01284 for ; Tue, 17 May 2005 15:41:42 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY8Da-0002bS-CY for hipsec@ietf.org; Tue, 17 May 2005 15:59:07 -0400 Received: from localhost (n51.nomadiclab.com [193.234.219.51]) by n2.nomadiclab.com (Postfix) with ESMTP id 69C6B212C40; Tue, 17 May 2005 22:41:23 +0300 (EEST) From: Jan Mikael Melen To: hipsec@ietf.org Subject: Re: [Hipsec] changes to base spec? Date: Tue, 17 May 2005 22:41:03 +0300 User-Agent: KMail/1.7.1 References: <426C950A.3020706@cs.helsinki.fi> <4281FE74.2030207@nomadiclab.com> <200505162113.11273.julien.IETF@laposte.net> In-Reply-To: <200505162113.11273.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505172241.11952.Jan.Melen@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, On Monday 16 May 2005 22:13, Julien Laganier wrote: > > There is a related problem when an opportunistic initiator tries to > reach a node via its rendezvous server. > > The initiator sends an I1 to the NULL destination HIT at the RVS IP > address, which relays it to the responder. If the responder replies > an R1 directly to the initiator, there's currently no way for the > initiator to identify the correct context, apart from the RVS IP > address included in an optional VIA_RVS parameter. You are probably referring to a case where RVS acts as an sentinel node for a farm of servers. This is really a special case but yes you have a valid point that in order this kind of scenario to work you would need a nonce. Perhaps the solution would be to add optional ECHO_REQUEST to I1 and a ECHO_RESPONSE that is outside the signature to R1 as you suggested. If this kind of scenario should be supported at all? Normally the destination HITs of these computer farms are probably well known. > A similar problem exists if an opportunistic initiator which accept > from an off-path attacker an R1 containing its HIT and a LOCATOR > parameter pointing to its own location (like below in the figure 10 > excerpted from hip-mm-01). Still the off-path attacker would have to know the source IP address and the HIT of the node that is sending the I1 with NULL HIT and also the timing must be correct. One can't just randomly send the R1's because if the host has not sent a I1 it will drop the packet and if the destination HIT is wrong it should drop the packet so the probability of getting these right is not really that big unless the attacker is on the path when even the nonce doesn't protect you. Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 17 15:41:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wz-0006l5-Ei; Tue, 17 May 2005 15:41:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DY7wy-0006l0-7k for hipsec@megatron.ietf.org; Tue, 17 May 2005 15:41:56 -0400 Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01302 for ; Tue, 17 May 2005 15:41:53 -0400 (EDT) Received: from localhost (n51.nomadiclab.com [193.234.219.51]) by n2.nomadiclab.com (Postfix) with ESMTP id 69C6B212C40; Tue, 17 May 2005 22:41:23 +0300 (EEST) From: Jan Mikael Melen To: hipsec@ietf.org Subject: Re: [Hipsec] changes to base spec? Date: Tue, 17 May 2005 22:41:03 +0300 User-Agent: KMail/1.7.1 References: <426C950A.3020706@cs.helsinki.fi> <4281FE74.2030207@nomadiclab.com> <200505162113.11273.julien.IETF@laposte.net> In-Reply-To: <200505162113.11273.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505172241.11952.Jan.Melen@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, On Monday 16 May 2005 22:13, Julien Laganier wrote: > > There is a related problem when an opportunistic initiator tries to > reach a node via its rendezvous server. > > The initiator sends an I1 to the NULL destination HIT at the RVS IP > address, which relays it to the responder. If the responder replies > an R1 directly to the initiator, there's currently no way for the > initiator to identify the correct context, apart from the RVS IP > address included in an optional VIA_RVS parameter. You are probably referring to a case where RVS acts as an sentinel node for a farm of servers. This is really a special case but yes you have a valid point that in order this kind of scenario to work you would need a nonce. Perhaps the solution would be to add optional ECHO_REQUEST to I1 and a ECHO_RESPONSE that is outside the signature to R1 as you suggested. If this kind of scenario should be supported at all? Normally the destination HITs of these computer farms are probably well known. > A similar problem exists if an opportunistic initiator which accept > from an off-path attacker an R1 containing its HIT and a LOCATOR > parameter pointing to its own location (like below in the figure 10 > excerpted from hip-mm-01). Still the off-path attacker would have to know the source IP address and the HIT of the node that is sending the I1 with NULL HIT and also the timing must be correct. One can't just randomly send the R1's because if the host has not sent a I1 it will drop the packet and if the destination HIT is wrong it should drop the packet so the probability of getting these right is not really that big unless the attacker is on the path when even the nonce doesn't protect you. Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 18 01:00:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGfy-0000yP-SA; Wed, 18 May 2005 01:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGfx-0000yK-7o for hipsec@megatron.ietf.org; Wed, 18 May 2005 01:00:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26648 for ; Wed, 18 May 2005 01:00:56 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYGwo-0002cL-Ux for hipsec@ietf.org; Wed, 18 May 2005 01:18:24 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D18AE89879; Wed, 18 May 2005 08:00:44 +0300 (EEST) Message-ID: <428ACC07.60000@piuha.net> Date: Wed, 18 May 2005 08:00:55 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org, "Petri Jokela (JO/LMF)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] some hip base spec nits 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Some nits that I noticed while reading the spec (looking at draft-ietf-hip-base-03-pre130505 version): > NAI Network Access Identifier, in binary > format. The > format of the NAI is login@FQDN. A reference to draft-ietf-radext-rfc2486bis-05.txt would be useful here. And I'm not sure what the "binary format" of the NAI is... suggest "Network Access Identifier [ref]." > This needs to be changed to "full3978" (and a possible update to the xml2rfc tool). > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type |C| Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > / Contents / > / +-+-+-+-+-+-+-+-+ > | | Padding | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type field is 15 bits according to this... and then later: > | | | | | > | HMAC | 65245 | 20 | HMAC based message | > | | | | authentication code, with | > | | | | key material from | > | | | | HIP_TRANSFORM | > Which seems to assume its at least 16 bits. Perhaps the picture is misaligned somehow? I think it should be 16 bits and the length field should be correspondingly smaller. --Jari _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 18 07:38:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYMsX-0007IO-4d; Wed, 18 May 2005 07:38:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYMsV-0007IJ-72 for hipsec@megatron.ietf.org; Wed, 18 May 2005 07:38:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08291 for ; Wed, 18 May 2005 07:38:17 -0400 (EDT) Received: from kulho194.adsl.netsonic.fi ([81.17.193.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYN9Q-0007se-Hi for hipsec@ietf.org; Wed, 18 May 2005 07:55:50 -0400 Received: from [192.168.1.175] (n175.local.pnr.iki.fi [192.168.1.175]) by kulho194.adsl.netsonic.fi (8.13.1/8.13.1) with ESMTP id j4IBbwXe008250; Wed, 18 May 2005 14:38:01 +0300 (EEST) (envelope-from pekka.nikander@nomadiclab.com) In-Reply-To: <428ACC07.60000@piuha.net> References: <428ACC07.60000@piuha.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] some hip base spec nits Date: Wed, 18 May 2005 14:37:52 +0300 To: Jari Arkko X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, "Petri Jokela \(JO/LMF\)" 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type |C| Length >> | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | >> | >> / Contents >> / >> / >> +-+-+-+-+-+-+-+-+ >> | | Padding >> | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type field is 15 bits according to this... and then later: > >> | | | | >> | >> | HMAC | 65245 | 20 | HMAC based message >> | >> | | | | authentication code, with >> | >> | | | | key material from >> | >> | | | | HIP_TRANSFORM >> | >> > > Which seems to assume its at least 16 bits. Perhaps the picture > is misaligned somehow? I think it should be 16 bits and the length > field should be correspondingly smaller. The C bit is counted as a part of the type. Probably a sentence somewhere is needed to clarify this. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 18 07:41:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYMvw-000084-6S; Wed, 18 May 2005 07:41:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYMvv-000079-7q for hipsec@megatron.ietf.org; Wed, 18 May 2005 07:41:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08640 for ; Wed, 18 May 2005 07:41:49 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYNCq-00082y-Uz for hipsec@ietf.org; Wed, 18 May 2005 07:59:22 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id EE89C89869; Wed, 18 May 2005 14:41:39 +0300 (EEST) Message-ID: <428B29FE.5060104@piuha.net> Date: Wed, 18 May 2005 14:41:50 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] some hip base spec nits References: <428ACC07.60000@piuha.net> <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> In-Reply-To: <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, "Petri Jokela \(JO/LMF\)" 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Pekka Nikander wrote: > The C bit is counted as a part of the type. Probably a sentence > somewhere > is needed to clarify this. Ok, that explains it. The spec may well have text about this but I just missed that. --Jari _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 18 08:29:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYNfh-0006Le-L1; Wed, 18 May 2005 08:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYNff-0006LZ-D6 for hipsec@megatron.ietf.org; Wed, 18 May 2005 08:29:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12435 for ; Wed, 18 May 2005 08:29:05 -0400 (EDT) Received: from kulho194.adsl.netsonic.fi ([81.17.193.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYNwb-0002VJ-Q1 for hipsec@ietf.org; Wed, 18 May 2005 08:46:38 -0400 Received: from [192.168.1.175] (n175.local.pnr.iki.fi [192.168.1.175]) by kulho194.adsl.netsonic.fi (8.13.1/8.13.1) with ESMTP id j4ICSuQe008311; Wed, 18 May 2005 15:28:56 +0300 (EEST) (envelope-from pekka.nikander@nomadiclab.com) In-Reply-To: <200505172241.11952.Jan.Melen@nomadiclab.com> References: <426C950A.3020706@cs.helsinki.fi> <4281FE74.2030207@nomadiclab.com> <200505162113.11273.julien.IETF@laposte.net> <200505172241.11952.Jan.Melen@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39b8e89d979a17c75bac6ddc7bc66f3b@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] changes to base spec? Date: Wed, 18 May 2005 15:28:50 +0300 To: Jan Mikael Melen X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > On Monday 16 May 2005 22:13, Julien Laganier wrote: >> >> There is a related problem when an opportunistic initiator tries to >> reach a node via its rendezvous server. >> >> The initiator sends an I1 to the NULL destination HIT at the RVS IP >> address, which relays it to the responder. If the responder replies >> an R1 directly to the initiator, there's currently no way for the >> initiator to identify the correct context, apart from the RVS IP >> address included in an optional VIA_RVS parameter. I think we should forbid that behavior. Firstly, if the destination HIT is NULL then the rendezvous server cannot reliably know to which destination the I1 is really intended to, unless it is serving just a single destination host. IMHO the right way forward here is to state (in the rendezvous doc) that if you want to support rvs with NULL dest HITs, then the return R1 *MUST* go through the rendezvous server and appear coming from the rendezvous server's IP address. Or am I missing something? > You are probably referring to a case where RVS acts as an sentinel > node for a > farm of servers. This is really a special case but yes you have a > valid point > that in order this kind of scenario to work you would need a nonce. > Perhaps > the solution would be to add optional ECHO_REQUEST to I1 and a > ECHO_RESPONSE > that is outside the signature to R1 as you suggested. If this kind of > scenario should be supported at all? Normally the destination HITs of > these > computer farms are probably well known. I have no objection in adding *optional* (for Initiator) support for that. Apparently, the support in the Responder should be RECOMMENDED or REQUIRED. I'd be in favor of making it RECOMMENDED, meaning that the Initiator must be prepared to receive an R1 without an ECHO_RESPONSE even if they sent an ECHO_REQUEST in I1. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 18 08:33:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYNjt-0007G5-AV; Wed, 18 May 2005 08:33:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYNjs-0007FC-Ie for hipsec@megatron.ietf.org; Wed, 18 May 2005 08:33:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12844 for ; Wed, 18 May 2005 08:33:27 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYO0o-0002jU-Eg for hipsec@ietf.org; Wed, 18 May 2005 08:50:59 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id CB615212C40; Wed, 18 May 2005 15:33:16 +0300 (EEST) Message-ID: <428B360C.702@nomadiclab.com> Date: Wed, 18 May 2005 15:33:16 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] some hip base spec nits References: <428ACC07.60000@piuha.net> <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> In-Reply-To: <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, "Petri Jokela \(JO/LMF\)" 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Pekka Nikander wrote: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type |C| Length | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> / Contents / >>> / +-+-+-+-+-+-+-+-+ >>> | | Padding | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Type field is 15 bits according to this... and then later: >> >>> | | | | | >>> | HMAC | 65245 | 20 | HMAC based message | >>> | | | | authentication code, with | >>> | | | | key material from | >>> | | | | HIP_TRANSFORM | >>> >> >> Which seems to assume its at least 16 bits. Perhaps the picture >> is misaligned somehow? I think it should be 16 bits and the length >> field should be correspondingly smaller. > > > The C bit is counted as a part of the type. Probably a sentence somewhere > is needed to clarify this. The C-bit definition covers it, but is not clear. Is it enough if I add the following to Type definition: Type Type code for the parameter. 16 bits long, C-bit being part of the Type code. C Critical. One if this parameter is critical, and MUST be recognized by the recipient, zero otherwise. The C bit is considered to be a part of the Type field. Consequently, critical parameters are always odd and non-critical ones have an even value. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 18 08:43:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYNtR-00024p-ET; Wed, 18 May 2005 08:43:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYNtO-00024k-60 for hipsec@megatron.ietf.org; Wed, 18 May 2005 08:43:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13825 for ; Wed, 18 May 2005 08:43:16 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYOAJ-0003Gp-Uc for hipsec@ietf.org; Wed, 18 May 2005 09:00:49 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 03D5589869; Wed, 18 May 2005 15:43:05 +0300 (EEST) Message-ID: <428B3864.60102@piuha.net> Date: Wed, 18 May 2005 15:43:16 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Petri Jokela Subject: Re: [Hipsec] some hip base spec nits References: <428ACC07.60000@piuha.net> <5e040848e55db898fa7ab1a5d443e76d@nomadiclab.com> <428B360C.702@nomadiclab.com> In-Reply-To: <428B360C.702@nomadiclab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, "Petri Jokela \(JO/LMF\)" 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Ok. Petri Jokela wrote: > Pekka Nikander wrote: > >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Type |C| >>>> Length | >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> | | >>>> / >>>> Contents / >>>> / >>>> +-+-+-+-+-+-+-+-+ >>>> | | >>>> Padding | >>>> >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> >>> Type field is 15 bits according to this... and then later: >>> >>>> | | | >>>> | | >>>> | HMAC | 65245 | 20 | HMAC based >>>> message | >>>> | | | | authentication code, >>>> with | >>>> | | | | key material >>>> from | >>>> | | | | >>>> HIP_TRANSFORM | >>>> >>> >>> Which seems to assume its at least 16 bits. Perhaps the picture >>> is misaligned somehow? I think it should be 16 bits and the length >>> field should be correspondingly smaller. >> >> >> >> The C bit is counted as a part of the type. Probably a sentence >> somewhere >> is needed to clarify this. > > > The C-bit definition covers it, but is not clear. Is it enough if I > add the following to Type definition: > > Type Type code for the parameter. 16 bits long, C-bit being > part of the Type code. > C Critical. One if this parameter is critical, and > MUST be recognized by the recipient, zero otherwise. > The C bit is considered to be a part of the Type field. > Consequently, critical parameters are always odd > and non-critical ones have an even value. > > /petri > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 18 09:46:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOse-0005oh-KY; Wed, 18 May 2005 09:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYOsc-0005o0-6Q for hipsec@megatron.ietf.org; Wed, 18 May 2005 09:46:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20877 for ; Wed, 18 May 2005 09:46:31 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYP9X-0007Hr-Rg for hipsec@ietf.org; Wed, 18 May 2005 10:04:05 -0400 Received: from [192.168.1.50] (194.2.144.31) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 425309C601B421B7 for hipsec@ietf.org; Wed, 18 May 2005 15:46:18 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] changes to base spec? User-Agent: KMail/1.7 References: <426C950A.3020706@cs.helsinki.fi> <200505172241.11952.Jan.Melen@nomadiclab.com> <39b8e89d979a17c75bac6ddc7bc66f3b@nomadiclab.com> In-Reply-To: <39b8e89d979a17c75bac6ddc7bc66f3b@nomadiclab.com> MIME-Version: 1.0 Content-Disposition: inline Date: Wed, 18 May 2005 15:47:01 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200505181547.01639.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Wednesday 18 May 2005 14:28, Pekka Nikander wrote: > > On Monday 16 May 2005 22:13, Julien Laganier wrote: > >> There is a related problem when an opportunistic initiator tries > >> to reach a node via its rendezvous server. > >> > >> The initiator sends an I1 to the NULL destination HIT at the RVS > >> IP address, which relays it to the responder. If the responder > >> replies an R1 directly to the initiator, there's currently no > >> way for the initiator to identify the correct context, apart > >> from the RVS IP address included in an optional VIA_RVS > >> parameter. > > I think we should forbid that behavior. Okay. I'd like to hear more opinions before we take a decision. > Firstly, if the > destination HIT is NULL then the rendezvous server cannot reliably > know to which destination the I1 is really intended to, unless it > is serving just a single destination host. With IPv6 there is an additional possibility: it might be reasonable for a RVS to have a per-client IPv6 address, and to demultiplex incoming I1s based on their destination IP address. > IMHO the right way forward here is to state (in the rendezvous doc) > that if you want to support rvs with NULL dest HITs, then the > return R1 *MUST* go through the rendezvous server and appear coming > from the rendezvous server's IP address. > > Or am I missing something? That's in the current draft. Security considerations says: If an Initiator has not an a priori knowledge of the Responder's HI (so called Opportunistic Initiators), it is almost impossible to defend the HIP exchange against MitM attacks (cannot authenticate public keys exchanged). The only solution is to mitigate hijacking threats on the HIP state by requiring an R1 answering an Opportunistic I1 to come from the IP address where the I1 was initially sent. That way we retain a level of security which is equivalent to what exists today in the Internet: By sending an IP packet to an IP address, and receiving an answered IP packet from this same IP address, I know that the routing fabric trusts my correspondent to be represented by this IP address. While it is true that such security is weak, it is better than none, and avoids to introduce additional threats at the IP layer. > > You are probably referring to a case where RVS acts as an > > sentinel node for a > > farm of servers. This is really a special case but yes you have a > > valid point > > that in order this kind of scenario to work you would need a > > nonce. Perhaps > > the solution would be to add optional ECHO_REQUEST to I1 and a > > ECHO_RESPONSE > > that is outside the signature to R1 as you suggested. If this > > kind of scenario should be supported at all? Normally the > > destination HITs of these > > computer farms are probably well known. > > I have no objection in adding *optional* (for Initiator) support > for that. > Apparently, the support in the Responder should be RECOMMENDED or > REQUIRED. > I'd be in favor of making it RECOMMENDED, meaning that the > Initiator must be prepared to receive an R1 without an > ECHO_RESPONSE even if they sent an ECHO_REQUEST in I1. Okay. So I'd like to hear more voice for/against the opportunistic mode with RVS. Do we keep the current text (reply R1 via the RVS) or do we forbid this behavior as Pekka proposed? Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu May 19 09:24:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYl0K-0004JB-CN; Thu, 19 May 2005 09:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYl0I-0004Iq-6o for hipsec@megatron.ietf.org; Thu, 19 May 2005 09:23:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04032 for ; Thu, 19 May 2005 09:23:56 -0400 (EDT) Message-Id: <200505191323.JAA04032@ietf.org> Received: from mail-01.iinet.net.au ([203.59.3.33] helo=mail.iinet.net.au) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DYlHM-0001Zo-9H for hipsec@ietf.org; Thu, 19 May 2005 09:41:42 -0400 Received: (qmail 16670 invoked from network); 19 May 2005 13:22:27 -0000 Received: from unknown (HELO T40) (203.217.44.138) by mail.iinet.net.au with SMTP; 19 May 2005 13:22:26 -0000 From: "Joseph" To: Date: Thu, 19 May 2005 23:22:22 +1000 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Thread-Index: AcVcdco+E8ftc/VbRRmoCu7uDKWq0w== X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [Hipsec] Did anyone develop the HIP model for simulation software? 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: , Content-Type: multipart/mixed; boundary="===============0953576343==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0953576343== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C55CC9.9D2B9C30" This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C55CC9.9D2B9C30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear All, Did anyone develop the HIP model in simulation software, such as Opnet or NS-2? Or did anyone know where I can find those? Thanks Joseph ------=_NextPart_000_0018_01C55CC9.9D2B9C30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear = All,
    Did anyone=20 develop the HIP model in simulation software, such as Opnet or NS-2? Or = did=20 anyone know where I can find those?
Thanks
Joseph
------=_NextPart_000_0018_01C55CC9.9D2B9C30-- --===============0953576343== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0953576343==-- From hipsec-bounces@lists.ietf.org Fri May 20 04:11:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ2bQ-0006Gy-7f; Fri, 20 May 2005 04:11:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ2bO-0006Gp-Jd for hipsec@megatron.ietf.org; Fri, 20 May 2005 04:11:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17897 for ; Fri, 20 May 2005 04:11:24 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ2sh-0002HE-Ic for hipsec@ietf.org; Fri, 20 May 2005 04:29:20 -0400 Received: from [10.0.0.68] (83.145.97.42) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 425309D301E6E2F5 for hipsec@ietf.org; Fri, 20 May 2005 10:10:36 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] changes to base spec? Date: Fri, 20 May 2005 10:11:15 +0200 User-Agent: KMail/1.7 References: <426C950A.3020706@cs.helsinki.fi> <39b8e89d979a17c75bac6ddc7bc66f3b@nomadiclab.com> <200505181547.01639.julien.IETF@laposte.net> In-Reply-To: <200505181547.01639.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505201011.16068.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, On Wednesday 18 May 2005 15:47, Julien Laganier wrote: > On Wednesday 18 May 2005 14:28, Pekka Nikander wrote: > > > On Monday 16 May 2005 22:13, Julien Laganier wrote: > > >> There is a related problem when an opportunistic initiator > > >> tries to reach a node via its rendezvous server. > > >> > > >> The initiator sends an I1 to the NULL destination HIT at the > > >> RVS IP address, which relays it to the responder. If the > > >> responder replies an R1 directly to the initiator, there's > > >> currently no way for the initiator to identify the correct > > >> context, apart from the RVS IP address included in an optional > > >> VIA_RVS parameter. > > > > I think we should forbid that behavior. (...) > So I'd like to hear more voice for/against the opportunistic mode > with RVS. Do we keep the current text (reply R1 via the RVS) or do > we forbid this behavior as Pekka proposed? Until now nobody has objected to Pekka's proposal, so if nobody still don't object in the following days, I will put some text in the draft to forbid opportunistic mode with rendezvous relaying: -An initiator MUST not send an I1 with a NULL destination HIT to an IP address which is known to be a rendezvous server address. -A rendezvous server MUST drop incoming I1 with a NULL destination HIT. -A rendezvous client, acting as responder, MUST drop incoming I1 with a NULL destination HIT which were relayed by a rendezvous server. I'm not sure of the requirements level, however. Perhaps MUST is too strong, and SHOULD would be sufficient. Opinions? Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri May 20 04:52:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3FT-000897-6F; Fri, 20 May 2005 04:52:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3FR-000870-4l for hipsec@megatron.ietf.org; Fri, 20 May 2005 04:52:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21345 for ; Fri, 20 May 2005 04:52:46 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ3Wj-0003NW-Fb for hipsec@ietf.org; Fri, 20 May 2005 05:10:43 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 96F07212CAE; Fri, 20 May 2005 11:52:35 +0300 (EEST) In-Reply-To: <200505201011.16068.julien.IETF@laposte.net> References: <426C950A.3020706@cs.helsinki.fi> <39b8e89d979a17c75bac6ddc7bc66f3b@nomadiclab.com> <200505181547.01639.julien.IETF@laposte.net> <200505201011.16068.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] changes to base spec? Date: Fri, 20 May 2005 11:52:21 +0300 To: Julien Laganier X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > -A rendezvous server MUST drop incoming I1 with a NULL destination > HIT. Alternatively, it could interpret it as an I1 to itself. That would be perfectly OK from a semantics point of view, provided that the rendezvous server is a HIP host itself. > -A rendezvous client, acting as responder, MUST drop incoming I1 with > a NULL destination HIT which were relayed by a rendezvous server. I don't quite understand the rationale of this. In some cases the client may not even know that it is coming from its rendezvous server and not directly from another host? Or am I missing something here? > I'm not sure of the requirements level, however. Perhaps MUST is too > strong, and SHOULD would be sufficient. I think SHOULD is enough. Little harm is done if someone acts badly, so we shouldn't use MUST. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri May 20 05:23:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3iw-00075R-LI; Fri, 20 May 2005 05:23:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3iv-00075M-PT for hipsec@megatron.ietf.org; Fri, 20 May 2005 05:23:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23523 for ; Fri, 20 May 2005 05:23:15 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ40F-00042j-DS for hipsec@ietf.org; Fri, 20 May 2005 05:41:12 -0400 Received: from [10.0.0.68] (83.145.97.42) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 425309EF01E70425; Fri, 20 May 2005 11:20:35 +0200 From: Julien Laganier To: Pekka Nikander Subject: Re: [Hipsec] changes to base spec? Date: Fri, 20 May 2005 11:20:30 +0200 User-Agent: KMail/1.7 References: <426C950A.3020706@cs.helsinki.fi> <200505201011.16068.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505201120.30556.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi Pekka, Thanks for your quick answer. More below, On Friday 20 May 2005 10:52, Pekka Nikander wrote: > > -A rendezvous server MUST drop incoming I1 with a NULL > > destination HIT. > > Alternatively, it could interpret it as an I1 to itself. That > would be perfectly OK from a semantics point of view, provided > that the rendezvous server is a HIP host itself. You're right. Let's have this text: -A rendezvous server SHOULD interpret any incoming opportunistic I1 (i.e. with a NULL destination HIT) as an I1 to itself and SHOULD NOT attempt to relay it to one of its clients. > > -A rendezvous client, acting as responder, MUST drop incoming I1 > > with a NULL destination HIT which were relayed by a rendezvous > > server. > > I don't quite understand the rationale of this. In some cases the > client may not even know that it is coming from its rendezvous > server and not directly from another host? Or am I missing > something here? I should have been more precise: I was thinking to the case where the responder get an opportunistic I1 including a FROM:ip_address parameter, indicating that the packet was relayed. I propose this text: -A rendezvous client acting as responder SHOULD drop opportunistic I1s including a FROM parameter because that means the I1 has been relayed. Along with their initiator counterparts: -An initiator SHOULD not send an opportunistic I1 with a NULL destination HIT to an IP address which is known to be a rendezvous server address. -An initiator SHOULD drop R1s replying to an opportunistic I1 if it does not come from the IP address the I1 was sent to. Is that okay with everybody? Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri May 20 05:31:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3qU-00008n-NQ; Fri, 20 May 2005 05:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ3qT-00008i-Qg for hipsec@megatron.ietf.org; Fri, 20 May 2005 05:31:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23991 for ; Fri, 20 May 2005 05:31:03 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ47o-0004Al-LA for hipsec@ietf.org; Fri, 20 May 2005 05:49:01 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 48F7A212C40; Fri, 20 May 2005 12:30:56 +0300 (EEST) In-Reply-To: <200505201120.30556.julien.IETF@laposte.net> References: <426C950A.3020706@cs.helsinki.fi> <200505201011.16068.julien.IETF@laposte.net> <200505201120.30556.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1bc932ece5edd4a6d576165bff32e341@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] changes to base spec? Date: Fri, 20 May 2005 12:31:26 +0300 To: Julien Laganier X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > -A rendezvous server SHOULD interpret any incoming opportunistic I1 > (i.e. with a NULL destination HIT) as an I1 to itself and SHOULD NOT > attempt to relay it to one of its clients. > > -A rendezvous client acting as responder SHOULD drop opportunistic I1s > including a FROM parameter because that means the I1 has been > relayed. > > Along with their initiator counterparts: > > -An initiator SHOULD not send an opportunistic I1 with a NULL > destination HIT to an IP address which is known to be a rendezvous > server address. You might want to add in parenthesis: (If the Initiator knows that a given IP address belongs to a rendezvous server, it most probably also knows the HIT of this rendezvous server.) Or, alternatively, you could simply add: , unless it wants to establish a HIP association with the rendezvous server itself and does not know the HIT of the rendezvous server. I am not quite sure which one is the right choice. > -An initiator SHOULD drop R1s replying to an opportunistic I1 if it > does not come from the IP address the I1 was sent to. > > Is that okay with everybody? Thanks. Other than the note above, looks very good to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri May 20 08:30:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ6du-0006Kj-Dc; Fri, 20 May 2005 08:30:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZ6dt-0006Ke-G0 for hipsec@megatron.ietf.org; Fri, 20 May 2005 08:30:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08545 for ; Fri, 20 May 2005 08:30:15 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZ6vE-0000DV-Io for hipsec@ietf.org; Fri, 20 May 2005 08:48:13 -0400 Received: from [10.0.0.68] (83.145.97.42) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 425309D301EA30EF; Fri, 20 May 2005 14:29:27 +0200 From: Julien Laganier To: hipsec@ietf.org Date: Fri, 20 May 2005 14:29:57 +0200 User-Agent: KMail/1.7 References: <426C950A.3020706@cs.helsinki.fi> <200505201120.30556.julien.IETF@laposte.net> <1bc932ece5edd4a6d576165bff32e341@nomadiclab.com> In-Reply-To: <1bc932ece5edd4a6d576165bff32e341@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505201429.57964.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: lars.eggert@netlab.nec.de Subject: [Hipsec] Preliminary -02 RVS 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Folks, Here is the pre-version of the updated rendezvous draft (based on feedback from the hipsec ML) that we plan to submit before the end of May. Changelog from -01 to -02-200505: Removed multiple relaying techniques but simple I1 header rewriting. Updated new HIP parameters type numbers (consistent with new layout and assigning rules from draft-ietf-hip-base.) Updated IANA Considerations. Please take a look and let me know if you disagree with the approach we took. Thanks in advance, --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri May 20 18:12:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZFhH-0001pc-J3; Fri, 20 May 2005 18:10:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZFhF-0001nH-QB for hipsec@megatron.ietf.org; Fri, 20 May 2005 18:10:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19320 for ; Fri, 20 May 2005 18:10:18 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZFyg-0002Tp-77 for hipsec@ietf.org; Fri, 20 May 2005 18:28:23 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA00340; Fri, 20 May 2005 15:10:02 -0700 (PDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4KMA1D29623; Fri, 20 May 2005 15:10:01 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 May 2005 15:10:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] changes to base spec? Date: Fri, 20 May 2005 15:09:59 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5A@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] changes to base spec? Thread-Index: AcVdHuQKafxTcUyjTHS8k+lid/1mLQAXxUHQ From: "Henderson, Thomas R" To: "Pekka Nikander" , "Julien Laganier" X-OriginalArrivalTime: 20 May 2005 22:10:00.0272 (UTC) FILETIME=[AA38ED00:01C55D88] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > > Is that okay with everybody? Thanks. >=20 > Other than the note above, looks very good to me. >=20 I also agree with the changes hashed out regarding the rendezvous case. However, I don't sense any convergence in agreeing on the initial proposal to include nonce in I1 and R1, now that this rendezvous case has been defused. It seems to me that consensus is that the stated vulnerability is unlikely to occur (off-path attacker who obtains correct signed parts of R1 and times the fake R1 successfully so that it tricks the initiator to solve the wrong puzzle). Regarding the other changes proposed in the paper: 2- I do not think it is burdensome to retain I and J for this purpose, so I would agree with the proposal 3,4,5- These are all related to the puzzle implementation. Perhaps we could put the proposed puzzle mechanism into the appendix and reference the paper? (5 would require some change in section 4.1.1 and appendix C) 6- I don't object to this proposed change (reveal HI in I2)-- I don't know the original requirement for this encryption, and the paper points out that it seems to be flawed. 7a)- Let me respond to this in a separate post. 7b),7c),8- These are all related to achieving consistency in=20 Initiator/Responder roles when I1s or I2s collide, and seem OK to me. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat May 21 17:13:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZbI0-0002ZQ-7X; Sat, 21 May 2005 17:13:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZbHx-0002ZL-Ky for hipsec@megatron.ietf.org; Sat, 21 May 2005 17:13:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27876 for ; Sat, 21 May 2005 17:13:38 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZbZb-0000b3-2e for hipsec@ietf.org; Sat, 21 May 2005 17:31:55 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA08904; Sat, 21 May 2005 14:13:31 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4LLDUD18978; Sat, 21 May 2005 14:13:30 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 21 May 2005 14:13:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 May 2005 14:13:29 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5B@xch-nw-27.nw.nos.boeing.com> Thread-Topic: moving from R2-SENT to UNASSOCIATED Thread-Index: AcVdHuQKafxTcUyjTHS8k+lid/1mLQAZwffw From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 21 May 2005 21:13:30.0450 (UTC) FILETIME=[F024E320:01C55E49] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: Tuomas Aura , aarthi.nagarajan@tu-harburg.de Subject: [Hipsec] moving from R2-SENT to UNASSOCIATED 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org In the paper by Aura et al., there is a proposal: "7a) The timeout transition from the R2-SENT state should lead to the UNASSOCIATED state." Earlier, it is said: "The reason for waiting for the ESP packet is key confirmation; only after receiving the ESP packet the Responder knows that the Initiator received a fresh Diffie-Hellman key (rather than a replay) in R1 and has computed the valid session key. The timeout transition breaks this mechanism." Actually, key confirmation is not the reason-- instead, the reason is the desire to avoid distinguishing between Initiator and Responder after the exchange completes, yet be able to properly handle the possible transmission loss of R2. See: http://honor.trusecure.com/pipermail/hipsec/2004-April/000672.html The Responder can learn that the Initiator received a fresh DH-key when it checks the HMAC on the I2. But getting back to proposal 7a), I question whether transition to UNASSOCIATED is solving the real problem. It may be that we do not want to have any special timeout transition from R2-SENT. The reason that R2-SENT is a useful state is that it allows the Responder to reply to a duplicate (retransmitted, or replayed) I2 without changing its state. If R2 was truly lost, this reply will serve the same purpose as the original R2. If R2 were not lost, the retransmitted R2 will simply be ignored. Consider if the timeout value of R2-SENT is too short (or zero), and the following situation occurs-- the first R2 sent is successfully received (moving Initiator to ESTABLISHED) but I2 is retransmitted or replayed (or retransmission of I2 crosses paths with the initial R2). The (previous) Responder may process this I2 as if it were a new one, following the rules for ESTABLISHED state, and cycle back into R2-SENT or ESTABLISHED. The new R2 (with new SPI) will be sent to the previous Initiator, but it will discard it. The two sides will be out of sync now. The situation would be the same if R2-SENT transitioned to UNASSOCIATED. Because of this, the timeout value to move from R2-SENT should be large enough to avoid such possibilities. And that makes me question whether any timer is needed. Moving from R2-SENT to ESTABLISHED could instead just be triggered based on reception of a packet (data on a SPI, HIP UPDATE) that indicates that the peer got the R2. If the group agrees, I'll propose some text to change this behavior. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun May 22 00:13:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZhpw-0002el-4t; Sun, 22 May 2005 00:13:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZhpv-0002eg-6W for hipsec@megatron.ietf.org; Sun, 22 May 2005 00:13:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21999 for ; Sun, 22 May 2005 00:13:08 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZi7b-0001m8-OJ for hipsec@ietf.org; Sun, 22 May 2005 00:31:29 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E0AB5212C40; Sun, 22 May 2005 07:12:58 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5B@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5B@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <23f5fbefd962941dcc75305fd284ed80@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Sun, 22 May 2005 07:13:30 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Tuomas Aura , aarthi.nagarajan@tu-harburg.de 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Because of this, the timeout value to move from R2-SENT > should be large enough to avoid such possibilities. And > that makes me question whether any timer is needed. Moving > from R2-SENT to ESTABLISHED could instead just be triggered > based on reception of a packet (data on a SPI, HIP UPDATE) > that indicates that the peer got the R2. > > If the group agrees, I'll propose some text to change this > behavior. In principle, sounds fine to me. OTOH, I think it might be good to allow a *long* timeout after which the Responder MAY revert to UNASSOCIATED. That timeout could be in the order of the default inactivity timeout of the association... --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sun May 22 16:23:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwzK-0005ed-DC; Sun, 22 May 2005 16:23:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DZwzJ-0005c4-AX for hipsec@megatron.ietf.org; Sun, 22 May 2005 16:23:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22806 for ; Sun, 22 May 2005 16:23:48 -0400 (EDT) Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DZxH6-0002ge-4H for hipsec@ietf.org; Sun, 22 May 2005 16:42:16 -0400 Received: from celerio.ucdavis.edu (celerio.ucdavis.edu [169.237.104.178]) by warsaw.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j4MKN3LH020173 for ; Sun, 22 May 2005 13:23:47 -0700 (PDT) Received: from celerio.ucdavis.edu (localhost [127.0.0.1]) by celerio.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j4MKN3JO010033 for ; Sun, 22 May 2005 13:23:03 -0700 (PDT) Received: (from www@localhost) by celerio.ucdavis.edu (8.12.10/8.12.9/Submit) id j4MKN3eN010032; Sun, 22 May 2005 13:23:03 -0700 (PDT) Date: Sun, 22 May 2005 13:23:03 -0700 (PDT) Message-Id: <200505222023.j4MKN3eN010032@celerio.ucdavis.edu> To: hipsec@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Subject: [Hipsec] Call for Paper: JSAC-MRNM (The deadline is approaching.) 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 23 10:51:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaEHB-0005mg-FM; Mon, 23 May 2005 10:51:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaEH9-0005mV-68 for hipsec@megatron.ietf.org; Mon, 23 May 2005 10:51:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02447 for ; Mon, 23 May 2005 10:51:25 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaEZ7-0006Wl-5B for hipsec@ietf.org; Mon, 23 May 2005 11:10:03 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA05505; Mon, 23 May 2005 09:51:12 -0500 (CDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4NEpBw18961; Mon, 23 May 2005 09:51:12 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 May 2005 07:51:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 07:51:09 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5F@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] moving from R2-SENT to UNASSOCIATED Thread-Index: AcVehIt6lKKCjBnLTLadEaIKsNGr0wBIa1QA From: "Henderson, Thomas R" To: "Pekka Nikander" X-OriginalArrivalTime: 23 May 2005 14:51:10.0092 (UTC) FILETIME=[DB738CC0:01C55FA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org, Tuomas Aura , aarthi.nagarajan@tu-harburg.de 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Saturday, May 21, 2005 9:14 PM > To: Henderson, Thomas R > Cc: aarthi.nagarajan@tu-harburg.de; hipsec@ietf.org; Tuomas Aura > Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED >=20 > > Because of this, the timeout value to move from R2-SENT > > should be large enough to avoid such possibilities. And > > that makes me question whether any timer is needed. Moving > > from R2-SENT to ESTABLISHED could instead just be triggered > > based on reception of a packet (data on a SPI, HIP UPDATE) > > that indicates that the peer got the R2. > > > > If the group agrees, I'll propose some text to change this > > behavior. >=20 > In principle, sounds fine to me. OTOH, I think it might be > good to allow a *long* timeout after which the Responder > MAY revert to UNASSOCIATED. That timeout could be in the > order of the default inactivity timeout of the association... >=20 We have such a timeout in ESTABLISHED state, but it moves to CLOSING. I agree that there could be a long timeout after which the Responder MAY change state, but I would suggest trying to pass through CLOSING state, so as to avoid cases where one side silently drops the association without notifying the other side. (note that the acronym "UAL", which I assume is the "default inactivity timeout", appears in the state machine but is nowhere defined in the document). Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 23 11:40:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaF2m-00038h-6R; Mon, 23 May 2005 11:40:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaF2k-00038Z-Hg for hipsec@megatron.ietf.org; Mon, 23 May 2005 11:40:38 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06335 for ; Mon, 23 May 2005 11:40:35 -0400 (EDT) Received: from [192.168.1.50] (194.2.144.31) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 429188A00005AA3A; Mon, 23 May 2005 17:39:57 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 17:39:52 +0200 User-Agent: KMail/1.7 References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5F@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5F@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505231739.53429.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Monday 23 May 2005 16:51, Henderson, Thomas R wrote: > (note that the acronym "UAL", which I assume is the "default > inactivity timeout", appears in the state machine but is nowhere > defined in the document). Sorry it's my mistake (when I merged Erik's CLOSE/CLOSE_ACK handshake with the HIP state machine). UAL signification (Unused Association Lifetime) is given in the CLOSING state text, so after it has been used in the ESTABLISHED state text. I think we should at least move this signification in the ESTABLISHED state text, and perhaps define it properly prior to states description. For wxample: "When a HIP node hasn't used a HIP association for Unused Association Lifetime (UAL) minutes, it will begin to tear down the association". It might also be good to suggest a typical value (5 min?) for implementors. Thoughts? --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 23 12:05:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaFQp-0006g7-Og; Mon, 23 May 2005 12:05:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaFQn-0006fz-TH for hipsec@megatron.ietf.org; Mon, 23 May 2005 12:05:30 -0400 Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09626 for ; Mon, 23 May 2005 12:05:27 -0400 (EDT) Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA17923; Mon, 23 May 2005 09:04:58 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4NG4ve04236; Mon, 23 May 2005 09:04:57 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 09:04:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 09:04:56 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C0664934F@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] moving from R2-SENT to UNASSOCIATED Thread-Index: AcVfrk31PmNVFRzGTP66GJAzTLn2QQAAni1g From: "Henderson, Thomas R" To: "Julien Laganier" , X-OriginalArrivalTime: 23 May 2005 16:04:57.0531 (UTC) FILETIME=[2A6920B0:01C55FB1] Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Julien Laganier [mailto:julien.IETF@laposte.net]=20 > Sent: Monday, May 23, 2005 8:40 AM > To: hipsec@lists.ietf.org > Cc: Henderson, Thomas R > Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED >=20 > I think we should at least move this signification in the ESTABLISHED=20 > state text, and perhaps define it properly prior to states=20 > description. For wxample: "When a HIP node hasn't used a HIP=20 > association for Unused Association Lifetime (UAL) minutes, it will=20 > begin to tear down the association". >=20 > It might also be good to suggest a typical value (5 min?) for=20 > implementors. >=20 5 minutes seems short to me. I don't know what magic number (if any) is appropriate. Here is what IKEv2 Section 2.8 says about the matter: " ... If an SA bundle has been inactive for a long time and if an endpoint would not initiate the SA in the absence of traffic, the endpoint MAY choose to close the SA instead of rekeying it when its lifetime expires. It SHOULD do so if there has been no traffic since the last time the SA was rekeyed." _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 23 13:45:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGzB-0001p0-2v; Mon, 23 May 2005 13:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGz9-0001oH-JM for hipsec@megatron.ietf.org; Mon, 23 May 2005 13:45:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18408 for ; Mon, 23 May 2005 13:45:02 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHH9-0005i4-QZ for hipsec@ietf.org; Mon, 23 May 2005 14:03:41 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 43A6A212C40; Mon, 23 May 2005 20:44:47 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5F@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5F@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7514092d185d4f94b24c6a7e05d59500@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 20:45:20 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Tuomas Aura , aarthi.nagarajan@tu-harburg.de 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >>> Because of this, the timeout value to move from R2-SENT >>> should be large enough to avoid such possibilities. And >>> that makes me question whether any timer is needed. Moving >>> from R2-SENT to ESTABLISHED could instead just be triggered >>> based on reception of a packet (data on a SPI, HIP UPDATE) >>> that indicates that the peer got the R2. >> >> In principle, sounds fine to me. OTOH, I think it might be >> good to allow a *long* timeout after which the Responder >> MAY revert to UNASSOCIATED. That timeout could be in the >> order of the default inactivity timeout of the association... > > We have such a timeout in ESTABLISHED state, but it moves > to CLOSING. I agree that there could be a long timeout > after which the Responder MAY change state, but I would suggest > trying to pass through CLOSING state, so as to avoid cases > where one side silently drops the association without notifying > the other side. OK to me. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 23 13:49:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaH3M-0002P5-Vf; Mon, 23 May 2005 13:49:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaH3K-0002P0-Uk for hipsec@megatron.ietf.org; Mon, 23 May 2005 13:49:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18727 for ; Mon, 23 May 2005 13:49:21 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaHLL-0005qL-83 for hipsec@ietf.org; Mon, 23 May 2005 14:08:00 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 21866212C40; Mon, 23 May 2005 20:49:09 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C0664934F@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C0664934F@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 20:49:41 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> [About UAL] >> >> It might also be good to suggest a typical value (5 min?) for >> implementors. >> > > 5 minutes seems short to me. I don't know what magic number (if > any) is appropriate. UAL has been traditionally 15 minutes, but I don't know the origin of that value. It came from Bob Moskowitz, and I don't know the rationale behind that. IMHO each implementation SHOULD implement per-HIT configuration of UAL, allowing statically configured HIP associations to stay alive days, even when inactive. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 23 16:54:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaJwk-0007re-5e; Mon, 23 May 2005 16:54:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaJwe-0007qw-FH for hipsec@megatron.ietf.org; Mon, 23 May 2005 16:54:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20211 for ; Mon, 23 May 2005 16:54:38 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaKEg-0000Tj-3p for hipsec@ietf.org; Mon, 23 May 2005 17:13:19 -0400 Received: from [10.10.10.11] (pD9E61C21.dip0.t-ipconnect.de [217.230.28.33]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3D57F1BAC9E; Mon, 23 May 2005 22:54:29 +0200 (CEST) In-Reply-To: References: <6938661A6EDA8A4EA8D1419BCE46F24C0664934F@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <05471F2E-F565-480D-9B4F-767169A6EF33@netlab.nec.de> From: Lars Eggert Subject: Re: [Hipsec] moving from R2-SENT to UNASSOCIATED Date: Mon, 23 May 2005 22:54:25 +0200 To: Pekka Nikander X-Mailer: Apple Mail (2.730) X-Spam-Score: 0.2 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: hipsec@ietf.org, Julien Laganier 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: , Content-Type: multipart/mixed; boundary="===============0379888113==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============0379888113== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-31--1011970721; protocol="application/pkcs7-signature" --Apple-Mail-31--1011970721 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On May 23, 2005, at 19:49 , Pekka Nikander wrote: > IMHO each implementation SHOULD implement per-HIT configuration > of UAL, allowing statically configured HIP associations to stay > alive days, even when inactive. Yes, please. We're pushing a similar change to TCP right now. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-31--1011970721 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGdTCCAy4w ggKXoAMCAQICAwyFWjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwNjE3MDcyMjAzWhcNMDUwNjE3MDcyMjAzWjCBhDEPMA0GA1UE BBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2VydDEoMCYGCSqGSIb3 DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTEiMCAGCSqGSIb3DQEJARYTbGFycy5lZ2dl cnRAZ214Lm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOowMZjwQREXIdWxQacJ DyqczykKpfIVmid2m8xBuUO53uWgnK3F8R20u/7PVugUzjNNqaivnU6qHtr/jdAn1UnyXzA/4Re+ AqsKNiw8hZkVonkJ+G4O0TFzMNeWUdrjX1FaSAsLuAPA6661cN4YDzrOYC3O3zgGtVvJAra0+iw9 eD2qWsnH0AVLFtq7H5ZFhz5zeOeCrrayqEhfS6tnTSjBzaH8SOdeemPTxdLRbMptLSy7lEFo8f1x isltw2eRT0txoUCqq0mjFEp8LgJ+s6p14M4cG3CDkKd5kNjdTWaokAo4qmpfF9IyA7uheaAHAz8U OH5GsH+Vkjbz5yFO1SsCAwEAAaNLMEkwOQYDVR0RBDIwMIEZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZYETbGFycy5lZ2dlcnRAZ214Lm5ldDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GB AE9rOnUtJERYLNbDztLIsH4AolAWkvNKoj7Ikst1M1X3myXqxYAHa9bsoPJy15qEV2B4ftOmJLrZ L9kb8RZnzGBii8a/XQ5wqaHZAJYcxQ6lp6UDTabhQN7J1trAOKgs+PFlF3lm6NOkXygiQH5PPO5k IHRjNvXpNGYeC7S3K8YsMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UE BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQK ExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZp c2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkB FhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIz NTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0 ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqG SIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph 8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4H v0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQI MAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBl cnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQD ExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+ whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FX JY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAucw ggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMhVow CQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MDUwNTIzMjA1NDI2WjAjBgkqhkiG9w0BCQQxFgQUbFMIGpRQepd6fb64D6DZv4NJV28weAYJKwYB BAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECAwyF WjB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMMhVowDQYJKoZIhvcNAQEBBQAEggEACP6zktDAAWYI/fMxB6N/ILBievDJjyBJgo+f arR9/IJzep3nOb9GhJYpalCu2GCpWQdJ7qmn6ol9KSBIhlyQqaWQaX0QkXs/c0WiWb+FHMPqPKEf vpv4P2urjKGvsE6Sir5Fi2Q7fqyWIcmLiy9JOCLcfzCa5yxl/v9m4qW4zbFxcVlM+u7RvP1ep7ZS mo7OMxTkX4aCntW5RBN81a+5o3NUS8nrDNKUHzaEaqW7Vm6G6vTwmCGEeJcosOY6OR4hvkt0dnd5 j1z3nrRWu5d+fc9JTPzrI5R0EyaOgG8zmoxgSnakGansX3UrUxNFA3l/R8gOMAe9yDfcPp7hM9OS IQAAAAAAAA== --Apple-Mail-31--1011970721-- --===============0379888113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0379888113==-- From hipsec-bounces@lists.ietf.org Tue May 24 08:00:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaY5G-0007pG-RC; Tue, 24 May 2005 08:00:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaY5E-0007p9-SC for hipsec@megatron.ietf.org; Tue, 24 May 2005 08:00:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21052 for ; Tue, 24 May 2005 08:00:27 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaYNO-000080-GB for hipsec@ietf.org; Tue, 24 May 2005 08:19:16 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BF0F7212C40; Tue, 24 May 2005 15:00:15 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5A@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B5A@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4b46d92102b16472ba05027329a1973f@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] changes to base spec? Date: Tue, 24 May 2005 15:00:49 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Julien Laganier 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > However, I don't sense any convergence in agreeing on the initial > proposal to include nonce in I1 and R1, now that this rendezvous > case has been defused. It seems to me that consensus is that the > stated vulnerability is unlikely to occur (off-path attacker who > obtains correct signed parts of R1 and times the fake R1 successfully > so that it tricks the initiator to solve the wrong puzzle). I agree. OTOH, I don't see much harm in allowing (MAY) the Initiator to include an ECHO_REQUEST in I1, with the provisioning that the Responder is recommended (SHOULD) to reply with an ECHO_RESPONSE. Furthermore, if the Initiator does implement this option, it MUST be prepared for the case that the Responder does not reply with a ECHO_RESPONSE. The only problem with this is that it adds complexity and optional behaviour, though in a fairly mild manner, IMHO. That is, most of the complexity is carried by the Initiator implementing this; at the Responder end implementing the SHOULD is fairly simple. > Regarding the other changes proposed in the paper: > > 2- I do not think it is burdensome to retain I and J for this purpose, > so I would agree with the proposal Fine with me. > 3,4,5- These are all related to the puzzle implementation. Perhaps > we could put the proposed puzzle mechanism into the appendix and > reference the paper? (5 would require some change in section 4.1.1 > and appendix C) Fine wiht me. > 6- I don't object to this proposed change (reveal HI in I2)-- I don't > know the original requirement for this encryption, and the paper > points out that it seems to be flawed. I think we could easily allow both, i.e., both encrypted and unencrypted initiator HI. Then the question boils down to which should be the preferred (MUST implement) style, which optional (MAY/SHOULD). > 7b),7c),8- These are all related to achieving consistency in > Initiator/Responder roles when I1s or I2s collide, and seem OK > to me. I don't remember the details of these any more, but my vague recollection was that some of them may not be a problem as the HITs identify the context. However, I may be very wrong here. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 24 10:44:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daadf-0000yY-0W; Tue, 24 May 2005 10:44:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Daadd-0000yT-9S for hipsec@megatron.ietf.org; Tue, 24 May 2005 10:44:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06037 for ; Tue, 24 May 2005 10:44:07 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Daavo-0005jq-Cc for hipsec@ietf.org; Tue, 24 May 2005 11:02:58 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA06280; Tue, 24 May 2005 07:43:50 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4OEhon08377; Tue, 24 May 2005 07:43:50 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 07:43:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Pre-version: ESP draft Date: Tue, 24 May 2005 07:43:48 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Pre-version: ESP draft Thread-Index: AcVXvN5bfchjzs4MQbuCt+ItHjb2rQIsafPg From: "Henderson, Thomas R" To: "Petri Jokela" , X-OriginalArrivalTime: 24 May 2005 14:43:49.0380 (UTC) FILETIME=[FF2DFC40:01C5606E] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Comments on draft-ietf-hip-esp-00-pre130505.txt I have a number of minor edits (non-technical) that I will send to=20 Petri in a separate message. Below are some technical issues: 1) There is presently one open issue in the HIP WG issue tracker for=20 this draft (http://hip4inter.net/cgi-bin/roundup.cgi/hip-esp/index). It relates to use of NULL encryption and integrity. As I suggested in a previous post (http://www1.ietf.org/mail-archive/web/hipsec/current/msg01317.html), the current pre-draft has removed the statement that ESP NULL is=20 deprecated. Instead, it has added some material describing how one=20 might want to migrate from a NULL SA to an encrypted SA (suggested=20 by Gonzalo in: http://www1.ietf.org/mail-archive/web/hipsec/current/msg01329.html). =20 This has resulted in possible inclusion of ESP_TRANSFORM parameter in the UPDATE. The remaining sub-issue (whether we should have the statement that=20 "All HIP implementations must implement, at minimum, the ESP transport format") never generated any more discussion on the list, so I guess=20 the WG sentiment is to keep this as it is. I am OK with that. So maybe this issue is now closed? 2) What is the status of the BEET draft-- it has expired some time ago, and I don't know of any (SAAG?) discussion of it. Do we need to incorporate the core elements of the BEET draft into this draft to make HIP ESP stand alone? Or will BEET draft be introduced again? If BEET continues to be referenced, will it be a blocking reference for this draft? 3) One question I have about BEET operation is whether IP addresses are ever checked to see whether they match known addresses of the peer. It seemed to me upon quick reread of BEET draft that such IP address check is not done. That is, the packet is looked up=20 by SPI only in the SADB, and can come in from any address. Now, it seems a nice feature that IP addresses no longer matter at this=20 IPsec layer, but I wonder whether people will still want to impose some sanity checking of the inbound addresses in some cases (e.g., a "upon receiving a packet, MAY check whether the packet's=20 source IP address is known to be associated with the peer's HIT that it is about to be overwritten with"). I don't know whether such addition would constrain NAT interoperability in the future. This may also pertain to the last sentence of the first paragraph in=20 Section 3.2 regarding possible DoS vulnerabilities of this new=20 mode of operation, or maybe handled in the Security section. 4) In section 3.3.7, there is the inactive SA timeout default=20 that Pekka mentioned, of 15 minutes. I suggest that we adopt his suggested text here: "Each implementation SHOULD implement per-HIT configuration of=20 the inactivity timeout, allowing statically configured HIP=20 associations to stay alive for days, even when inactive." 5) At the Minneapolis WG meeting, when we were discussing future extensibility of HIP, Pekka brought up a suggestion that we maybe renumber the parameters and message types so as to leave some room for insertion. Although mainly a base spec issue, I bring this up here because we have selected ESP_INFO to be parameter=20 number 1 (so that it is easily accessible for inspection by middleboxes). =20 Do we want to leave some room at the top end of this parameter space for future parameters, and get better spacing between the ones we have? =20 6) Section 6.8 may need some refinement based on resolution of similar "simultaneous handshake" issues raised by Aura (regarding who takes role of Initiator and Responder if=20 UPDATEs cross on the wire). 7) In the definition of ESP_INFO, there is some language=20 regarding the binding of SPIs to addresses: " Old SPI Old SPI for data sent to the source address of this packet. If this is an initial SA setup, the Old SPI value is zero. New SPI New SPI for data sent to the source address of this packet." I wonder whether this should be slightly modified, to cover the case where REA associates different addresses with an SPI. Perhaps it should be, instead: " Old SPI Old SPI for data sent to address(es) associated with this SA. If this is an initial SA setup, the Old SPI value is zero. New SPI New SPI for data sent to address(es) associated with this SA." 8) There is not much mention of REKEYING state (actually, there is one mention about leaving REKEYING, but none on entering it). I added a reference to transitioning to REKEYING state in=20 Section 6.8 (Initiating ESP SA update) 9) The "Security" section is not written yet. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 24 10:54:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaanE-0002cT-2Y; Tue, 24 May 2005 10:54:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaanA-0002bS-I1 for hipsec@megatron.ietf.org; Tue, 24 May 2005 10:54:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07004 for ; Tue, 24 May 2005 10:53:58 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dab5L-0006Al-W6 for hipsec@ietf.org; Tue, 24 May 2005 11:12:49 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA20732; Tue, 24 May 2005 07:53:06 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4OEr5p26101; Tue, 24 May 2005 09:53:06 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 24 May 2005 07:52:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2005 07:52:58 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B67@xch-nw-27.nw.nos.boeing.com> Thread-Topic: IPR status of "Analysis of the HIP Base Exchange Proposal" Thread-Index: AcVdHuQKafxTcUyjTHS8k+lid/1mLQAZwffwALpHEiA= From: "Henderson, Thomas R" To: , "Tuomas Aura" , "Andrei Gurtov" X-OriginalArrivalTime: 24 May 2005 14:52:59.0809 (UTC) FILETIME=[4742C910:01C56070] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org Subject: [Hipsec] IPR status of "Analysis of the HIP Base Exchange Proposal" 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Tuomas, Aarthi, and Andrei, Since the WG is considering some modifications of the protocol based on your recent paper, could you please clarify whether the proposals have any IPR associated with them? Thanks, Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 24 11:10:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dab2w-0006xp-Gx; Tue, 24 May 2005 11:10:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dab2v-0006xk-QY for hipsec@megatron.ietf.org; Tue, 24 May 2005 11:10:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08914 for ; Tue, 24 May 2005 11:10:15 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DabL7-00070W-7h for hipsec@ietf.org; Tue, 24 May 2005 11:29:06 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA14585 for ; Tue, 24 May 2005 08:10:02 -0700 (PDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4OFA2p23812 for ; Tue, 24 May 2005 10:10:02 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 24 May 2005 08:10:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Date: Tue, 24 May 2005 08:10:00 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C06649357@xch-nw-27.nw.nos.boeing.com> Thread-Topic: Re: sticking with 128-bit HITs (was Re: [Hipsec] SHA1 broken? ) Thread-Index: AcVGlkIVbmy3SYsRSo2+SEw3zO5P1AWw8yjwAMXV9AA= From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 24 May 2005 15:10:01.0082 (UTC) FILETIME=[A7FCADA0:01C56072] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Pekka, Tim, and I have been discussing this thread off-line. The subject was how to define the prefix that is prepended to the hashed bits of the HIT. I think that we agreed that 8 bits was sufficient, but we had some debates over whether to further divide this field into Prefix/Hash Algorithm, and how many bits to assign to each subfield, if so. =20 Below is the present text in Petri's preview draft. Pekka and Tim indicated that they are fine with this proposal. Pekka indicated slight preference for a 5 bit prefix and 3 bit hash algorithm, so that the group could in the future try to get a /5 allocation for HITs from IANA, and allow us to change the hash algorithm without revisiting IANA. Tim commented that it may be hard to predict what IANA wants to do. My current thinking is that the below is fine for now-- if HIP goes standards track in the future, I'm sure there will be more understanding of what to put in there, but for now, the below seems general enough for our experimental purposes. Tom There are two types of HITs. HITs of the first type, called _Type 1 HIT_, consist of an 8-bit prefix followed by 120 bits of the hash of the public key. HITs of the second type (Type 2 HIT) consist of a Host Assigning Authority Field (HAA), and only the last 64 bits come from a SHA-1 hash of the Host Identity. This latter format for HIT is recommended for 'well known' systems. It is possible to support a resolution mechanism for these names in hierarchical directories, like the DNS. Another use of HAA is in policy controls, see Section 7. The following figure shows the structure of a Type 1 HIT. 1 0 2 0 1 2 3 4 5 6 7 8 ... 7 +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix | Hash | +-+-+-+-+-+-+-+-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix (8 bits) - Fixed prefix. 0x40 - SHA-1 hash algorithm All other values reserved. Hash (120 bits) - Lower-order bits of the hash (as specified by the hash algorithm) of the public key Additional values for the prefix (including different hash algorithms, or other information) may be defined in the future. A host may receive a HIT for which it does not understand the prefix. In such a case, it will not be able to check the mapping between HI and HIT. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 24 11:30:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabMV-0002mt-S5; Tue, 24 May 2005 11:30:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DabMT-0002mo-Oi for hipsec@megatron.ietf.org; Tue, 24 May 2005 11:30:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10793 for ; Tue, 24 May 2005 11:30:27 -0400 (EDT) Received: from courier.cs.helsinki.fi ([128.214.9.1] helo=mail.cs.helsinki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dabef-0007rJ-O0 for hipsec@ietf.org; Tue, 24 May 2005 11:49:19 -0400 Received: from [82.181.111.233] (cs181111233.pp.htv.fi [82.181.111.233]) (AUTH: PLAIN gurtov, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by mail.cs.helsinki.fi with esmtp; Tue, 24 May 2005 18:30:25 +0300 id 0008FEC9.42934891.0000539B Message-ID: <42934836.5040003@cs.helsinki.fi> Date: Tue, 24 May 2005 18:28:54 +0300 From: Andrei Gurtov User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B67@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B67@xch-nw-27.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Tuomas Aura , aarthi.nagarajan@tu-harburg.de Subject: [Hipsec] Re: IPR status of "Analysis of the HIP Base Exchange Proposal" 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Tom, I'm not aware of any iprs and I suppose there are none, since all the authors are from academia. Andrei Henderson, Thomas R wrote: >Tuomas, Aarthi, and Andrei, >Since the WG is considering some modifications of the protocol >based on your recent paper, could you please clarify whether >the proposals have any IPR associated with them? > >Thanks, >Tom > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 25 03:23:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaqEg-0004AC-DD; Wed, 25 May 2005 03:23:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaqEe-00049n-VM for hipsec@megatron.ietf.org; Wed, 25 May 2005 03:23:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14268 for ; Wed, 25 May 2005 03:23:23 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaqWy-0004BF-O2 for hipsec@ietf.org; Wed, 25 May 2005 03:42:22 -0400 Received: from n51.nomadiclab.com (n51.nomadiclab.com [193.234.219.51]) by n2.nomadiclab.com (Postfix) with ESMTP id BAC70212C40 for ; Wed, 25 May 2005 10:23:03 +0300 (EEST) From: Jan Mikael Melen To: hipsec@ietf.org Date: Wed, 25 May 2005 10:23:01 +0300 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505251023.02290.Jan.Melen@nomadiclab.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] HIP4BSD FAQ 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org HI, We have collected few most frequently asked qustions about our implementation and put them in to a web page: http://www.hip4inter.net/faq.php Regards, Jan _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 25 05:25:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Das8q-00083v-NV; Wed, 25 May 2005 05:25:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Das8o-00083q-Om for hipsec@megatron.ietf.org; Wed, 25 May 2005 05:25:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21927 for ; Wed, 25 May 2005 05:25:28 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DasR9-0007S0-8T for hipsec@ietf.org; Wed, 25 May 2005 05:44:28 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 1F858212C40; Wed, 25 May 2005 12:25:17 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 25 May 2005 12:25:50 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] BEET (was Re: Pre-version: ESP 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > 2) What is the status of the BEET draft-- it has expired some time > ago, and I don't know of any (SAAG?) discussion of it. Do we need > to incorporate the core elements of the BEET draft into this draft > to make HIP ESP stand alone? Or will BEET draft be introduced again? > If BEET continues to be referenced, will it be a blocking > reference for this draft? AFAIK, Jan is in the process of submitting a slightly updated version of the BEET draft. I have no real idea what would be the best way forward with it; I'm inclined to think that probably as an individual submission through Sam Hartman. > 3) One question I have about BEET operation is whether IP addresses > are ever checked to see whether they match known addresses of the > peer. It seemed to me upon quick reread of BEET draft that such > IP address check is not done. That is, the packet is looked up > by SPI only in the SADB, and can come in from any address. Now, it > seems a nice feature that IP addresses no longer matter at this > IPsec layer, but I wonder whether people will still want to impose > some sanity checking of the inbound addresses in some cases > (e.g., a "upon receiving a packet, MAY check whether the packet's > source IP address is known to be associated with the peer's HIT > that it is about to be overwritten with"). I don't know whether such > addition would constrain NAT interoperability in the future. This > may also pertain to the last sentence of the first paragraph in > Section 3.2 regarding possible DoS vulnerabilities of this new > mode of operation, or maybe handled in the Security section. I'd be inclined to include some text to the sec cons section about potential DOS, and leave it there. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 25 05:28:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DasBx-0008HU-Vg; Wed, 25 May 2005 05:28:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DasBw-0008HK-1P for hipsec@megatron.ietf.org; Wed, 25 May 2005 05:28:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22049 for ; Wed, 25 May 2005 05:28:42 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DasUI-0007Vo-9X for hipsec@ietf.org; Wed, 25 May 2005 05:47:42 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6255D212C40; Wed, 25 May 2005 12:28:34 +0300 (EEST) In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <425830fc9bd5c885439aff8606dfa506@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Pre-version: ESP draft Date: Wed, 25 May 2005 12:29:07 +0300 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Comments on draft-ietf-hip-esp-00-pre130505.txt > > 1) There is presently one open issue in the HIP WG issue tracker for > this draft > So maybe this issue is now closed? Fine with me. [BEET comments in a separate mail.] > 4) In section 3.3.7, there is the inactive SA timeout default > that Pekka mentioned, of 15 minutes. I suggest that we adopt > his suggested text here: > "Each implementation SHOULD implement per-HIT configuration of > the inactivity timeout, allowing statically configured HIP > associations to stay alive for days, even when inactive." Needless to say but fine with me. > 5) At the Minneapolis WG meeting, when we were discussing future > extensibility of HIP, Pekka brought up a suggestion that we maybe > renumber the parameters and message types so as to leave some > room for insertion. Although mainly a base spec issue, I bring > this up here because we have selected ESP_INFO to be parameter > number 1 (so that it is easily accessible for inspection by > middleboxes). > > Do we want to leave some room at the top end of this parameter > space for future parameters, and get better spacing between > the ones we have? I think it would be wise. > 6) Section 6.8 may need some refinement based on resolution > of similar "simultaneous handshake" issues raised by Aura > (regarding who takes role of Initiator and Responder if > UPDATEs cross on the wire). [Can't make any quick comments until there is text to comment; Petri are you planning to address this?] > 7) In the definition of ESP_INFO, there is some language > regarding the binding of SPIs to addresses: Fine as such with me, but maybe we should add some explanation w.r.t. the wording and REAs? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 25 15:21:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1Rv-0005GC-Sq; Wed, 25 May 2005 15:21:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db1Ru-0005Fk-LS for hipsec@megatron.ietf.org; Wed, 25 May 2005 15:21:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11847 for ; Wed, 25 May 2005 15:21:49 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db1kK-0006E7-Uz for hipsec@ietf.org; Wed, 25 May 2005 15:40:54 -0400 Received: from inside.nomadiclab.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 6A237212C40 for ; Wed, 25 May 2005 22:21:38 +0300 (EEST) Date: Wed, 25 May 2005 22:21:38 +0300 (EEST) From: Petri Jokela To: hipsec@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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [Hipsec] Base draft, snapshot 25.05.2005 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I uploaded the current version of the base draft to our server, the snapshot is dated 25.5.2005 (250505): http://hip4inter.net/draft.php The diff is between the 13th of May and this newer version. The diff is, unfortunately, a bit broken at the end of the document. Open issue: There is one comment about the CER packet: the description is unclear. I haven't yet touched that, but the question is: should I? The following editions have been made: - New IANA section - New Appendix C (sample Cookie handling at the Responder, based on Aura's comments) - ECHO_REQ/RESP messages numbering changed so that both are now critical (earlier, ECHO_REQ/RESP inside the SIGNATURE were not marked as critical, but outside they were). I couldn't find any reasoning for the different numbering from earlier mails. - ENCRYPTED parameter description and HMAC calculation (6.3.1) changed (based on Miika's and Jeff's mail) - 6.6 Changed the statement "Under no circumstances does the HIP state machine transition upon sending an R1" to only recommendation. In another place in the document it is said that the host may keep information about incoming I1s which means keeping some kind of state. Because this is an implementation issue, I don't think that we can mandate the implementation not to keep state based on I1-messages. But: please comment this edition. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed May 25 16:05:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db280-0006qI-WC; Wed, 25 May 2005 16:05:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Db27z-0006q3-SX for hipsec@megatron.ietf.org; Wed, 25 May 2005 16:05:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18919 for ; Wed, 25 May 2005 16:05:18 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Db2QQ-0008S6-NW for hipsec@ietf.org; Wed, 25 May 2005 16:24:24 -0400 Received: from inside.nomadiclab.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 20F3D212C40; Wed, 25 May 2005 23:05:09 +0300 (EEST) Date: Wed, 25 May 2005 23:05:09 +0300 (EEST) From: Petri Jokela To: "Henderson, Thomas R" Subject: RE: [Hipsec] Pre-version: ESP draft In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> Message-ID: References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Tue, 24 May 2005, Henderson, Thomas R wrote: > 1) There is presently one open issue in the HIP WG issue tracker for > this draft (http://hip4inter.net/cgi-bin/roundup.cgi/hip-esp/index). Unfortunately, the ESP tracker has been broken (seems to work now...) and is badly out of date. > So maybe this issue is now closed? I closed the original issue. > 5) At the Minneapolis WG meeting, when we were discussing future > extensibility of HIP, Pekka brought up a suggestion that we maybe > renumber the parameters and message types so as to leave some > room for insertion. Although mainly a base spec issue, I bring > this up here because we have selected ESP_INFO to be parameter > number 1 (so that it is easily accessible for inspection by > middleboxes). > > Do we want to leave some room at the top end of this parameter > space for future parameters, and get better spacing between > the ones we have? I'll see this together with the base spec parameter numbering and make a new proposal about numbering. I opened some issues on the tracker related to rest of the comments. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon May 30 07:46:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcij6-00024W-QT; Mon, 30 May 2005 07:46:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dcij5-00024Q-HT for hipsec@megatron.ietf.org; Mon, 30 May 2005 07:46:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07799 for ; Mon, 30 May 2005 07:46:34 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dcj2T-0006wq-9x for hipsec@ietf.org; Mon, 30 May 2005 08:06:38 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 22340212C40; Mon, 30 May 2005 14:46:23 +0300 (EEST) Message-ID: <429AFD0F.2040002@nomadiclab.com> Date: Mon, 30 May 2005 14:46:23 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Petri Jokela References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B66@xch-nw-27.nw.nos.boeing.com> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] Numbering of TLVs 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Petri Jokela wrote: > On Tue, 24 May 2005, Henderson, Thomas R wrote: >> 5) At the Minneapolis WG meeting, when we were discussing future >> extensibility of HIP, Pekka brought up a suggestion that we maybe >> renumber the parameters and message types so as to leave some >> room for insertion. Although mainly a base spec issue, I bring >> this up here because we have selected ESP_INFO to be parameter >> number 1 (so that it is easily accessible for inspection by >> middleboxes). >> >> Do we want to leave some room at the top end of this parameter >> space for future parameters, and get better spacing between >> the ones we have? > > > I'll see this together with the base spec parameter numbering and make a > new proposal about numbering. > > I opened some issues on the tracker related to rest of the comments. Here is a set type values for TLVs to get some space for possible additions (in the type value area 1-511). Comments on the following values? OLD NEW ESP draft: ESP_INFO 1 41 Base draft: R1_COUNTER 2 64 PUZZLE 5 91 SOLUTION 7 101 SEQ 11 131 ACK 13 141 DIFFIE_HELLMAN 15 171 HIP_TRANSFORM 17 201 ENCRYPTED 21 257 HOST_ID 35 321 CERT 64 384 NOTIFY 256 448 /Petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 31 09:15:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd6as-0007yI-G8; Tue, 31 May 2005 09:15:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd6ap-0007y5-UO for hipsec@megatron.ietf.org; Tue, 31 May 2005 09:15:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07882 for ; Tue, 31 May 2005 09:15:38 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd6uS-0002GK-Do for hipsec@ietf.org; Tue, 31 May 2005 09:35:56 -0400 Received: from inside.nomadiclab.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id DBAB2212C40; Tue, 31 May 2005 16:15:27 +0300 (EEST) Date: Tue, 31 May 2005 16:15:27 +0300 (EEST) From: Petri Jokela To: "Ahrenholz, Jeffrey M" In-Reply-To: <0DF156EE7414494187B087A3C279BDB40D7EF0@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: References: <0DF156EE7414494187B087A3C279BDB40D7EF0@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: hipsec@ietf.org Subject: [Hipsec] ESP draft snapshot 31.05.05 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I uploaded the ESP draft (snapshot + diff from previous) to: http://hip4inter.net/drafts.php (version dated 31.05.05) There are three open issues at the moment in the roundup tracker http://hip4inter.net/cgi-bin/roundup.cgi/hip-esp/index Two of them are commented inline in the following answer. In addition to those, the security section is still empty. Fixed also: timeout issue (issue #2), renumbering of ESP_INFO (issue #3), and ESP_INFO definition (issue #5). On Mon, 16 May 2005, Ahrenholz, Jeffrey M wrote: > Date: Mon, 16 May 2005 11:42:55 -0700 > From: "Ahrenholz, Jeffrey M" > To: Petri Jokela , hipsec@ietf.org > Subject: RE: [Hipsec] Pre-version: ESP and Base drafts > > - section "ESP packet processing" > "As these mechanisms can be located..." - this sentence is unclear to > me, but I do not have a suggested rewrite. I made a change to the text. "These mechanisms can be considered to be on the network side of IPsec, thus they cannot add any integrity or conficentiality problems that would not exist without them." Is this any better? > - For all AES references (3 occurrences), RFC 2451 should be RFC 3602; > RFC 2451 contains no mention of AES, should be removed from references Fixed. > - The 64-bit sequence number is interesting, but: To implement it, you > just keep an additional 32-bit counter representing the upper bits? Upon > rollover of the lower 32-bits, you increment the upper. What is the > usefulness of this? i.e. how can the replay window be enforced if it is > not part of each packet? Maybe we could have more text on this or an > appropriate reference. Hmm.. I'm not sure how to fix this. Earlier there was some talk about having AES-CBC IV vectors from the sequence number, but the RFC3602 states that the IV must be random. > - For the sentence "...exchange information about the used protocols and > other...", is there another term besides "used protocols" that should be > used here, such as "transforms used"? Fixed as proposed. > - the key index field of the ESP_INFO parameter is mentioned for the > rekeying section, but not in the preceding section when discussing the > ESP_INFO. I couldn't now find the place in text. Can you give a pointer to that? > - When talking about the IP address to HIT conversion, what about the > IPv4 case? Should LSIs be mentioned also? A new bullet in "Processing incoming application data": If LSIs are used, the address field is converted to contain the LSI value before the packet is sent to the application. > - In the "finalizing rekeying" section it says to use the lowest Keymat > Index of the two ESP_INFO parameters, but earlier in the > "transform_reply" section, is says "it is RECOMMENDED that the system > use the greater value received from the peer" ??? Fixed this. It should bet the greater of the two values. > - It should be noted somewhere that HIP packets should bypass IPsec > policies, i.e. UPDATE packet transmitted in the clear even though an > active association is in place, or all protocol 99 packets bypass IPsec > processing, etc. 6. Packet processing Packet processing is mainly defined in the HIP base specification [5]. This section describes the changes and new requirements for packet handling when the ESP transport format is used. Note that all HIP packets (currently protocol 99) MUST bypass IPsec processing. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 31 11:04:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8Hq-0007XP-Ty; Tue, 31 May 2005 11:04:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8Hp-0007Wv-5L for hipsec@megatron.ietf.org; Tue, 31 May 2005 11:04:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16793 for ; Tue, 31 May 2005 11:04:07 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd8bO-0004La-L3 for hipsec@ietf.org; Tue, 31 May 2005 11:24:27 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA08831; Tue, 31 May 2005 10:03:50 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4VF3op04267; Tue, 31 May 2005 10:03:50 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 08:03:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 May 2005 08:03:47 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C066493BA@xch-nw-27.nw.nos.boeing.com> Thread-Topic: Numbering of TLVs Thread-Index: AcVlDTXV3X4lvwWcQZmp8TGMtWRBUAA23Hcg From: "Henderson, Thomas R" To: "Petri Jokela" X-OriginalArrivalTime: 31 May 2005 15:03:47.0969 (UTC) FILETIME=[F27C6710:01C565F1] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org Subject: [Hipsec] RE: Numbering of TLVs 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Comments on the following values? >=20 > OLD NEW > ESP draft: > ESP_INFO 1 41 >=20 > Base draft: > R1_COUNTER 2 64 > PUZZLE 5 91 > SOLUTION 7 101 > SEQ 11 131 > ACK 13 141 > DIFFIE_HELLMAN 15 171 > HIP_TRANSFORM 17 201 > ENCRYPTED 21 257 > HOST_ID 35 321 > CERT 64 384 > NOTIFY 256 448 >=20 I strongly support getting improved spacing. I have been staring at the above list for a few minutes, trying to discern the numbering pattern. Is there one? The numbering patterns that seem to be in effect are: - parameters protected by signature are in the range 1-4096 - except for nonces and transforms, the range is really 1-511 - nonces are numbered in the range 1022-1024 - transforms are numbered 2048-4096 - crypto parameters are numbered between (2^16 - 291) and (2^16 - 257) While we are doing this, we should consider also the known parameters that exist in the other core drafts, and that are likely to form the complete set of parameters approved in this cycle of WG documents: OLD ESP_INFO 1 R1_COUNTER 2 LOCATOR 3 PUZZLE 5 SOLUTION 7 SEQ 11 ACK 13 DIFFIE_HELLMAN 15 HIP_TRANSFORM 17 ENCRYPTED 21 HOST_ID 35 CERT 64 NOTIFY 256 ECHO_REQUEST 1022 ECHO_RESPONSE 1024 ESP_TRANSFORM 2048=09 HMAC 65245 HMAC_2 65247 HIP_SIGNATURE_2 65277 HIP_SIGNATURE 65279 ECHO_REQUEST 65281 ECHO_RESPONSE 65283 FROM 65470 RVS_HMAC 65472 VIA_RVS 65474 I think it might be useful to state the numbering rationale, and then go for equal spacing in the various sub-ranges: "Because the ordering (from lowest to highest) of HIP parameters is strictly enforced, the parameter type values for existing parameters have been spaced to allow for future protocol extensions. Parameters numbered between 0-1023 are used in HIP handshake and update procedures and are covered by signatures. Parameters numbered between 1024-2047 are reserved. Parameters numbered between 2048-4095 are used for parameters related to HIP transform types. Parameters numbered between 4096 and (2^16 - 2^12) 61439 are reserved. Parameters numbered beteween 61440-62463 are used for signatures and signed MACs. Parameters numbered between 62464-63487 are used for parameters that fall outside of the signed area of the packet. Parameters numbered between 63488-64511 are used for rendezvous and other relaying services. Parameters numbered between 64512-65535 are reserved." Then, I suggest taking these ranges and allocating each parameter to be roughly equally spaced by some increment, and in the future, if we need to insert a new parameter between two existing ones, it is numbered to split the difference between the two, etc. For example: OLD NEW ESP_INFO 1 65 (2^6+1) R1_COUNTER 2 128 (2*2^6) LOCATOR 3 193 (3*2^6 + 1, etc.) PUZZLE 5 257 SOLUTION 7 321 SEQ 11 385 ACK 13 449 DIFFIE_HELLMAN 15 513 HIP_TRANSFORM 17 577 ENCRYPTED 21 641 HOST_ID 35 705 CERT 64 768 NOTIFY 256 832 ECHO_REQUEST 1022 896 ECHO_RESPONSE 1024 960 ESP_TRANSFORM 2048 2048 HMAC 65245 61505=09 HMAC_2 65247 61569 HIP_SIGNATURE_2 65277 61633 HIP_SIGNATURE 65279 61697 ECHO_REQUEST 65281 63661 ECHO_RESPONSE 65283 63425 FROM 65470 63552 RVS_HMAC 65472 63616 VIA_RVS 65474 63680 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 31 11:16:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8U3-0001W5-2P; Tue, 31 May 2005 11:16:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd8U1-0001Vj-9D for hipsec@megatron.ietf.org; Tue, 31 May 2005 11:16:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17795 for ; Tue, 31 May 2005 11:16:43 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd8ne-0004cx-SR for hipsec@ietf.org; Tue, 31 May 2005 11:37:03 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA24587; Tue, 31 May 2005 10:16:34 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4VFGYp24556; Tue, 31 May 2005 10:16:34 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 08:16:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 May 2005 08:16:26 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C04060B8A@xch-nw-27.nw.nos.boeing.com> Thread-Topic: ECHO_* parameters Thread-Index: AcVlDTXV3X4lvwWcQZmp8TGMtWRBUAA5VfIg From: "Henderson, Thomas R" To: "Petri Jokela" X-OriginalArrivalTime: 31 May 2005 15:16:27.0468 (UTC) FILETIME=[B72EC0C0:01C565F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org Subject: [Hipsec] ECHO_* parameters 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org The ECHO_REQUEST and ECHO_RESPONSE are listed as non-critical parameters inside the signature, and critical outside the signature. As presently defined, they should be "critical" in both places. While their use is optional in some packets, it seems to me that if ECHO_REQUEST is present, ECHO_RESPONSE MUST be sent. At least this is the case in the CLOSE/CLOSE_ACK packets. Tom=20 _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue May 31 12:23:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd9WL-0003qH-CB; Tue, 31 May 2005 12:23:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dd9WI-0003qC-SY for hipsec@megatron.ietf.org; Tue, 31 May 2005 12:23:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22973 for ; Tue, 31 May 2005 12:23:08 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dd9pv-00060t-Vl for hipsec@ietf.org; Tue, 31 May 2005 12:43:29 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA19159; Tue, 31 May 2005 09:22:57 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j4VGMun26698; Tue, 31 May 2005 09:22:56 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 31 May 2005 09:22:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 May 2005 09:21:59 -0700 Message-ID: <0DF156EE7414494187B087A3C279BDB40D7F21@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: ESP draft snapshot 31.05.05 Thread-Index: AcVl4tIPMmZWKAXGR0q6qX7a0KLKmwAE18mQ From: "Ahrenholz, Jeffrey M" To: "Petri Jokela" X-OriginalArrivalTime: 31 May 2005 16:22:53.0678 (UTC) FILETIME=[FF2620E0:01C565FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org Subject: [Hipsec] RE: ESP draft snapshot 31.05.05 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Petri, please see below... > "These mechanisms can be considered to be on the network side=20 > of IPsec,=20 > thus they cannot add any integrity or conficentiality=20 > problems that would=20 > not exist without them." >=20 > Is this any better? Yes, this is better. > > - The 64-bit sequence number is interesting, but: To=20 > implement it, you=20 > > just keep an additional 32-bit counter representing the=20 > upper bits? Upon=20 > > rollover of the lower 32-bits, you increment the upper. What is the=20 > > usefulness of this? i.e. how can the replay window be=20 > enforced if it is=20 > > not part of each packet? Maybe we could have more text on=20 > this or an=20 > > appropriate reference. >=20 > Hmm.. I'm not sure how to fix this. Earlier there was some talk about=20 > having AES-CBC IV vectors from the sequence number, but the=20 > RFC3602 states=20 > that the IV must be random. So is there a benefit to using these 64-bit sequence numbers? Why do we need them? > > - the key index field of the ESP_INFO parameter is=20 > mentioned for the=20 > > rekeying section, but not in the preceding section when=20 > discussing the=20 > > ESP_INFO. >=20 > I couldn't now find the place in text. Can you give a pointer to that? (using pre310505) Section 4.1.2 Updating an Existing ESP SA -- this mentions the keymat index. Section 4.1.1 Setting up an ESP Security Association -- this contains no mention of the keymat index. The keymat index is described in detail in 5.1.1 ESP_INFO, then for packet processing, it is described for sections 6.8, 6.9, 6.9.1, 6.9.2, 6.9.3, 6.10, but not in sections 6.5 and 6.6. Section 7 Keying Material says "After the HIP association keys have been drawn, the ESP keys are drawn..." and this is the first advice given to the reader on what value the keymat index should have during the base exchange. The other various revisions noted in this email look good. -Jeff _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 01 03:47:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdNwQ-0008IB-AR; Wed, 01 Jun 2005 03:47:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdNwO-0008I6-Pb for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 03:47:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02719 for ; Wed, 1 Jun 2005 03:47:02 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdOGA-0002xO-A1 for hipsec@ietf.org; Wed, 01 Jun 2005 04:07:31 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 809D0212C40; Wed, 1 Jun 2005 10:46:54 +0300 (EEST) Message-ID: <429D67EE.7030908@nomadiclab.com> Date: Wed, 01 Jun 2005 10:46:54 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" References: <6938661A6EDA8A4EA8D1419BCE46F24C04060B8A@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C04060B8A@xch-nw-27.nw.nos.boeing.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] Re: ECHO_* parameters 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Henderson, Thomas R wrote: > The ECHO_REQUEST and ECHO_RESPONSE are listed as non-critical parameters > inside the signature, and critical outside the signature. > > As presently defined, they should be "critical" in both places. While > their use is optional in some packets, it seems to me that if > ECHO_REQUEST is present, ECHO_RESPONSE MUST be sent. At least this is > the case in the CLOSE/CLOSE_ACK packets. True. This was indicated by Jeff at some point, and changed to the previous version (25.5.05). /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 01 04:03:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdOCC-0002Ti-F2; Wed, 01 Jun 2005 04:03:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdOCA-0002Td-FH for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 04:03:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03747 for ; Wed, 1 Jun 2005 04:03:20 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdOVv-0003ma-Lr for hipsec@ietf.org; Wed, 01 Jun 2005 04:23:49 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 883F6212C40; Wed, 1 Jun 2005 11:03:11 +0300 (EEST) Message-ID: <429D6BBF.7060501@nomadiclab.com> Date: Wed, 01 Jun 2005 11:03:11 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Henderson, Thomas R" References: <6938661A6EDA8A4EA8D1419BCE46F24C066493BA@xch-nw-27.nw.nos.boeing.com> In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C066493BA@xch-nw-27.nw.nos.boeing.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] Re: Numbering of TLVs 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > have been spaced to allow for future protocol extensions. Parameters > numbered between 0-1023 are used in HIP handshake and update procedures Was there any reasoning ealier to put them below 512? > to insert a new parameter between two existing ones, it is numbered to > split the difference between the two, etc. Ok. Any objections to the proposed numbering? > For example: > OLD NEW > ESP_INFO 1 65 (2^6+1) > R1_COUNTER 2 128 (2*2^6) > LOCATOR 3 193 (3*2^6 + 1, etc.) > PUZZLE 5 257 > SOLUTION 7 321 > SEQ 11 385 > ACK 13 449 > DIFFIE_HELLMAN 15 513 > HIP_TRANSFORM 17 577 > ENCRYPTED 21 641 > HOST_ID 35 705 > CERT 64 768 > NOTIFY 256 832 > > ECHO_REQUEST 1022 896 > ECHO_RESPONSE 1024 960 > > ESP_TRANSFORM 2048 2048 > > HMAC 65245 61505 > HMAC_2 65247 61569 > HIP_SIGNATURE_2 65277 61633 > HIP_SIGNATURE 65279 61697 > > ECHO_REQUEST 65281 63661 > ECHO_RESPONSE 65283 63425 > > FROM 65470 63552 > RVS_HMAC 65472 63616 > VIA_RVS 65474 63680 /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 01 07:03:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdR0Y-0002he-VU; Wed, 01 Jun 2005 07:03:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdR0X-0002gn-Db for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 07:03:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03814 for ; Wed, 1 Jun 2005 07:03:30 -0400 (EDT) Received: from newyork.ucdavis.edu ([169.237.104.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdRKK-00044g-HH for hipsec@ietf.org; Wed, 01 Jun 2005 07:24:02 -0400 Received: from citheronia.ucdavis.edu (citheronia.ucdavis.edu [169.237.104.183]) by newyork.ucdavis.edu (8.13.3/8.13.1/it-defang-5.3.0) with ESMTP id j51B3TlE029037 for ; Wed, 1 Jun 2005 04:03:29 -0700 (PDT) Received: from citheronia.ucdavis.edu (localhost [127.0.0.1]) by citheronia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j51B3TgD022691 for ; Wed, 1 Jun 2005 04:03:29 -0700 (PDT) Received: (from www@localhost) by citheronia.ucdavis.edu (8.12.10/8.12.9/Submit) id j51B3T3r022690; Wed, 1 Jun 2005 04:03:29 -0700 (PDT) Date: Wed, 1 Jun 2005 04:03:29 -0700 (PDT) Message-Id: <200506011103.j51B3T3r022690@citheronia.ucdavis.edu> To: hipsec@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [Hipsec] Deadline extended: JSAC-MRNM 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY The deadline is extened until June 5th. http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications nad models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 5, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 01 08:17:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdS9x-00076s-Rt; Wed, 01 Jun 2005 08:17:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdS9w-00076l-3l for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 08:17:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11164 for ; Wed, 1 Jun 2005 08:17:16 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdSTj-0008CX-7M for hipsec@ietf.org; Wed, 01 Jun 2005 08:37:48 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 1D7E8212C40; Wed, 1 Jun 2005 15:17:07 +0300 (EEST) Message-ID: <429DA742.7040508@nomadiclab.com> Date: Wed, 01 Jun 2005 15:17:06 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <0DF156EE7414494187B087A3C279BDB40D7F21@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DF156EE7414494187B087A3C279BDB40D7F21@XCH-NW-6V1.nw.nos.boeing.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] Re: ESP draft snapshot 31.05.05 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Ahrenholz, Jeffrey M wrote: > Petri, > please see below... >>I couldn't now find the place in text. Can you give a pointer to that? > > > (using pre310505) > Section 4.1.2 Updating an Existing ESP SA -- this mentions the keymat > index. > Section 4.1.1 Setting up an ESP Security Association -- this contains no > mention of the keymat index. > The keymat index is described in detail in 5.1.1 ESP_INFO, then for > packet processing, it is described for sections 6.8, 6.9, 6.9.1, 6.9.2, > 6.9.3, 6.10, but not in sections 6.5 and 6.6. > > Section 7 Keying Material says "After the HIP association keys have been > drawn, the ESP keys are drawn..." and this is the first advice given to > the reader on what value the keymat index should have during the base > exchange. Some fixes: 4.1.1: "...be used by the peer host. The ESP_INFO Keymat Index value MUST be set to zero." 6.5 (provided already by Tom): "For this initial ESP SA establishment, the Old SPI value MUST be zero. The Keymat Index field MUST be zero." 6.6: "...to the peer. The ESP_INFO Keymat Index field MUST be zero." Question: should the Keymat Index be something else than zero during the base exchange? Basically, the Keymat Index points to the place where keys are drawn and in _this_ specification we are defining ESP_INFO that is used to get the ESP SA established. We are not "interested" in HIP keys. Thus, the Keymat Index during the base exchange should point already to the point from where the ESP keys are drawn. Of course, keeping the Keymat Index value zero during base exchange, does not break anything because we say that the ESP keys are drawn after the HIP association keys. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 01 10:54:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUc2-0000VU-OV; Wed, 01 Jun 2005 10:54:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUc1-0000VP-Lg for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 10:54:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23373 for ; Wed, 1 Jun 2005 10:54:27 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdUvq-0007r2-Iw for hipsec@ietf.org; Wed, 01 Jun 2005 11:15:00 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA14166; Wed, 1 Jun 2005 07:54:11 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j51EsAp04870; Wed, 1 Jun 2005 09:54:10 -0500 (CDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 07:53:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Re: ESP draft snapshot 31.05.05 Date: Wed, 1 Jun 2005 07:53:45 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C066493CB@xch-nw-27.nw.nos.boeing.com> Thread-Topic: [Hipsec] Re: ESP draft snapshot 31.05.05 Thread-Index: AcVmpBEyPQExUKIcQni4pHOza7g8HQAFSQaQ From: "Henderson, Thomas R" To: "Petri Jokela" X-OriginalArrivalTime: 01 Jun 2005 14:53:46.0294 (UTC) FILETIME=[B645D560:01C566B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Wednesday, June 01, 2005 5:17 AM > To: Ahrenholz, Jeffrey M > Cc: hipsec@ietf.org > Subject: [Hipsec] Re: ESP draft snapshot 31.05.05 >=20 >=20 > Question: should the Keymat Index be something else than zero=20 > during the > base exchange? Basically, the Keymat Index points to the place where > keys are drawn and in _this_ specification we are defining=20 > ESP_INFO that > is used to get the ESP SA established. We are not "interested" in HIP > keys. Thus, the Keymat Index during the base exchange should point > already to the point from where the ESP keys are drawn. >=20 > Of course, keeping the Keymat Index value zero during base exchange, > does not break anything because we say that the ESP keys are=20 > drawn after > the HIP association keys. >=20 I had similar thoughts when reviewing it. The only argument that I could see for having it be zero is if it were burdensome to compute the actual offset when ESP_INFO is created because possibly the HIP key sizes are not known yet. But I do not think such a case applies. =20 So I would vote for keeping it consistent as you suggest-- even during base exchange, it points to the right place to start drawing ESP keys (not zero). Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 01 10:56:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUdz-0000sI-4e; Wed, 01 Jun 2005 10:56:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdUdx-0000s5-Gi for hipsec@megatron.ietf.org; Wed, 01 Jun 2005 10:56:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23593 for ; Wed, 1 Jun 2005 10:56:27 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdUxm-00080b-Ke for hipsec@ietf.org; Wed, 01 Jun 2005 11:17:00 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA24454; Wed, 1 Jun 2005 07:56:16 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j51EuFn00893; Wed, 1 Jun 2005 07:56:15 -0700 (PDT) Received: from XCH-NW-27.nw.nos.boeing.com ([192.48.4.101]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Jun 2005 07:56:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Jun 2005 07:56:15 -0700 Message-ID: <6938661A6EDA8A4EA8D1419BCE46F24C066493CC@xch-nw-27.nw.nos.boeing.com> Thread-Topic: Numbering of TLVs Thread-Index: AcVmgGMrVP1x1WlkS8ulFkoBtfeYZgAOWmMA From: "Henderson, Thomas R" To: "Petri Jokela" X-OriginalArrivalTime: 01 Jun 2005 14:56:15.0483 (UTC) FILETIME=[0F3244B0:01C566BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: hipsec@ietf.org Subject: [Hipsec] RE: Numbering of TLVs 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Petri Jokela [mailto:petri.jokela@nomadiclab.com]=20 > Sent: Wednesday, June 01, 2005 1:03 AM > To: Henderson, Thomas R > Cc: hipsec@ietf.org > Subject: Re: Numbering of TLVs >=20 >=20 > > have been spaced to allow for future protocol extensions. =20 > Parameters > > numbered between 0-1023 are used in HIP handshake and=20 > update procedures >=20 > Was there any reasoning ealier to put them below 512? I do not know any such reason. The below scheme is somewhat arbitrary too, but one has to draw lines somewhere. >=20 > > to insert a new parameter between two existing ones, it is=20 > numbered to > > split the difference between the two, etc. >=20 > Ok. Any objections to the proposed numbering? >=20 > >=20 > > ECHO_REQUEST 1022 896 > > ECHO_RESPONSE 1024 960 > >=20 Just that these should also be bumped up by 1 (as per previous message on critical bit for these parameters). Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 02 01:50:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddiax-0003VP-FP; Thu, 02 Jun 2005 01:50:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ddiaw-0003Ty-L7 for hipsec@megatron.ietf.org; Thu, 02 Jun 2005 01:50:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13880 for ; Thu, 2 Jun 2005 01:50:17 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddiut-0006vP-Fj for hipsec@ietf.org; Thu, 02 Jun 2005 02:10:57 -0400 Received: from localhost (n51.nomadiclab.com [193.234.219.51]) by n2.nomadiclab.com (Postfix) with ESMTP id 8400F212C40; Thu, 2 Jun 2005 08:50:06 +0300 (EEST) From: Jan Mikael Melen Date: Thu, 2 Jun 2005 08:49:29 +0300 User-Agent: KMail/1.7.1 To: mobike@machshav.com, hipsec@ietf.org MIME-Version: 1.0 Message-Id: <200506020849.37110.Jan.Melen@nomadiclab.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [Hipsec] Fwd: I-D ACTION:draft-nikander-esp-beet-mode-03.txt 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: , Content-Type: multipart/mixed; boundary="===============0923127224==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============0923127224== Content-Type: multipart/signed; boundary="nextPart3897362.bIfzanmjPT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart3897362.bIfzanmjPT Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit ---------- Forwarded Message ---------- Subject: I-D ACTION:draft-nikander-esp-beet-mode-03.txt Date: Wednesday 01 June 2005 23:03 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bound End-to-End Tunnel (BEET) mode for ESP Author(s) : P. Nikander, J. Melen Filename : draft-nikander-esp-beet-mode-03.txt Pages : 29 Date : 2005-6-1 This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nikander-esp-beet-mode-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nikander-esp-beet-mode-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------- --nextPart3897362.bIfzanmjPT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCnp3wp4iklvjQtTgRAh1LAJ907tNq0IQuGRsavEROBWwxo5UYbQCfXqrk Rj3R0thZ5HV+o8zubBMJBNA= =P7Xo -----END PGP SIGNATURE----- --nextPart3897362.bIfzanmjPT-- --===============0923127224== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0923127224==-- From hipsec-bounces@lists.ietf.org Fri Jun 03 08:57:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBju-0002e4-Al; Fri, 03 Jun 2005 08:57:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DeBjt-0002dt-1u for hipsec@megatron.ietf.org; Fri, 03 Jun 2005 08:57:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24225 for ; Fri, 3 Jun 2005 08:57:27 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DeC44-0003KR-E4 for hipsec@ietf.org; Fri, 03 Jun 2005 09:18:23 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 19A20212C40 for ; Fri, 3 Jun 2005 15:57:12 +0300 (EEST) Message-ID: <42A053A7.5060705@nomadiclab.com> Date: Fri, 03 Jun 2005 15:57:11 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] ESP draft snapshot 03.06.2005 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org The latest version of ESP usage with HIP is available at http://hip4inter.net/drafts.php (date 03.06.05) - Initial version of the security considerations section has been written. - IANA consideratios has been added (two new parameter types). - Few fixes (see the diff file between 31.05 and this version). o During base exchange, keymat index points to the ESP SA keys o REKEYING state taken away completely o few typos known, 6.9.3: Pfaket, empty bullet 5 I haven't yet made any changes regarding possible problems when UDPATEs are crossing each other. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 06 11:07:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJBx-00067E-MJ; Mon, 06 Jun 2005 11:07:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DfJBv-000674-Lj for hipsec@megatron.ietf.org; Mon, 06 Jun 2005 11:07:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08705 for ; Mon, 6 Jun 2005 11:07:01 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DfJWl-00036m-0k for hipsec@ietf.org; Mon, 06 Jun 2005 11:28:37 -0400 Received: from [192.168.10.123] (62.206.52.42) by mx.laposte.net (7.0.028) (authenticated as julien.laganier) id 4291895A00846412; Mon, 6 Jun 2005 17:06:43 +0200 From: Julien Laganier To: namedroppers@ops.ietf.org User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Disposition: inline Date: Mon, 6 Jun 2005 16:20:50 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200506061620.53254.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] review of draft-ietf-hip-dns-01 (DNS extension for 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Dear dnsext members, I am editor for draft-ietf-hip-dns-01 (DNS extensions for the Host Identity Protocol), which defines two new RRs for storing HIP nodes public keys and rendezvous servers IP addresses in the DNS. Our intent is to publish it as an EXPERIMENTAL RFC to allow further experimentations with HIP. Because the document is now quite mature w.r.t. to the HIP WG, I'd like to solicit some help from the DNS experts to do a cross-area review of the document (which is short and very similar to RFC4025 - IPSECKEY RR). Do you have an idea of the best way to proceed? Thanks. Best Regards, -- Julien Laganier _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 09 06:59:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgKko-0006Go-69; Thu, 09 Jun 2005 06:59:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgKkm-0006Ec-LF for hipsec@megatron.ietf.org; Thu, 09 Jun 2005 06:59:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13253 for ; Thu, 9 Jun 2005 06:59:13 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgL5j-000472-1i for hipsec@ietf.org; Thu, 09 Jun 2005 07:20:56 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 5F14F212C40 for ; Thu, 9 Jun 2005 13:58:11 +0300 (EEST) Message-ID: <42A820C3.4050202@nomadiclab.com> Date: Thu, 09 Jun 2005 13:58:11 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] ESP draft - state machine and simultaneous UPDATEs 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, We tried to figure out how the system should behave when UPDATE messages for rekeying or ESP transform changes are initiated simultaneously and cross each other in the network. With the current UPDATE ACK system the state machine became a chaos because the ACK is not necessarily included in the response packet (response packet = response to the change request, not response to the UPDATE packet), but can arrive in a separate UPDATE packet later. One way to manage this is to make it mandatory to send the ACK in the same packet as SEQ in the following way: UPD(SEQ...) ----------------> UPD(SEQ, ACK...) <---------------- UPD(ACK) ----------------> This would help a host that has initialized rekeying/family change so that it knows if the received packet is an answer or if it is an initialization message. The other way would be to include some "initialization" parameter in the ESP_INFO/ESP_TRANSFORM parameters that could be used to track the packets. But that would be adding yet another acknowledgement system on top of the UPDATE ack system. We created a following state machine, when the middle UPDATE message must contain both SEQ and ACK: EI = ESP_INFO TR = ESP_TRANSFORM [C] = conditional, the behaviour is based on the HIT value comparison (if local HIT is greater, choose one path and if smaller, choose the other path) DIFFIE_HELLMAN is not included in the picture, as it is OPTIONAL and not necessary included in messages to both directions TR_CH_IN = ESP transform family change initiated by the peer host TR_CH_OUT = ESP transform family change initiated by this host REKEY_IN = rekeying initiated by the peer host REKEY_OUT = rekeying initiated by this host +---------------------------------------+[C]<-+ | | | |out: EI+TR+ACK (drop)| |in: EI+TR V V | +-----------+ +-----------+ +>| TR_CH_IN |<-----------+ +------->| TR_CH_OUT | | +-----------+ | | +-----------+ | | | | | ^ in: EI | | in: EI+TR| | | | out: EI+TR | | out: EI+TR+ACK| |out: EI+TR +--+ | | | | | | | | | |in: ACK | | | | | | | | +-------------+ | +-------------->| ESTABLISHED |<---------+ | +-------------+ | | | ^ | |in: EI+ACK | +------------+ | | |out: ACK | | | | | | |in: EI | |out: EI | | |out: EI+ACK | | | | | | | | | v | | | | +-----------+ | | +-----------+ | | REKEY_IN |---------------+ +------->| REKEY_OUT | | +-----------+ in: ACK +-----------+ | | ^ ^ | ^ | | | | | in: EI | | | | +--+ | V |drop | in: EI+TR | in: EI +--------------------------------[C]-+ | out:EI+TR+ACK | out: EI+ACK out: EI+ACK | | | +--------------------------------------------------------+ /Petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 09 10:14:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNoA-0000vO-Bp; Thu, 09 Jun 2005 10:14:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNo5-0000uX-61 for hipsec@megatron.ietf.org; Thu, 09 Jun 2005 10:14:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04786 for ; Thu, 9 Jun 2005 10:14:49 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgO9W-0005Qr-Jz for hipsec@ietf.org; Thu, 09 Jun 2005 10:37:03 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 80460212C3D; Thu, 9 Jun 2005 17:14:29 +0300 (EEST) In-Reply-To: <42A820C3.4050202@nomadiclab.com> References: <42A820C3.4050202@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] ESP draft - state machine and simultaneous UPDATEs Date: Thu, 9 Jun 2005 10:14:28 -0400 To: Petri Jokela X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I don't have time to consider this now in detail, but just an idea: Can't we apply ideas from the TCP state machine? It allows SYNs and FINs to be crossing in parallel and handles them nicely, and IIRC in a simpler way than what you are now suggesting. --Pekka On Jun 9, 2005, at 6:58, Petri Jokela wrote: > Hi, > > We tried to figure out how the system should behave when UPDATE > messages > for rekeying or ESP transform changes are initiated simultaneously and > cross each other in the network. With the current UPDATE ACK system the > state machine became a chaos because the ACK is not necessarily > included > in the response packet (response packet = response to the change > request, not response to the UPDATE packet), but can arrive in a > separate UPDATE packet later. > > One way to manage this is to make it mandatory to send the ACK in the > same packet as SEQ in the following way: > > > UPD(SEQ...) > ----------------> > UPD(SEQ, ACK...) > <---------------- > UPD(ACK) > ----------------> > > This would help a host that has initialized rekeying/family change so > that it knows if the received packet is an answer or if it is an > initialization message. > > The other way would be to include some "initialization" parameter in > the > ESP_INFO/ESP_TRANSFORM parameters that could be used to track the > packets. But that would be adding yet another acknowledgement system on > top of the UPDATE ack system. > > We created a following state machine, when the middle UPDATE message > must contain both SEQ and ACK: > > EI = ESP_INFO > TR = ESP_TRANSFORM > [C] = conditional, the behaviour is based on the HIT value comparison > (if local HIT is greater, choose one path and if smaller, choose the > other path) > > DIFFIE_HELLMAN is not included in the picture, as it is OPTIONAL and > not > necessary included in messages to both directions > > TR_CH_IN = ESP transform family change initiated by the peer host > TR_CH_OUT = ESP transform family change initiated by this host > REKEY_IN = rekeying initiated by the peer host > REKEY_OUT = rekeying initiated by this host > > > +---------------------------------------+[C]<-+ > | | | > |out: EI+TR+ACK (drop)| |in: EI+TR > V V | > +-----------+ +-----------+ > +>| TR_CH_IN |<-----------+ +------->| TR_CH_OUT | > | +-----------+ | | +-----------+ > | | | | | ^ in: EI > | | in: EI+TR| | | | out: EI+TR > | | out: EI+TR+ACK| |out: EI+TR +--+ > | | | | > | | | | > | |in: ACK | | > | | | | > | | +-------------+ > | +-------------->| ESTABLISHED |<---------+ > | +-------------+ | > | | ^ | |in: EI+ACK > | +------------+ | | |out: ACK > | | | | | > | |in: EI | |out: EI | > | |out: EI+ACK | | | > | | | | | > | v | | | > | +-----------+ | | +-----------+ > | | REKEY_IN |---------------+ +------->| REKEY_OUT | > | +-----------+ in: ACK +-----------+ > | | ^ ^ | ^ | > | | | | in: EI | | | > | +--+ | V |drop | in: EI+TR > | in: EI +--------------------------------[C]-+ | > out:EI+TR+ACK > | out: EI+ACK out: EI+ACK | > | | > +--------------------------------------------------------+ > > > /Petri > > > -- > Petri Jokela Tel: +358 9 299 2413 > Research scientist Fax: +358 9 299 3535 > NomadicLab, Ericsson Research Mobile: +358 44 299 2413 > Oy L M Ericsson Ab email: petri.jokela@ericsson.com > > _______________________________________________ > 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 Sun Jun 12 12:00:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhUt3-0000Sc-8C; Sun, 12 Jun 2005 12:00:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhUt1-0000SX-Q3 for hipsec@megatron.ietf.org; Sun, 12 Jun 2005 12:00:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15820 for ; Sun, 12 Jun 2005 12:00:33 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+B/Hj1FmH/SXpYK+6h47+wm9yLuCAggng=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhVF7-0007r6-By for hipsec@ietf.org; Sun, 12 Jun 2005 12:23:26 -0400 Received: from hsi-kbw-085-216-018-203.hsi.kabelbw.de ([85.216.18.203] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DhUsZ-0004xV-6u; Sun, 12 Jun 2005 18:00:13 +0200 Message-ID: <42AC5C02.1000702@tm.uka.de> Date: Sun, 12 Jun 2005 18:00:02 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Thomas Henderson , Pekka Nikander , Gregory Perkins , Jari Arkko , hipsec@ietf.org X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -102.5 (---------------------------------------------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [Hipsec] Review of draft-ietf-hip-mm-01 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: , Content-Type: multipart/mixed; boundary="===============0237114440==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0237114440== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig393013829B1490D394A1C003" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig393013829B1490D394A1C003 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi everybody, reviewing draft-ietf-hip-mm-01, a couple of things came to my mind: (1) Address verification. The draft mentiones in several places that a correspondent host may omit address verification for a mobile or multi-homed peer in case that peer is sufficiently trusted to provide the right addresses. I don't think trust eliminates the need for an address check, however. James Kempf brought this up on the Mobopts mailing list [1]. If we omit the address check for "trusted" nodes, those nodes could still be compromised by malware and start to redirect packets. In other words, a node redirecting packets to the wrong address may not do this by intention; the perpetrator could be someone else who brought that node under his control through a viral software. Admittedly, the use of IPsec ESP would probably require a very sophisticated virus/worm... Anyway, I'd propose to make address verification a MUST in all cases. Note that the verification won't delay communications since we are now using Credit-Based Authorization (CBA). I drafted possible modifications for the affected paragraphs and sent them to the co-editors of draft-ietf-hip-mm-01 as part of my CBA-related modifications. (2) Section 7.1 (Sending LOCATORs) and 7.2 (Handling received LOCATORs): There is mentioning of an "SPI field" inside the LOCATOR parameter. Is this a relict from draft-ietf-hip-mm-00? There used to be a SPI field in the REA parameter, but there is none in the LOCATOR parameter. As far as I understand, the SPI is now part of the Locator field. (3) Section 7.1 (Sending LOCATORs). Paragraph 8 says: "If there are multiple LOCATOR parameters leading to a packet size that exceeds the MTU, the host SHOULD send multiple packets, each smaller than the MTU. In the case of R1 and I2, the additional packets should be UPDATE packets that are sent after the base exchange has been completed." My concern is this: Any locator not in the first packet will (temporarily) be set to DEPRECATED status according to paragraph 5 of this section. Even when it shows up in a subsequent packet, it will first go to UNVERIFIED status, and address verification will have to be accomplished even if the locator was in ACTIVE status before the first packet arrived. So it seems that splitting the locator set over multiple packets would be sub-optimal. Would it be possible to change the semantics of the LOCATOR parameter such that existing locators are not removed when they do not show up? The readdressing host could explicitly remove a locator by advertising it with a zero Locator Lifetime, e.g. Regards, - Christian [1] http://www1.ietf.org/mail-archive/web/mip6/current/msg02936.html -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ --------------enig393013829B1490D394A1C003 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCrFwGwstEk8gl2rURAj19AJ43P05vcYwgUbSZliHdGZwildO/AwCgmq8u wrq/yo53YGvCla4q8OXdtIE= =HrOV -----END PGP SIGNATURE----- --------------enig393013829B1490D394A1C003-- --===============0237114440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0237114440==-- From hipsec-bounces@lists.ietf.org Mon Jun 13 03:14:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhj9j-0004Ta-EI; Mon, 13 Jun 2005 03:14:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhj9f-0004TN-ES for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 03:14:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13510 for ; Mon, 13 Jun 2005 03:14:42 -0400 (EDT) Received: from ntp1.niksula.cs.hut.fi ([130.233.40.5] helo=twilight.cs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhjVt-0005Ce-66 for hipsec@ietf.org; Mon, 13 Jun 2005 03:37:42 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id B25772DB3; Mon, 13 Jun 2005 10:14:24 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 5D2F82DA6; Mon, 13 Jun 2005 10:14:20 +0300 (EEST) In-Reply-To: <42AC5C02.1000702@tm.uka.de> References: <42AC5C02.1000702@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8ce426317c0fae13af48790697ed040a@iki.fi> Content-Transfer-Encoding: 7bit From: Teemu Koponen Subject: Re: [Hipsec] Review of draft-ietf-hip-mm-01 Date: Mon, 13 Jun 2005 00:14:22 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.622) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Jari Arkko 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Jun 12, 2005, at 9:00, Christian Vogt wrote: Christian, > reviewing draft-ietf-hip-mm-01, a couple of things came to my mind: > > (1) Address verification. The draft mentiones in several places that > a > correspondent host may omit address verification for a mobile or > multi-homed peer in case that peer is sufficiently trusted to provide > the right addresses. I don't think trust eliminates the need for an > address check, however. Actually, I have been thinking the same issue of whether to do the address verification or not, but from a slightly different viewpoint. IMHO, there might be certain use cases where you would like to know for sure whether the remote peer is about to send an address verification or not. One example, perhaps a bit artificial though, that comes to my mind is related to power management: a mobile device sends an UPDATE and begins to wait for an UPDATE with ACK. Now, if the device would know whether the peer is *not* about to respond with an address verification check, it could shutdown the transmitter components of its radio right after sending the UPDATE with new locator. Teemu -- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 13 06:31:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhmDi-0001bi-3k; Mon, 13 Jun 2005 06:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhmDN-0001bU-62 for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 06:30:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27397 for ; Mon, 13 Jun 2005 06:30:42 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhmZa-0005Uh-C7 for hipsec@ietf.org; Mon, 13 Jun 2005 06:53:45 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id E2F3B212C3C; Mon, 13 Jun 2005 13:30:18 +0300 (EEST) Message-ID: <42AD603A.2040605@nomadiclab.com> Date: Mon, 13 Jun 2005 13:30:18 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ahrenholz, Jeffrey M" References: <0DF156EE7414494187B087A3C279BDB40D7F21@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <0DF156EE7414494187B087A3C279BDB40D7F21@XCH-NW-6V1.nw.nos.boeing.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org Subject: [Hipsec] Re: ESP draft snapshot 31.05.05 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Ahrenholz, Jeffrey M wrote: >>>- The 64-bit sequence number is interesting, but: To >> >>implement it, you >> >>>just keep an additional 32-bit counter representing the >> >>upper bits? Upon >> >>>rollover of the lower 32-bits, you increment the upper. What is the >>>usefulness of this? i.e. how can the replay window be >> >>enforced if it is >> >>>not part of each packet? Maybe we could have more text on >> >>this or an >> >>>appropriate reference. >> >>Hmm.. I'm not sure how to fix this. Earlier there was some talk about >>having AES-CBC IV vectors from the sequence number, but the >>RFC3602 states >>that the IV must be random. > > > So is there a benefit to using these 64-bit sequence numbers? Why do we > need them? Nobody has reacted on this issue. There seems not to be need for the 64-bit sequence numbers. So, if there is no reason to keep it there I will remove it from the next version. Comments? /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 13 08:20:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhnvE-0002SM-8N; Mon, 13 Jun 2005 08:20:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhnud-0002LD-GN for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 08:19:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04618 for ; Mon, 13 Jun 2005 08:19:30 -0400 (EDT) Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DhoGt-0001yf-T3 for hipsec@ietf.org; Mon, 13 Jun 2005 08:42:33 -0400 Received: (qmail 89967 invoked from network); 13 Jun 2005 12:19:19 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 13 Jun 2005 12:19:19 -0000 Received: (qmail 37032 invoked from network); 13 Jun 2005 08:19:19 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.78) by mail1.oct.nac.net with SMTP; 13 Jun 2005 08:19:19 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j5D97Wk08030; Mon, 13 Jun 2005 05:07:32 -0400 Date: Mon, 13 Jun 2005 05:07:32 -0400 (EDT) From: George Gross To: Petri Jokela Subject: Re: [Hipsec] Re: ESP draft snapshot 31.05.05 In-Reply-To: <42AD603A.2040605@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.7 (/) 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, inline.... On Mon, 13 Jun 2005, Petri Jokela wrote: > > So is there a benefit to using these 64-bit sequence numbers? Why do we > > need them? > > Nobody has reacted on this issue. There seems not to be need for the > 64-bit sequence numbers. So, if there is no reason to keep it there I > will remove it from the next version. Comments? see the draft rfc2401-bis section 4.4.2.1, now in RFC editor queue. If you want to keep alignment with IPsec definition of a SAD, 64-bit sequence numbers are a MUST. The intent of 64-bit sequence numbers is to handle high volume (>Gbps) packet flows that would overwise overflow the 32 bit sequence counter too frequently. hth, George > > /petri > > > _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 13 15:03:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuDC-0006Ii-03; Mon, 13 Jun 2005 15:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhuD9-0006II-AD for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 15:03:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10376 for ; Mon, 13 Jun 2005 15:03:01 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+Jyc/2KE/11Z2MBjFnKplPWF7oUk9prnY=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhuZS-0003iZ-0g for hipsec@ietf.org; Mon, 13 Jun 2005 15:26:08 -0400 Received: from hsi-kbw-085-216-018-203.hsi.kabelbw.de ([85.216.18.203] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DhuCX-0004se-GG; Mon, 13 Jun 2005 21:02:30 +0200 Message-ID: <42ADD83B.3000505@tm.uka.de> Date: Mon, 13 Jun 2005 21:02:19 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Teemu Koponen Subject: Re: [Hipsec] Review of draft-ietf-hip-mm-01 References: <42AC5C02.1000702@tm.uka.de> <8ce426317c0fae13af48790697ed040a@iki.fi> In-Reply-To: <8ce426317c0fae13af48790697ed040a@iki.fi> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -102.5 (---------------------------------------------------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: hipsec@ietf.org, Jari Arkko 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: , Content-Type: multipart/mixed; boundary="===============2038252798==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2038252798== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B085AB892548B2391D9B8A1" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B085AB892548B2391D9B8A1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Teemu, yes, what you say definitely makes sense. If we make address verification mandatory in all cases (*), which I think we should, then hosts would not wait in vain for the challenge. Would this solve your concern? (*) The one and only exception would be a new primary locator advertised as part of the R1 message. We don't need to verify reachability of that locator because, if the locator was false, then... ==> the I2 message would not reach the responder (because it's sent to the new locator) ==> the responder could not create the DH secret ==> the responder could not compute the HMAC for the R2 ==> the initiator would detect the fraud. Since address verification is unnessary in this case, it shouldn't be performed either because it could delay (or even confuse) the base exchange. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Teemu Koponen wrote: > On Jun 12, 2005, at 9:00, Christian Vogt wrote: > > Christian, > >> reviewing draft-ietf-hip-mm-01, a couple of things came to my mind: >> >> (1) Address verification. The draft mentiones in several places that a >> correspondent host may omit address verification for a mobile or >> multi-homed peer in case that peer is sufficiently trusted to provide >> the right addresses. I don't think trust eliminates the need for an >> address check, however. > > > Actually, I have been thinking the same issue of whether to do the > address verification or not, but from a slightly different viewpoint. > IMHO, there might be certain use cases where you would like to know for > sure whether the remote peer is about to send an address verification or > not. > > One example, perhaps a bit artificial though, that comes to my mind is > related to power management: a mobile device sends an UPDATE and begins > to wait for an UPDATE with ACK. Now, if the device would know whether > the peer is *not* about to respond with an address verification check, > it could shutdown the transmitter components of its radio right after > sending the UPDATE with new locator. > > Teemu --------------enig8B085AB892548B2391D9B8A1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCrdg+wstEk8gl2rURAinhAJ4/XlyLJzDOxwTk5TghIAQs/QAj6QCgkaCb CJ78lFfjxvQepbpzt4/O3+M= =zD9v -----END PGP SIGNATURE----- --------------enig8B085AB892548B2391D9B8A1-- --===============2038252798== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============2038252798==-- From hipsec-bounces@lists.ietf.org Mon Jun 13 15:55:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhv1Q-0003mV-Jn; Mon, 13 Jun 2005 15:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dhv1P-0003mK-4J for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 15:54:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21123 for ; Mon, 13 Jun 2005 15:54:57 -0400 (EDT) Received: from ns.niksula.cs.hut.fi ([130.233.40.5] helo=twilight.cs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhvNi-0007yx-HV for hipsec@ietf.org; Mon, 13 Jun 2005 16:18:04 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id D87482EE5; Mon, 13 Jun 2005 22:54:46 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 9DAC82EBF; Mon, 13 Jun 2005 22:54:44 +0300 (EEST) In-Reply-To: <42ADD83B.3000505@tm.uka.de> References: <42AC5C02.1000702@tm.uka.de> <8ce426317c0fae13af48790697ed040a@iki.fi> <42ADD83B.3000505@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3c641c22c9aa7cb1eb7b2b6361bd9010@iki.fi> Content-Transfer-Encoding: 7bit From: Teemu Koponen Subject: Re: [Hipsec] Review of draft-ietf-hip-mm-01 Date: Mon, 13 Jun 2005 12:54:46 -0700 To: Christian Vogt X-Mailer: Apple Mail (2.622) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: hipsec@ietf.org, Jari Arkko 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Jun 13, 2005, at 12:02, Christian Vogt wrote: Christian, > If we make address verification mandatory in all cases (*), which I > think we should, then hosts would not wait in vain for the challenge. > Would this solve your concern? Yes it certainly would, as my main concern was exactly the ambiguity. Teemu -- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 13 16:12:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhvI6-0007iR-7h; Mon, 13 Jun 2005 16:12:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DhvI2-0007hB-Lm for hipsec@megatron.ietf.org; Mon, 13 Jun 2005 16:12:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29983 for ; Mon, 13 Jun 2005 16:12:07 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DhveK-0002o4-B4 for hipsec@ietf.org; Mon, 13 Jun 2005 16:35:15 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA21030; Mon, 13 Jun 2005 13:11:31 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5DKBU528639; Mon, 13 Jun 2005 15:11:30 -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.211); Mon, 13 Jun 2005 13:10:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jun 2005 13:12:43 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0959C7@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: Review of draft-ietf-hip-mm-01 Thread-Index: AcVvZ/PG9Q2s6kITSWerQJglcsx6KwAw8txw From: "Henderson, Thomas R" To: "Christian Vogt" , "Pekka Nikander" , "Gregory Perkins" , "Jari Arkko" , X-OriginalArrivalTime: 13 Jun 2005 20:10:57.0954 (UTC) FILETIME=[02FBB020:01C57054] X-Spam-Score: 0.5 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Hipsec] RE: Review of draft-ietf-hip-mm-01 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Christian Vogt [mailto:chvogt@tm.uka.de]=20 > Sent: Sunday, June 12, 2005 9:00 AM > To: Henderson, Thomas R; Pekka Nikander; Gregory Perkins;=20 > Jari Arkko; hipsec@ietf.org > Cc: Jan.Melen@nomadiclab.com; Ahrenholz, Jeffrey M > Subject: Review of draft-ietf-hip-mm-01 >=20 > Hi everybody, >=20 > reviewing draft-ietf-hip-mm-01, a couple of things came to my mind: >=20 > (1) Address verification. The draft mentiones in several=20 > places that a > correspondent host may omit address verification for a mobile or > multi-homed peer in case that peer is sufficiently trusted to provide > the right addresses. I don't think trust eliminates the need for an > address check, however. James Kempf brought this up on the Mobopts > mailing list [1]. If we omit the address check for "trusted" nodes, > those nodes could still be compromised by malware and start=20 > to redirect > packets. In other words, a node redirecting packets to the wrong > address may not do this by intention; the perpetrator could be someone > else who brought that node under his control through a viral software. >=20 > Admittedly, the use of IPsec ESP would probably require a very > sophisticated virus/worm... >=20 > Anyway, I'd propose to make address verification a MUST in all cases. > Note that the verification won't delay communications since we are now > using Credit-Based Authorization (CBA). Disclaimer: I was one who originally pushed for making address check a MAY instead of a MUST, to save transmissions and latency in certain (wireless) environments. However, I think your security rationale may trump this (and as you mention, CBA solves the latency issue). There is an additional consideration that may bias towards always sending the address check-- if one wants HIP-aware middleboxes to be able to learn SPI/identity bindings, there needs to be a packet in each direction. So I would agree with your proposal now-- make address verification prior to address use a MUST for hosts that have received an UPDATE (but, as presently specified, do not require the peer host to enforce this MUST condition). > (2) Section 7.1 (Sending LOCATORs) and 7.2 (Handling received > LOCATORs): There is mentioning of an "SPI field" inside the LOCATOR > parameter. Is this a relict from draft-ietf-hip-mm-00? There used to > be a SPI field in the REA parameter, but there is none in the LOCATOR > parameter. As far as I understand, the SPI is now part of the Locator > field. >=20 Yes, the text in this section has fallen inconsistent with the LOCATOR format. > (3) Section 7.1 (Sending LOCATORs). Paragraph 8 says: >=20 > "If there are multiple LOCATOR parameters leading to a packet size > that exceeds the MTU, the host SHOULD send multiple packets, each > smaller than the MTU. In the case of R1 and I2, the additional > packets should be UPDATE packets that are sent after the base > exchange has been completed." >=20 > My concern is this: Any locator not in the first packet will > (temporarily) be set to DEPRECATED status according to paragraph 5 of > this section. Even when it shows up in a subsequent packet, it will > first go to UNVERIFIED status, and address verification will=20 > have to be > accomplished even if the locator was in ACTIVE status before the first > packet arrived. So it seems that splitting the locator set over > multiple packets would be sub-optimal. It may be worse than this if the subsequent packets deprecate the locators of the all previous packets. =20 >=20 > Would it be possible to change the semantics of the LOCATOR parameter > such that existing locators are not removed when they do not show up? > The readdressing host could explicitly remove a locator by advertising > it with a zero Locator Lifetime, e.g. >=20 I do not recall the entire history of this issue, but if I recall correctly, both variants (explicit and implicit removal) have been supported at different times during the history of this draft. Presently, it is implicit removal (removed if locator is not present in the UPDATE). =20 One argument in favor of the status quo might be that, if the common case is single-interface mobility, the implicit removal avoids having to explicitly deprecate the old locator. =20 I think that the "large packet" issue might be better handled via IP fragmentation-- although it seems an unlikely scenario for IPv6 in particular. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 15 01:56:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQsn-00018w-K7; Wed, 15 Jun 2005 01:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiQsl-00018i-Dg for hipsec@megatron.ietf.org; Wed, 15 Jun 2005 01:56:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09468 for ; Wed, 15 Jun 2005 01:56:10 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiRFO-0007Xv-C0 for hipsec@ietf.org; Wed, 15 Jun 2005 02:19:34 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BA839212C3C; Wed, 15 Jun 2005 08:55:48 +0300 (EEST) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D0959C7@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D0959C7@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <64bc4189ceb4d45ccd1a34e60efa88c3@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 15 Jun 2005 08:55:50 +0300 To: Thomas R Henderson , Christian Vogt X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: Jari Arkko , "" Subject: [Hipsec] Re: Review of draft-ietf-hip-mm-01 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >> (3) Section 7.1 (Sending LOCATORs). Paragraph 8 says: >> >> "If there are multiple LOCATOR parameters leading to a packet size >> that exceeds the MTU, the host SHOULD send multiple packets, each >> smaller than the MTU. In the case of R1 and I2, the additional >> packets should be UPDATE packets that are sent after the base >> exchange has been completed." >> >> My concern is this: Any locator not in the first packet will >> (temporarily) be set to DEPRECATED status according to paragraph 5 of >> this section. Even when it shows up in a subsequent packet, it will >> first go to UNVERIFIED status, and address verification will >> have to be >> accomplished even if the locator was in ACTIVE status before the first >> packet arrived. So it seems that splitting the locator set over >> multiple packets would be sub-optimal. > > It may be worse than this if the subsequent packets deprecate the > locators of the all previous packets. I don't think anyone has thought about that before; at least the problem didn't occur to me nor had I heard about it before. IIRC, the original reason for the behaviour was to make the method to work also if UPDATEs are lost. That is, the idea was that each address update would include complete information, making them idempotent. However, as UPDATEs are now acked there is less reason for this, though still some. >> Would it be possible to change the semantics of the LOCATOR parameter >> such that existing locators are not removed when they do not show up? >> The readdressing host could explicitly remove a locator by advertising >> it with a zero Locator Lifetime, e.g. > > I do not recall the entire history of this issue, but if I recall > correctly, both variants (explicit and implicit removal) have been > supported at different times during the history of this draft. > Presently, it is implicit removal (removed if locator is not present in > the UPDATE). IIRC, we originally had the interface identifiers there, grouping IP addresses by logical interfaces, where the logical interfaces were basically whatever groups the sender decided to have. These were later removed. > One argument in favor of the status quo might be that, if the common > case is single-interface mobility, the implicit removal avoids having > to > explicitly deprecate the old locator. Does this imply that in the case of multi-interface mobility we perhaps should reconsider interface IDs? > I think that the "large packet" issue might be better handled via IP > fragmentation-- although it seems an unlikely scenario for IPv6 in > particular. Agreed. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 16 08:14:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitGY-0006MY-3r; Thu, 16 Jun 2005 08:14:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DitGW-0006LH-Qx for hipsec@megatron.ietf.org; Thu, 16 Jun 2005 08:14:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12216 for ; Thu, 16 Jun 2005 08:14:31 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DitdO-0002Ol-DG for hipsec@ietf.org; Thu, 16 Jun 2005 08:38:15 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 10601212C3C; Thu, 16 Jun 2005 15:14:13 +0300 (EEST) Message-ID: <42B16D14.9080705@nomadiclab.com> Date: Thu, 16 Jun 2005 15:14:12 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Gross Subject: Re: [Hipsec] Re: ESP draft snapshot 31.05.05 References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org George Gross wrote: > Hi, > > inline.... > > On Mon, 13 Jun 2005, Petri Jokela wrote: > > > >>>So is there a benefit to using these 64-bit sequence numbers? Why do we >>>need them? >> >>Nobody has reacted on this issue. There seems not to be need for the >>64-bit sequence numbers. So, if there is no reason to keep it there I >>will remove it from the next version. Comments? > > > see the draft rfc2401-bis section 4.4.2.1, now in RFC editor queue. If you > want to keep alignment with IPsec definition of a SAD, 64-bit sequence > numbers are a MUST. The intent of 64-bit sequence numbers is to handle > high volume (>Gbps) packet flows that would overwise overflow the 32 bit > sequence counter too frequently. Valid point. I'll add a reference to this draft. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 16 15:45:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0Ib-0005et-Bs; Thu, 16 Jun 2005 15:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0IY-0005eo-TI for hipsec@megatron.ietf.org; Thu, 16 Jun 2005 15:45:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00287 for ; Thu, 16 Jun 2005 15:45:05 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj0fV-00080M-CR for hipsec@ietf.org; Thu, 16 Jun 2005 16:08:54 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id 90C662DB4; Thu, 16 Jun 2005 22:44:55 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id 61D852D7C for ; Thu, 16 Jun 2005 22:44:53 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <75335f2e8cc57966fc019caa2a856f27@iki.fi> Content-Type: text/plain; charset=US-ASCII; format=flowed To: hipsec@ietf.org From: Teemu Koponen Date: Thu, 16 Jun 2005 12:44:56 -0700 X-Mailer: Apple Mail (2.622) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Packet reordering, certificates and base exchange 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org All, The latest base-03-pre defines a control bit for both I2 and R2 to inform a peer to wait for shortly arriving certificate packets. However, I did not find any discussion how the peer should behave if a certificate packet arrives before I2/R2. Packet reordering is not anything rare in Internet, so it should be considered. From initiator's point of view, I think it just means that the responder's certificate packets should be cached for a short period of time. Someone else probably has a better understanding of the required time window, so I do not even try suggest any practical time. :-) However, introducing caching in responder is not an option due to the fact that it should remain stateless until it receives I2. As the initiator cannot enforce the I2 to arrive before the certificates, without a significant delay between I2 and certificate packets, I wonder if it might make sense to alter the I2 to optionally contain a number of certificate parameters. Then, initiator could actually send multiple I2s, each containing a different certificate, or a single I2 that possibly gets fragmented. If R2 gets the same enhancement, the certificate packet eventually becomes useless, I think. Comments? Teemu -- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 17 03:23:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjBC2-0007Hh-5B; Fri, 17 Jun 2005 03:23:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjBBz-0007Hc-QD for hipsec@megatron.ietf.org; Fri, 17 Jun 2005 03:23:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20105 for ; Fri, 17 Jun 2005 03:23:05 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjBZ2-0003ZQ-23 for hipsec@ietf.org; Fri, 17 Jun 2005 03:46:57 -0400 Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id A457B212C3C; Fri, 17 Jun 2005 10:22:51 +0300 (EEST) Received: from [IPv6:::1] (n2.nomadiclab.com [193.234.219.2]) by outside.nomadiclab.com (Postfix) with ESMTP id 977CEBDC0C; Fri, 17 Jun 2005 10:22:51 +0300 (EEST) Message-ID: <42B27A49.7010007@nomadiclab.com> Date: Fri, 17 Jun 2005 10:22:49 +0300 From: Jukka Ylitalo User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Teemu Koponen Subject: Re: [Hipsec] Packet reordering, certificates and base exchange References: <75335f2e8cc57966fc019caa2a856f27@iki.fi> In-Reply-To: <75335f2e8cc57966fc019caa2a856f27@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, Teemu Koponen wrote: > All, > > The latest base-03-pre defines a control bit for both I2 and R2 to > inform a peer to wait for shortly arriving certificate packets. > However, I did not find any discussion how the peer should behave if a > certificate packet arrives before I2/R2. Packet reordering is not > anything rare in Internet, so it should be considered. > > From initiator's point of view, I think it just means that the > responder's certificate packets should be cached for a short period of > time. Someone else probably has a better understanding of the required > time window, so I do not even try suggest any practical time. :-) > > However, introducing caching in responder is not an option due to the > fact that it should remain stateless until it receives I2. As the > initiator cannot enforce the I2 to arrive before the certificates, > without a significant delay between I2 and certificate packets, I > wonder if it might make sense to alter the I2 to optionally contain a > number of certificate parameters. Then, initiator could actually send > multiple I2s, each containing a different certificate, or a single I2 > that possibly gets fragmented. If R2 gets the same enhancement, the > certificate packet eventually becomes useless, I think. > > Comments? > How about adding the solved puzzle to each certificate packet (also carried in the I2 packet) going to the responder? The responder may establish a soft-state for the certificate packets after validating the puzzle, and release the state, if I2 does not arrive in the assumed time frame. -- Jukka > Teemu > > -- > > > _______________________________________________ > 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 Fri Jun 17 04:09:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjBue-0007dk-V8; Fri, 17 Jun 2005 04:09:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjBuc-0007bN-MD for hipsec@megatron.ietf.org; Fri, 17 Jun 2005 04:09:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22812 for ; Fri, 17 Jun 2005 04:09:12 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjCHe-0006xk-BV for hipsec@ietf.org; Fri, 17 Jun 2005 04:33:04 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3114815271 for ; Fri, 17 Jun 2005 10:24:49 +0200 (CEST) Received: from [10.1.1.112] ([10.1.1.112]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Jun 2005 10:10:03 +0200 Mime-Version: 1.0 (Apple Message framework v730) To: hipsec@ietf.org Message-Id: <1A8E6681-5E59-4812-9758-F86E76556765@netlab.nec.de> References: From: Lars Eggert Date: Fri, 17 Jun 2005 10:08:54 +0200 X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 17 Jun 2005 08:10:03.0367 (UTC) FILETIME=[F6E47F70:01C57313] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: Subject: [Hipsec] Fwd: I-D ACTION:draft-ietf-hip-rvs-02.txt 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: , Content-Type: multipart/mixed; boundary="===============1070547434==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============1070547434== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--1045385487; protocol="application/pkcs7-signature" --Apple-Mail-8--1045385487 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit For some reasons, this announcement hasn't made it to the list yet. We'd appreciate comments on this revision! Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: June 16, 2005 21:50:02 GMT+02:00 > To: i-d-announce@ietf.org > Cc: hipsec@ietf.org > Subject: I-D ACTION:draft-ietf-hip-rvs-02.txt > Reply-To: internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Host Identity Protocol Working > Group of the IETF. > > Title : Host Identity Protocol (HIP) Rendezvous Extension > Author(s) : J. Laganier, L. Eggert > Filename : draft-ietf-hip-rvs-02.txt > Pages : 16 > Date : 2005-6-16 > > This document discusses a rendezvous extension for the Host Identity > Protocol (HIP). The rendezvous extension extends HIP and the HIP > registration extension for initiating communication between HIP > nodes > via HIP rendezvous servers. Rendezvous servers improve > reachability > and operation when HIP nodes are multi-homed or mobile. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hip-rvs-02.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-hip-rvs-02.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-hip-rvs-02.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-6-16151000.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-8--1045385487 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILRDCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggPhMIIDSqADAgECAgMO8MUwDQYJKoZI hvcNAQEEBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1 MDYxNzA3MzQzM1oXDTA2MDYxNzA3MzQzM1owgfMxDzANBgNVBAQTBkVnZ2VydDENMAsGA1UEKhME TGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxIzAhBgkqhkiG9w0BCQEWFGxhcnMuZWdnZXJ0QGll ZWUub3JnMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBhY20ub3JnMSgwJgYJKoZIhvcNAQkB FhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMSIwIAYJKoZIhvcNAQkBFhNsYXJzLmVnZ2VydEBn bXgubmV0MSQwIgYJKoZIhvcNAQkBFhVlZ2dlcnRAYWx1bW5pLnVzYy5lZHUwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCl+oudGX8XAtHhDH8R09G04C+RbQFvmG1Ctau5/8a3cuIuFcWH 8qPmxWpsIcvZR0MQ6r8Q7sPQXV5QFQKw1KijyHXF3TK2qZAl61b7keOYVFThYY6adgZyFDUTrx5E uLkpdZyzZ6ODk72OZFbOSFXBcgw5P5keVwDoeoi4Wb+XkZq6dTlqQD18j0UJAGdHTU6FXbzv5uzn ClKuUX3MOkYBa05zVCT+0uJc5hPtEIpAk0y9GRLoDjvliDKnlOvZEKje0eT/AR0CmwO8ghcW6wlQ JUWpakfoKV5CWoIfimEn0R2pD+ggmpbRwQ4BYfpFMnMFej7mFmOnbQZMHr7OtgmhAgMBAAGjgY4w gYswewYDVR0RBHQwcoEUbGFycy5lZ2dlcnRAaWVlZS5vcmeBE2xhcnMuZWdnZXJ0QGFjbS5vcmeB GWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGWBE2xhcnMuZWdnZXJ0QGdteC5uZXSBFWVnZ2VydEBh bHVtbmkudXNjLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAFAOwi4S0MKEr6LQ olKerPDcwpkbtgOrCopWBtATDr+ifk57LFpGiYTrWbfsSogIQbM2EUO91bpZvSaaMMim/0ChtAFb Md4l/L22fol1SkbwGvG1Q/Y6e7yVaswykhK/BLgzT6IEyREIPd/rX44m1SOXX8xM5tmxQeANXdbp w5YAMIIEGDCCA4GgAwIBAgIBADANBgkqhkiG9w0BAQUFADCBvzELMAkGA1UEBhMCREUxHDAaBgNV BAgUE0JhZGVuLVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5F QyBFdXJvcGUgTHRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29i ZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRl MB4XDTA0MDYxODExNTMwOFoXDTA5MDYxNzExNTMwOFowgb8xCzAJBgNVBAYTAkRFMRwwGgYDVQQI FBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQKEw5ORUMg RXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMTEmtvYmUu bmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5lYy5kZTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtDkMLBPOka7dGbNBjgrGJpBqT8HAhb1aTooyD79X RqJa+WvPu4V0gIEZVMqHJavcX4bFE8JVNapL1UQ9/0Dn0Mj1MUJLcW2tpLH7DwClB6LyJ1snQuq7 y1PPY7WBhHZ0QsgPnBAf13EgA23ds/f1yuANnMZjEImKVyKYWEAMSAcCAwEAAaOCASAwggEcMB0G A1UdDgQWBBToey/Xqhh5wIWyXTuD2C2M8QmjTTCB7AYDVR0jBIHkMIHhgBToey/Xqhh5wIWyXTuD 2C2M8QmjTaGBxaSBwjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJl cmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQL ExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJ KoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlggEAMAwGA1UdEwQFMAMBAf8wDQYJ KoZIhvcNAQEFBQADgYEAl+iKXdwBfdxQ8wWsN2Vb0M8wr/5BjwQc86yd5+bvuHkKaZjon4blh2X2 /IfEvvo6nKDxxlY45T+T2hW/sC9DUaYgWpUXJYpA98SGP4RaMSdQBwjtAM3xcRH5TtdG+PrJjKwW CbZOXfRAIa+YRIKBgjO0IowbZwsGQSiyPaRYFtcxggOlMIIDoQIBATBpMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDvDFMAkGBSsOAwIaBQCgggIRMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDYxNzA4MDg1NVowIwYJKoZIhvcN AQkEMRYEFDPBHICdfUkq9y9nvGR2z/rPQSrdMIHWBgkrBgEEAYI3EAQxgcgwgcUwgb8xCzAJBgNV BAYTAkRFMRwwGgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJn MRcwFQYDVQQKEw5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMx GzAZBgNVBAMTEmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRA bmV0bGFiLm5lYy5kZQIBADCB2AYLKoZIhvcNAQkQAgsxgciggcUwgb8xCzAJBgNVBAYTAkRFMRww GgYDVQQIFBNCYWRlbi1Xw3VlcnR0ZW1iZXJnMRMwEQYDVQQHEwpIZWlkZWxiZXJnMRcwFQYDVQQK Ew5ORUMgRXVyb3BlIEx0ZDEdMBsGA1UECxMUTmV0d29yayBMYWJvcmF0b3JpZXMxGzAZBgNVBAMT EmtvYmUubmV0bGFiLm5lYy5kZTEoMCYGCSqGSIb3DQEJARYZbGFycy5lZ2dlcnRAbmV0bGFiLm5l Yy5kZQIBADANBgkqhkiG9w0BAQEFAASCAQCgpWVJPSijSv9WrO0VEN6Vcht/slq0sSCp/WxO16ce gEEXYK5nnxDFg22qhTMza//vfig24nk7vLwCeechY9I2y6dOMLrsZex08SkheP2lFssV/BOcZO0I 8amqVBi7JJJOO2xJbUAD5psOUHaXG1uh+Dak3olsQ9Z76qmBsV15t84a9g+pIkKeKacU+umHX8dc 34ZT2pCmf1SbvUis/1Fp0CH3Iaf+uQX1RAK725cX9r+mvwNOvaPgUFY97hAqDMXlkqKyB8r2DQJ5 jaz6llLwlVWYKLPsyJkU4a+2rRqVCUpGTCvLyZPB+ijmKGcV69XhyTQvHMnOYCYOlAz4idVYAAAA AAAA --Apple-Mail-8--1045385487-- --===============1070547434== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============1070547434==-- From hipsec-bounces@lists.ietf.org Fri Jun 17 07:09:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjEiq-0003nG-8C; Fri, 17 Jun 2005 07:09:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjEio-0003n6-GZ for hipsec@megatron.ietf.org; Fri, 17 Jun 2005 07:09:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05397 for ; Fri, 17 Jun 2005 07:09:10 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjF5s-0002WK-Gs for hipsec@ietf.org; Fri, 17 Jun 2005 07:33:05 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 2221F212C3C for ; Fri, 17 Jun 2005 14:08:34 +0300 (EEST) Message-ID: <42B2AF31.6040503@nomadiclab.com> Date: Fri, 17 Jun 2005 14:08:33 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Base draft - 17.6 preliminary version 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org The current version of the base draft is at http://hip4inter.net/drafts.php dated 170605. Please give all the input that you have for it. I'm planning to submit it to IETF next week. /Petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 18 01:29:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjVtc-0008Cg-Mm; Sat, 18 Jun 2005 01:29:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjVta-0008CY-Pp for hipsec@megatron.ietf.org; Sat, 18 Jun 2005 01:29:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21863 for ; Sat, 18 Jun 2005 01:29:29 -0400 (EDT) Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjWGm-0000ES-V2 for hipsec@ietf.org; Sat, 18 Jun 2005 01:53:32 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id EB21AD3D for ; Sat, 18 Jun 2005 07:29:04 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Jun 2005 07:29:03 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Sat, 18 Jun 2005 07:29:03 +0200 Received: from [131.160.126.70] (rvi2-126-70.lmf.ericsson.se [131.160.126.70]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 64BDF2546 for ; Sat, 18 Jun 2005 08:29:03 +0300 (EEST) Message-ID: <42B3B11E.1060202@ericsson.com> Date: Sat, 18 Jun 2005 08:29:02 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jun 2005 05:29:03.0785 (UTC) FILETIME=[A3BF0190:01C573C6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] 63rd IETF in Paris - Important Meeting Dates 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org FYI: http://www.ietf.org/meetings/cutoff_dates_63.html Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 20 02:20:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkFeV-0001j8-DE; Mon, 20 Jun 2005 02:20:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkFeT-0001iy-43 for hipsec@megatron.ietf.org; Mon, 20 Jun 2005 02:20:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26186 for ; Mon, 20 Jun 2005 02:20:56 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkG25-0008Eq-5f for hipsec@ietf.org; Mon, 20 Jun 2005 02:45:24 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id E23B02DA7; Mon, 20 Jun 2005 09:20:35 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id AB4182C46; Mon, 20 Jun 2005 09:20:34 +0300 (EEST) In-Reply-To: <42B27A49.7010007@nomadiclab.com> References: <75335f2e8cc57966fc019caa2a856f27@iki.fi> <42B27A49.7010007@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05a5073ebb3c3828ac5b1bf9935ab123@iki.fi> Content-Transfer-Encoding: 7bit From: Teemu Koponen Subject: Re: [Hipsec] Packet reordering, certificates and base exchange Date: Sun, 19 Jun 2005 23:20:38 -0700 To: Jukka Ylitalo X-Mailer: Apple Mail (2.622) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Jun 17, 2005, at 0:22, Jukka Ylitalo wrote: Jukka, >> The latest base-03-pre defines a control bit for both I2 and R2 to >> inform a peer to wait for shortly arriving certificate packets. >> However, I did not find any discussion how the peer should behave if >> a certificate packet arrives before I2/R2. Packet reordering is not >> anything rare in Internet, so it should be considered. >> >> From initiator's point of view, I think it just means that the >> responder's certificate packets should be cached for a short period >> of time. Someone else probably has a better understanding of the >> required time window, so I do not even try suggest any practical >> time. :-) >> >> However, introducing caching in responder is not an option due to the >> fact that it should remain stateless until it receives I2. As the >> initiator cannot enforce the I2 to arrive before the certificates, >> without a significant delay between I2 and certificate packets, I >> wonder if it might make sense to alter the I2 to optionally contain a >> number of certificate parameters. Then, initiator could actually send >> multiple I2s, each containing a different certificate, or a single I2 >> that possibly gets fragmented. If R2 gets the same enhancement, the >> certificate packet eventually becomes useless, I think. >> > How about adding the solved puzzle to each certificate packet (also > carried in the I2 packet) > going to the responder? The responder may establish a soft-state for > the certificate packets > after validating the puzzle, and release the state, if I2 does not > arrive in the assumed time frame. Adding the solved puzzle to CER packets seems to me to be the smallest possible change to overcome the problem. However, at the moment I'm unable to see if a) adding the puzzle has any additional side-effects, b) is it enough alone. Teemu -- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 20 11:13:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNxp-00053w-1V; Mon, 20 Jun 2005 11:13:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkNxn-00053P-39 for hipsec@megatron.ietf.org; Mon, 20 Jun 2005 11:13:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08891 for ; Mon, 20 Jun 2005 11:13:25 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkOLV-0004Bk-Sm for hipsec@ietf.org; Mon, 20 Jun 2005 11:37:59 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9F7DBD96D for ; Mon, 20 Jun 2005 17:29:56 +0200 (CEST) Received: from [10.1.1.112] ([10.1.1.112]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Jun 2005 17:14:32 +0200 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: References: Message-Id: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> From: Lars Eggert Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Mon, 20 Jun 2005 17:13:10 +0200 X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 20 Jun 2005 15:14:32.0630 (UTC) FILETIME=[C2FEDD60:01C575AA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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: , Content-Type: multipart/mixed; boundary="===============0035830384==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============0035830384== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9--760728540; protocol="application/pkcs7-signature" --Apple-Mail-9--760728540 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit Hi, On Feb 15, 2005, at 18:51 , Teemu Koponen wrote: > > A new draft that is a spin-off from the rendezvous draft: > > Title : Host Identity Protocol (HIP) Registration Extension > Author(s) : T. Koponen, et al. > Filename : draft-koponen-hip-registration-00.txt > Pages : 13 > Date : 2005-2-14 we haven't received much feedback on this ID and would much appreciate if some WG people could take a look at it. (FWIW, it's only a few pages long! :-) Thanks, Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-9--760728540 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw7yUjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjE4MDczODIzWhcNMDYwNjE4MDczODIzWjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAwC64+CjRjFft0NL8szfPoms1+W/AsJ96uZ0SxhZXWynorOKPLaoCYWuE3a9SsUY5Pfj5 KQjMh6Dcv1F3LwQ/cdkiFzGBYkHU8IxKMjhZtCanKHTwyKC4Zhuy4pSArJUhsl/3z7FNKUaK7HXn JEfAvheuXQ7ve+vF+IF4uorvTmjQrvQJWjpJBIqgmya2GSnv7eZJIJmXE1sfCrVHes2eiLsxWNz+ ZB/N5h8v6NxxcrWcJa0C/IvMc2nH8dYwIk5++LV/0Ua2IDxWV/dodXxMxWoihkNUiMIZIDwgvITi 7eyStEddqzUFiTQtsasSfC2KQDrFu2J3IrdE2kkpOJ/unwIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAFxcPmBBZLSD6vhqZW 852TSPZfQZFNWg+y5lT/+Jbb5qlYjd6pTEYQIZ4I5JAcN1T8a5JkAU3ZKB0eP5mhFrptyHtpQ1hy KSq8BBF/RVFYt1Irz88+SgQ6L+1LT4lcgvxy4PGIQCLtqbvr0w29w/i7MGr+mUpjI+T1F+nKAI4m GTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMO8lIwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUwNjIwMTUxMzEyWjAjBgkqhkiG9w0BCQQxFgQU1MsjWlWhDT9SYk8RlGpb l451eJowgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBABIkMRWllVc39jKSqzqDLq2y4qNSnLHYfJgdI+gF+5n/+Z3Ejbt9JZuehnJJipNzluuniaAp S3OKBFChANMMWkZqPDxIYtEO77tp2DQDsQ9wkq6MZk8XDTLFC+e7K51aSveVmDKbHPqdNpB4uhsV vdEgEPQ/k3zVstH+MZkWXDw7iTtENuJczpY7ok9PswRKbiIIcShr7k4BBKddDc79g2IAftN/RHio UbKzoGZIHvAzcSBtNrxf+eWdB0GVxI4FBcTTASKNuIyV9iB89z/+VFoaoozDD/kGDqEfGhfJV6GZ OUKL0zuhV9RfW10iZP/71sjUC7aKWnX9Rl9F/2nxKR4AAAAAAAA= --Apple-Mail-9--760728540-- --===============0035830384== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0035830384==-- From hipsec-bounces@lists.ietf.org Mon Jun 20 13:15:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPsK-0004jy-KL; Mon, 20 Jun 2005 13:15:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkPsJ-0004jr-A6 for hipsec@megatron.ietf.org; Mon, 20 Jun 2005 13:15:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19873 for ; Mon, 20 Jun 2005 13:15:52 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkQG2-0007QI-4d for hipsec@ietf.org; Mon, 20 Jun 2005 13:40:28 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA29410; Mon, 20 Jun 2005 10:15:17 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5KHFHn29893; Mon, 20 Jun 2005 10:15:17 -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.211); Mon, 20 Jun 2005 10:14:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] Packet reordering, certificates and base exchange Date: Mon, 20 Jun 2005 10:14:13 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] Packet reordering, certificates and base exchange Thread-Index: AcVyrEW6ZuEMHzwVRiyUWL+4cJZKhQDDmjow From: "Henderson, Thomas R" To: "Teemu Koponen" , X-OriginalArrivalTime: 20 Jun 2005 17:14:14.0657 (UTC) FILETIME=[7BD13710:01C575BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org =20 > -----Original Message----- > From: Teemu Koponen [mailto:tkoponen@iki.fi]=20 > Sent: Thursday, June 16, 2005 12:45 PM > To: hipsec@ietf.org > Subject: [Hipsec] Packet reordering, certificates and base exchange >=20 > All, >=20 > The latest base-03-pre defines a control bit for both I2 and R2 to=20 > inform a peer to wait for shortly arriving certificate packets.=20 > However, I did not find any discussion how the peer should=20 > behave if a=20 > certificate packet arrives before I2/R2. Packet reordering is not=20 > anything rare in Internet, so it should be considered. >=20 > From initiator's point of view, I think it just means that the=20 > responder's certificate packets should be cached for a short=20 > period of=20 > time. Someone else probably has a better understanding of the=20 > required=20 > time window, so I do not even try suggest any practical time. :-) >=20 > However, introducing caching in responder is not an option due to the=20 > fact that it should remain stateless until it receives I2. As the=20 > initiator cannot enforce the I2 to arrive before the certificates,=20 > without a significant delay between I2 and certificate packets, I=20 > wonder if it might make sense to alter the I2 to optionally contain a=20 > number of certificate parameters. Then, initiator could actually send=20 > multiple I2s, each containing a different certificate, or a single I2=20 > that possibly gets fragmented. If R2 gets the same enhancement, the=20 > certificate packet eventually becomes useless, I think. >=20 > Comments? >=20 I think it makes sense to add capability to include certificates in the base exchange packets. I'm not that sure it makes the utility of stand-alone CER packets go away, though. However, I would suggest that such a topic (using HIP with certificate infrastructure) could be separate work item for future, and not try to fix the base spec now with little experience on the approach. For that matter, I would probably be more in favor of taking out CER from the existing base spec rather than trying to improve its definition at this time. Tom _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 21 16:07:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp1X-0001LL-4C; Tue, 21 Jun 2005 16:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp1W-0001Kv-3A for hipsec@megatron.ietf.org; Tue, 21 Jun 2005 16:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28538 for ; Tue, 21 Jun 2005 16:07:03 -0400 (EDT) Received: from twilight.cs.hut.fi ([130.233.40.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkpPT-0000G2-Ls for hipsec@ietf.org; Tue, 21 Jun 2005 16:31:53 -0400 Received: by twilight.cs.hut.fi (Postfix, from userid 60001) id CF7F92D4F; Tue, 21 Jun 2005 23:06:53 +0300 (EEST) Received: from [127.0.0.1] (kekkonen.cs.hut.fi [130.233.41.50]) by twilight.cs.hut.fi (Postfix) with ESMTP id A86822D44; Tue, 21 Jun 2005 23:06:52 +0300 (EEST) In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Teemu Koponen Subject: Re: [Hipsec] Packet reordering, certificates and base exchange Date: Tue, 21 Jun 2005 13:06:56 -0700 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.622) X-Spam-Niksula: No X-Spam-Checker-Version: SpamAssassin 3.0.4-niksula20040914 (2005-06-05) on twilight.cs.hut.fi X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.0.4-niksula20040914 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Jun 20, 2005, at 10:14, Henderson, Thomas R wrote: Tom, > I think it makes sense to add capability to include certificates in the > base exchange packets. I'm not that sure it makes the utility of > stand-alone CER packets go away, though. If CER packet was removed, all other packets should be able to carry CER parameter then I think. > However, I would suggest that such a topic (using HIP with certificate > infrastructure) could be separate work item for future, and not try to > fix the base spec now with little experience on the approach. For that > matter, I would probably be more in favor of taking out CER from the > existing base spec rather than trying to improve its definition at this > time. I agree, CER should be removed from the base specification. IMHO the current approach is anyway broken and thus requires further consideration. Teemu -- _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 21 16:14:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp5A-0003jF-Cv; Tue, 21 Jun 2005 16:10:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dkp58-0003dE-Sh for hipsec@megatron.ietf.org; Tue, 21 Jun 2005 16:10:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29949 for ; Tue, 21 Jun 2005 16:10:48 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkpT6-0000ks-8J for hipsec@ietf.org; Tue, 21 Jun 2005 16:35:37 -0400 Received: from inside.nomadiclab.com (inside.nomadiclab.com [193.234.219.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 3B533212C3C; Tue, 21 Jun 2005 23:10:27 +0300 (EEST) Date: Tue, 21 Jun 2005 23:10:27 +0300 (EEST) From: Petri Jokela To: "Henderson, Thomas R" Subject: RE: [Hipsec] Packet reordering, certificates and base exchange In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> Message-ID: References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Mon, 20 Jun 2005, Henderson, Thomas R wrote: > However, I would suggest that such a topic (using HIP with certificate > infrastructure) could be separate work item for future, and not try to > fix the base spec now with little experience on the approach. For that > matter, I would probably be more in favor of taking out CER from the > existing base spec rather than trying to improve its definition at this > time. > > Tom We have now three options: 1) Try to fix the CER packet in base spec 2) Take it out and submit as a separate draft 3) Leave it as it is now 1) firstly, we should identify all the possibilities to fix the problem (some proposals exists) and secondly, validate the solutions. This requires time, and I think that we should avoid spending too much time on fixing things now. 2) is a quite easy-to-do procedure (at least removing it from the base specification). 3) is not an option, because the CER system is now broken. >From 1) and 2), I would vote for 2). /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 21 21:26:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dku0s-0003N6-09; Tue, 21 Jun 2005 21:26:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dku0r-0003N1-2v for hipsec@megatron.ietf.org; Tue, 21 Jun 2005 21:26:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05255 for ; Tue, 21 Jun 2005 21:26:43 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkuOp-0005XF-S7 for hipsec@ietf.org; Tue, 21 Jun 2005 21:51:35 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id SAA16108 for ; Tue, 21 Jun 2005 18:26:26 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j5M1QPn01399 for ; Tue, 21 Jun 2005 18:26:25 -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.211); Tue, 21 Jun 2005 18:26:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hipsec] changes to base spec? Date: Tue, 21 Jun 2005 18:26:25 -0700 Message-ID: <77F357662F8BFA4CA7074B0410171B6D095A46@XCH-NW-5V1.nw.nos.boeing.com> Thread-Topic: [Hipsec] changes to base spec? Thread-Index: AcVdHuQKafxTcUyjTHS8k+lid/1mLQAXxUHQBlKUxlA= From: "Henderson, Thomas R" To: X-OriginalArrivalTime: 22 Jun 2005 01:26:25.0584 (UTC) FILETIME=[6808D300:01C576C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I reviewed Petri's recent draft with an eye towards making changes to align with the proposals in the Aura et al. paper that we discussed last month, but found that Petri had already made most of them. I still suggest a few changes below and have sent the diffs directly to Petri. Tom ** Proposal 1: Add nonce to I1 and to unsigned part of R1=20 Action: No list consensus on adding this. ** Proposal 2: Hash nonces I and J into key material Action: Petri already made the change to Section 6.4=20 ** Proposal 3/4/5: Changes to secure the cookie mechanism Action: Petri already updated the Appendix C to correspond to the=20 stronger cookie selection mechanism. However, there is leftover from the past some guidance in 4.1.1=20 (and also in the appendix itself) to explicitly recommend against using=20 the algorithm in Appendix C. I don't think that the guidance applies anymore-- I think that we would be fine if people implement Appendix C now, with the changes proposed. Also, there is still guidance in the Appendix to allow Responder to keep state about failed puzzles. I replaced that with the following: "The Responder SHOULD NOT keep state about failed puzzle solutions." Specific diffs provided to Petri. ** Proposal 6: Do not encrypt Initiator HI in I2 Action: Petri already made this a MAY (Section 5.3.3) ** Proposal 7a: Move from R2-SENT to Unassociated upon timeout Action: Per discussion on list, do not move to Unassociated upon timeout, but only after "Unused Association Lifetime" has been exceeded Define "Unused Association Lifetime" in the Definitions section. Specific text change in R2-SENT state: From: "If no data is received during an implementation specific time, move to UNASSOCIATED" To: "No packet sent/received during UAL minutes, send CLOSE and go to CLOSING." ** Proposal 7b, 7c, and 8: Tiebreaker rules for handshake packet collisions Action: Petri seems to already have made these changes. _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 22 02:15:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkyWI-0002qR-NG; Wed, 22 Jun 2005 02:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkyWG-0002qG-LO for hipsec@megatron.ietf.org; Wed, 22 Jun 2005 02:15:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11067 for ; Wed, 22 Jun 2005 02:15:26 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkyuJ-0004A1-VF for hipsec@ietf.org; Wed, 22 Jun 2005 02:40:21 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 06E71212C3C; Wed, 22 Jun 2005 09:15:17 +0300 (EEST) In-Reply-To: References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Packet reordering, certificates and base exchange Date: Wed, 22 Jun 2005 09:15:19 +0300 To: Petri Jokela , David Ward , Gonzalo Camarillo X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > We have now three options: > > 1) Try to fix the CER packet in base spec > 2) Take it out and submit as a separate draft > 3) Leave it as it is now I think 2) is the best way to go now. I would go even a little bit further and merely define a code point (parameter type) for the certificate parameter, and state that the exact syntax, semantics, and use are to be defined elsewhere. That is, IMHO, we should include some text about certificates in the base spec lest the SEC ADs come to us and ask about this. If it is clear from the text that we have considered the situation and decided to leave it for later, that should be fine. Chairs, if the WG decided to take this way, it would be good to consider another milestone for the certificate spec. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 22 09:00:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4qV-0002lG-CM; Wed, 22 Jun 2005 09:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4qP-0002kJ-4V for hipsec@megatron.ietf.org; Wed, 22 Jun 2005 09:00:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05845 for ; Wed, 22 Jun 2005 09:00:39 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5EU-0006v3-0K for hipsec@ietf.org; Wed, 22 Jun 2005 09:25:37 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id C29AA212C64; Wed, 22 Jun 2005 16:00:18 +0300 (EEST) Message-ID: <42B960E2.3020400@nomadiclab.com> Date: Wed, 22 Jun 2005 16:00:18 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Packet reordering, certificates and base exchange References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Pekka Nikander wrote: >> We have now three options: >> >> 1) Try to fix the CER packet in base spec >> 2) Take it out and submit as a separate draft >> 3) Leave it as it is now > > > I think 2) is the best way to go now. I would go even a little bit further > and merely define a code point (parameter type) for the certificate > parameter, > and state that the exact syntax, semantics, and use are to be defined > elsewhere. I admit that I haven't waited too long time after these comments, but I edited the draft and took certificates out. I left the CERT type definition and a short piece of text. The current pre version is available at http://hip4inter.net/drafts.php dated 220605. However, if there comes still need for the certificates in the base spec, it is not a big effort to put them back. /petri -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 22 09:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4wK-000455-SJ; Wed, 22 Jun 2005 09:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4wG-00042w-Tj for hipsec@megatron.ietf.org; Wed, 22 Jun 2005 09:06:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06538 for ; Wed, 22 Jun 2005 09:06:42 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5KO-000790-14 for hipsec@ietf.org; Wed, 22 Jun 2005 09:31:41 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 89634212C64; Wed, 22 Jun 2005 16:06:34 +0300 (EEST) In-Reply-To: <42B960E2.3020400@nomadiclab.com> References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> <42B960E2.3020400@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <6dc19f1817df1d57a70045c938eb0b39@nomadiclab.com> Content-Transfer-Encoding: quoted-printable From: Pekka Nikander Subject: Re: [Hipsec] Packet reordering, certificates and base exchange Date: Wed, 22 Jun 2005 16:06:36 +0300 To: Petri Jokela X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >>> 1) Try to fix the CER packet in base spec >>> 2) Take it out and submit as a separate draft >>> 3) Leave it as it is now >> >> I think 2) is the best way to go now. I would go even a little bit=20= >> further >> and merely define a code point (parameter type) for the certificate >> parameter, >> and state that the exact syntax, semantics, and use are to be defined >> elsewhere. > > I admit that I haven't waited too long time after these comments, but = I > edited the draft and took certificates out. I left the CERT type > definition and a short piece of text. The current pre version is > available at > > http://hip4inter.net/drafts.php > > dated 220605. However, if there comes still need for the certificates=20= > in > the base spec, it is not a big effort to put them back. Ref [16]=A0(X.509) seems to be a leftover from this change. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 22 09:50:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl5d0-0008Gw-9P; Wed, 22 Jun 2005 09:50:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl5cz-0008Gr-0E for hipsec@megatron.ietf.org; Wed, 22 Jun 2005 09:50:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11271 for ; Wed, 22 Jun 2005 09:50:50 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl617-0000JK-4T for hipsec@ietf.org; Wed, 22 Jun 2005 10:15:49 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 723D6212C3C; Wed, 22 Jun 2005 16:50:43 +0300 (EEST) In-Reply-To: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v622) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Wed, 22 Jun 2005 16:50:45 +0300 To: Lars Eggert X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org I read this document again, and in general it looks good to me. The language could be improved, now it is a little bit too "abstract" or fluffy to my taste. Changing some of the terminology and especially the definitions of terms would make it easier to read. Also considering advice from draft-iab-model-XX.txt might help. But content-wise, once a proper security considerations section is added, I think the document starts to be ready for a WG LC, though most probably we have to wait for the base spec to first advance to WG LC. Major detail: Did we discuss using exponential seconds instead of seconds for the lifetimes? I don't remember any more. In general, I'm in favour of fixed point exponential times instead of integer times... The parameter type values need to be checked against base-03. Can a reply include both REG_RESPONSE and REG_FAILED params if some of the registrations succeeded and some failed? Minor details: Sec 3, bullet 3: > 3. At this point, the registrar tries to authenticate the requester > based on currently available information. The details of this > authentication procedure are not specified in this document. If It would be good to be more specific in the second statement, and refer directly to the base spec. Also make the difference between authentication (as a part of the base exchange) vs. authorisation (which is a matter local to the registrar). Sec 3, second list, bullet 1: > exchanges or later announces its capabilities by sending the It might be good to discuss briefly when REG_INFO might be sent in an UPDATE; i.e., when the registrar changes its configuration. It would also be good to note that there may be a long time between R1 with REG_INFO and UPDATE with REG_REQUEST... Sec 3, second list, bullet 3: Please clarify the authenticate vs. authorise language. I think the first sentence uses authenticate while it should use authorise. Sec 3, 2nd para after second list: > Both the requester and > registrar can cancel the created registration before its expiration. I don't understand what that is trying to say. I guess this is part of the language being too abstract or fluffy... Or otherwise I just need more coffee.... Sec 4.2: > REG_REQUEST parameter is in an UPDATE packet, the registrar SHOULD > NOT modify the registrations of registration types which are not > listed in the parameter. Moreover, the requester SHOULD NOT include IMHO these "SHOULD NOT"s should be "MUST NOT"s.... In the former case, violating the rule would lead to inconsistent state (enough for a MUST), in the latter case apply the "be strict in what you sent (and liberal in what you expect) principle". > the parameter unless the registrar's I1 packet or an earlier > received s/an earlier/latest/ > signature. The requester SHOULD support inclusion of multiple > instances of the REG_REQUEST parameter in its I2 packets. What happens if it does not? Sec 4.3: > The registrar SHOULD include the REG_RESPONSE parameter in its R2 or > UPDATE packet only if a registration has successfully completed. I don't understand why we have here a "SHOULD"?? What is the rationale? Doesn't the registrar just include it if and only if the rgistration has been succesfully completed? Sec 4.4: > The registrar SHOULD include the REG_FAILED parameter in its R2 or > UPDATE packet if registering with registration types listed has not > completed successfully and a requester is asked to try again with > additional credentials. I don't understand the rationale for the SHOULD here either. Sec 5: > REG_RESPONSE parameters. Therefore, registration type definitions > MAY define dependencies for HIP parameters that are not defined in ... specifications that define different registration types and corresponding services MAY define ... --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 22 10:16:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl618-0001iD-Iq; Wed, 22 Jun 2005 10:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl615-0001gD-Os for hipsec@megatron.ietf.org; Wed, 22 Jun 2005 10:15:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14498 for ; Wed, 22 Jun 2005 10:15:45 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl6PD-0001E4-4g for hipsec@ietf.org; Wed, 22 Jun 2005 10:40:44 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 87996212C3C; Wed, 22 Jun 2005 17:15:27 +0300 (EEST) In-Reply-To: <1A8E6681-5E59-4812-9758-F86E76556765@netlab.nec.de> References: <1A8E6681-5E59-4812-9758-F86E76556765@netlab.nec.de> Mime-Version: 1.0 (Apple Message framework v622) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9c54ce75535a0c4ee82aa997ea915e0b@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Fwd: I-D ACTION:draft-ietf-hip-rvs-02.txt Date: Wed, 22 Jun 2005 17:15:29 +0300 To: Lars Eggert X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Comments: Consider removing or greatly condensing the first two paragraphs from Introduction, and mostly replacing them with a reference to the arch document. I don't think this kind of architectural discussion belongs to this kind of a fairly-low-level protocol description. But YMMV. If you decide to make this change, also update the beginning of the third paragraph to reflect what is above in the new revision. If you want to have architectural discussion in the beginning, I would refer to the mobility discussion in the original Mobile IP(v4) architecture paper by Bhagwat, Tripathi and Perkins (1995), and discuss the need for a rendezvous point in the light of that (see the section about Location Directory). In the spirit of the above, I would also propose removing or rewriting the first paragraph of section 3. It looks like all text on how construct a proper R1 at the Responder end is missing, as well as how the Initiator verifies the received R1 with an VIA:RVS parameter. [12] needs to be a normative reference due to the text in section 3, third para after Figure 1. Minor: Sec 3.3: > If a HIP node and one of its rendezvous servers have a rendezvous > registration, the rendezvous servers MUST relay inbound I1 packets Why the "MUST" here? What danger is avoided? I would just say "servers relay" without the must. > Because of egress filtering on the path from the RVS to the client, > a > HIP rendezvous server MAY also need to replace the source IP > address, I think this "MAY" should be a "SHOULD", i.e., replacing the IP address is the RECOMMENDED way of doing it. Also update 4.4. to reflect this. > The RVS MUST verify the checksum field of an I1 packet doing any A missing "before" here? Also, the "MUST" should be a "SHOULD" because no danger to external nodes or security is involved if the RVS doesn't check the incoming checksum. Is there some text missing between the last and second last paras of Sec 3.3? I1 doesn't include SIG or HMAC paras, don't they? Sec 4.5: > When a rendezvous server receives an I1 whose destination HIT is not > its own, it MUST consult its registration database to find a > registration for the rendezvous service established by the HIT > owner. > If it finds an appropriate registration, it MUST relay the packet to > the registered IP address. If it does not find an appropriate > registration, is MUST drop the packet. Inappropriate "MUST"s (all three of them)? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 23 04:59:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlNYQ-0000Pg-Tj; Thu, 23 Jun 2005 04:59:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlNYQ-0000Pb-0i for hipsec@megatron.ietf.org; Thu, 23 Jun 2005 04:59:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18228 for ; Thu, 23 Jun 2005 04:59:20 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlNwg-0008TW-EN for hipsec@ietf.org; Thu, 23 Jun 2005 05:24:28 -0400 Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id C16B8212C3C for ; Thu, 23 Jun 2005 11:58:47 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: <7777cc9a3a59050808dadde38717da64@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: hipsec@ietf.org From: Pekka Nikander Date: Thu, 23 Jun 2005 11:58:50 +0300 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Puzzle hash function? 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org While reading the pre-version of the forthcoming -03 of the base spec, I realised that we now use a fixed hash algorithm for the puzzle, while we have the possibility of updating the HIT-generation hash function. Without thinking too much, I would propose that we define that the puzzle hash function is the same as used for generating the Responder's HIT. This change won't make it to -03, but anyway. Opinions? --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Thu Jun 23 08:27:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQnS-0007bp-VO; Thu, 23 Jun 2005 08:27:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlQnQ-0007bk-Sr for hipsec@megatron.ietf.org; Thu, 23 Jun 2005 08:27:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04012 for ; Thu, 23 Jun 2005 08:27:04 -0400 (EDT) Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlRBk-0000tT-AR for hipsec@ietf.org; Thu, 23 Jun 2005 08:52:13 -0400 Received: from [193.234.219.41] (n41.nomadiclab.com [193.234.219.41]) by n2.nomadiclab.com (Postfix) with ESMTP id 876F1212CB2 for ; Thu, 23 Jun 2005 14:44:04 +0300 (EEST) Message-ID: <42BAA084.6020600@nomadiclab.com> Date: Thu, 23 Jun 2005 14:44:04 +0300 From: Petri Jokela User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hipsec@ietf.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] Base draft -03 & ESP draft -00 submitted 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi all, I just submitted base draft version -03 and ESP draft version -00 to IETF. Drafts and diffs can also be found from: http://hip4inter.net/drafts.php BR, Petri (I will be on vacation until 25th of July) -- Petri Jokela Tel: +358 9 299 2413 Research scientist Fax: +358 9 299 3535 NomadicLab, Ericsson Research Mobile: +358 44 299 2413 Oy L M Ericsson Ab email: petri.jokela@ericsson.com _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Fri Jun 24 09:41:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloQc-0007jB-MI; Fri, 24 Jun 2005 09:41:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DloQc-0007j5-31 for hipsec@megatron.ietf.org; Fri, 24 Jun 2005 09:41:06 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08827 for ; Fri, 24 Jun 2005 09:41:03 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69E03002EE1D8 for hipsec@lists.ietf.org; Fri, 24 Jun 2005 15:40:34 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] Fwd: I-D ACTION:draft-ietf-hip-rvs-02.txt User-Agent: KMail/1.8 References: <1A8E6681-5E59-4812-9758-F86E76556765@netlab.nec.de> <9c54ce75535a0c4ee82aa997ea915e0b@nomadiclab.com> In-Reply-To: <9c54ce75535a0c4ee82aa997ea915e0b@nomadiclab.com> MIME-Version: 1.0 Content-Disposition: inline Date: Fri, 24 Jun 2005 15:41:52 +0000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200506241541.52328.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Pekka, Thanks for reviewing the draft. I agree with your comments, hence if no contradictory opinions are expressed, I will update the I-D accordingly. I have however one question regarding the validation of an R1. On Wednesday 22 June 2005 14:15, Pekka Nikander wrote: > > It looks like all text on how construct a proper R1 at the > Responder end is missing, as well as how the Initiator > verifies the received R1 with an VIA:RVS parameter. I will add text on how to construct a proper R1. Now concerning the validation of an incoming R1 in presence of a RVS, my understanding was that the VIA_RVS parameter was mainly intended to help debugging, and has only an informal nature and does not modify processing of the packet itself (hence its position after the signature in R1). Consequently I thought that processing an incoming R1 replying to a relayed I1 is no different from processing a "regular" R1. The base specification says: A system receiving an R1 MUST first check to see if it has sent an I1 to the originator of the R1 (i.e., it is in state I1-SENT). Because the state is indexed by source and destination HI/HITs, and not IP address, I assume that we don't need specific text on how to handle an R1 when a RVS was involved in I1 delivery, with or without presence of a VIA_RVS parameter. Is that correct or I am missing something? Perhaps we might also want to consider the case where the responder want to securely assert its RVS IP address to the initiator, but I am really not sure about that. Any insights appreciated. Thanks. --julien -- julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Sat Jun 25 05:12:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm6iR-000298-CX; Sat, 25 Jun 2005 05:12:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dm6iQ-000292-BD for hipsec@megatron.ietf.org; Sat, 25 Jun 2005 05:12:42 -0400 Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08975 for ; Sat, 25 Jun 2005 05:12:39 -0400 (EDT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id A8680212C3C; Sat, 25 Jun 2005 12:12:09 +0300 (EEST) In-Reply-To: <200506241524.52846.julien.laganier@laposte.net> References: <1A8E6681-5E59-4812-9758-F86E76556765@netlab.nec.de> <9c54ce75535a0c4ee82aa997ea915e0b@nomadiclab.com> <200506241524.52846.julien.laganier@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5c13a3eb820fd00c18d67dda2c60b46b@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [Hipsec] Fwd: I-D ACTION:draft-ietf-hip-rvs-02.txt Date: Sat, 25 Jun 2005 12:12:12 +0300 To: Julien Laganier X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 7bit Cc: Lars Eggert , 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > Now concerning the validation of an incoming R1 in presence of a RVS, > my understanding was that the VIA_RVS parameter was mainly intended > to help debugging, and has only an informal nature and does not > modify processing of the packet itself (hence its position after the > signature in R1). Consequently I thought that processing an incoming > R1 replying to a relayed I1 is no different from processing a > "regular" R1. The base specification says: > > A system receiving an R1 MUST first check to see > if it has sent an I1 to the originator of the R1 > (i.e., it is in state I1-SENT). > > Because the state is indexed by source and destination HI/HITs, and > not IP address, I assume that we don't need specific text on how to > handle an R1 when a RVS was involved in I1 delivery, with or without > presence of a VIA_RVS parameter. > > Is that correct or I am missing something? Hmm. I can see some implementations checking also the IP fields in incoming R1s in order to weed out potential replay attacks. Hence, I think we should include a few sentences here stating the perhaps obvious: that incoming R1s SHOULD be verified based on state on HITs only, and if IP addresses are checked, also include RVS to the check.... Or what do you think? Perhaps I am missing something? > Perhaps we might also want > to consider the case where the responder want to securely assert its > RVS IP address to the initiator, but I am really not sure about that. Hmm. If we want add that, it should be in R2, I think. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 27 04:24:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmov5-0000cr-Ek; Mon, 27 Jun 2005 04:24:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlaWI-0003KU-CD; Thu, 23 Jun 2005 18:50:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11140; Thu, 23 Jun 2005 18:49:59 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dlaui-000267-BG; Thu, 23 Jun 2005 19:15:16 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DlaWH-0007zv-Bo; Thu, 23 Jun 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 23 Jun 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-Mailman-Approved-At: Mon, 27 Jun 2005 04:24:41 -0400 Cc: hipsec@ietf.org Subject: [Hipsec] I-D ACTION:draft-ietf-hip-base-03.txt 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol Working Group of the IETF. Title : Host Identity Protocol Author(s) : R. Moskowitz, et al. Filename : draft-ietf-hip-base-03.txt Pages : 96 Date : 2005-6-23 This memo specifies the details of the Host Identity Protocol (HIP). HIP provides a rapid exchange of Host Identities (public keys) between hosts and uses a Sigma-compliant [REF] Diffie-Hellman key exchange to establish shared secrets between such endpoints. The protocol is designed to be resistant to Denial-of-Service (DoS) and Man-in-the-middle (MitM) attacks, and when used together with another suitable security protocol, such as Encapsulated Security Payload (ESP) [24], it provides encryption and/or authentication protection for upper layer protocols such as TCP and UDP, while enabling continuity of communications across network layer address changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hip-base-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hip-base-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hip-base-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-6-23161104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hip-base-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hip-base-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-6-23161104.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --NextPart-- From hipsec-bounces@lists.ietf.org Mon Jun 27 08:54:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmt7r-0002zt-BX; Mon, 27 Jun 2005 08:54:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dmt7p-0002zk-Ip for hipsec@megatron.ietf.org; Mon, 27 Jun 2005 08:54:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16887 for ; Mon, 27 Jun 2005 08:54:07 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DmtWw-0003RO-Gm for hipsec@ietf.org; Mon, 27 Jun 2005 09:20:09 -0400 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id DA1D1A9C; Mon, 27 Jun 2005 14:53:55 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 14:53:55 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Jun 2005 14:53:54 +0200 Received: from [131.160.126.95] (rvi2-126-95.lmf.ericsson.se [131.160.126.95]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 65706262D; Mon, 27 Jun 2005 15:53:54 +0300 (EEST) Message-ID: <42BFF6E1.3060302@ericsson.com> Date: Mon, 27 Jun 2005 15:53:53 +0300 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [Hipsec] Packet reordering, certificates and base exchange References: <77F357662F8BFA4CA7074B0410171B6D095A31@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2005 12:53:54.0916 (UTC) FILETIME=[469E2240:01C57B17] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi, > Chairs, if the WG decided to take this way, it would be good to consider > another milestone for the certificate spec. yes, we would need to do that. In any case, our focus should still be on requesting the publication of the base and the ESP specs right after Paris. This means that we have a very tight deadline. Thanks, Gonzalo _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 27 10:16:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmuJu-0002jU-1a; Mon, 27 Jun 2005 10:10:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmuJr-0002ic-On for hipsec@megatron.ietf.org; Mon, 27 Jun 2005 10:10:39 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24315 for ; Mon, 27 Jun 2005 10:10:37 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69F97005D4084; Mon, 27 Jun 2005 16:10:00 +0200 From: Julien Laganier To: Pekka Nikander Date: Mon, 27 Jun 2005 16:11:21 +0000 User-Agent: KMail/1.8 References: <200506241524.52846.julien.laganier@laposte.net> <5c13a3eb820fd00c18d67dda2c60b46b@nomadiclab.com> In-Reply-To: <5c13a3eb820fd00c18d67dda2c60b46b@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506271611.21480.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org Subject: [Hipsec] Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txt 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org > > Because the state is indexed by source and destination HI/HITs, > > and not IP address, I assume that we don't need specific text on > > how to handle an R1 when a RVS was involved in I1 delivery, with > > or without presence of a VIA_RVS parameter. > > > > Is that correct or I am missing something? > > Hmm. I can see some implementations checking also the IP > fields in incoming R1s in order to weed out potential replay > attacks. Hence, I think we should include a few sentences here > stating the perhaps obvious: that incoming R1s SHOULD be verified > based on state on HITs only, and if IP addresses are checked, > also include RVS to the check.... > > Or what do you think? Perhaps I am missing something? No that is fine. Do you think we should have also a SHOULD requirement for the case where IP address are also checked? > > Perhaps we might also want > > to consider the case where the responder want to securely assert > > its RVS IP address to the initiator, but I am really not sure > > about that. > > Hmm. If we want add that, it should be in R2, I think. Ok. Not sure we want it, so I'll not consider it further. Thanks. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Mon Jun 27 10:43:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmupV-0000v0-T0; Mon, 27 Jun 2005 10:43:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmupU-0000uv-G3 for hipsec@megatron.ietf.org; Mon, 27 Jun 2005 10:43:20 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28981 for ; Mon, 27 Jun 2005 10:43:17 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69E80005F627F; Mon, 27 Jun 2005 16:42:48 +0200 From: Julien Laganier To: hipsec@ietf.org Subject: Re: [Hipsec] Puzzle hash function? Date: Mon, 27 Jun 2005 16:44:10 +0000 User-Agent: KMail/1.8 References: <7777cc9a3a59050808dadde38717da64@nomadiclab.com> In-Reply-To: <7777cc9a3a59050808dadde38717da64@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506271644.10311.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org On Thursday 23 June 2005 08:58, Pekka Nikander wrote: > While reading the pre-version of the forthcoming -03 of the base > spec, I realised that we now use a fixed hash algorithm for the > puzzle, while we have the possibility of updating the > HIT-generation hash function. > > Without thinking too much, I would propose that we define that > the puzzle hash function is the same as used for generating the > Responder's HIT. > > This change won't make it to -03, but anyway. > > Opinions? FWIW I agree with the change you proposed. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 28 07:51:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEcw-0007zO-Il; Tue, 28 Jun 2005 07:51:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEcu-0007zJ-D0 for hipsec@megatron.ietf.org; Tue, 28 Jun 2005 07:51:42 -0400 Received: from mx.laposte.net (mx.laposte.net [80.245.62.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26886 for ; Tue, 28 Jun 2005 07:51:38 -0400 (EDT) Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69F970069BFEF; Tue, 28 Jun 2005 13:51:04 +0200 From: Julien Laganier To: hipsec@ietf.org, hipsec@ietf.org Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Tue, 28 Jun 2005 13:52:22 +0000 User-Agent: KMail/1.8 References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> In-Reply-To: <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506281352.23011.julien.IETF@laposte.net> Content-Transfer-Encoding: 7bit Cc: Lars Eggert 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi Pekka, On Wednesday 22 June 2005 13:50, Pekka Nikander wrote: > I read this document again, and in general it looks good to me. Thanks for reviewing it. Please find answers, but also questions :) inlined below. > The language could be improved, now it is a little bit too > "abstract" or fluffy to my taste. Changing some of the terminology > and especially the definitions of terms would make it easier to > read. Also considering advice from draft-iab-model-XX.txt might > help. But content-wise, once a proper security considerations > section is added, I think the document starts to be ready > for a WG LC, though most probably we have to wait for the base spec > to first advance to WG LC. I will try to improve the terminology and definitions following advices from draft-iab-model-03.txt > Major detail: > > Did we discuss using exponential seconds instead of seconds for > the lifetimes? I don't remember any more. In general, I'm in > favour of fixed point exponential times instead of integer > times... I don't think we discussed them yet. Right now the specification uses 32-bits integer lifetimes, with a MUST minimum of 10s and a SHOULD maximum of 120s. First of all, even if we stick to integer lifetimes, I think we can at least reduce the field size from 32-bits (~136 years) to 16-bits (~18 hours), that it is still enough, in my opinion. Then yes, we can also use exponential times; with 8-bits fields (or perhaps even less, i.e. 4 bits) that would allow to pack most of the REG_* TLV parameter into 8-bytes. For instance: 4.1 REG_INFO 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min LifeT Exp | Max LifeT Exp | Reg Type #1 | Reg Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What does other people think about having a 2^(Lifetime exponent) lifetime then? > > Can a reply include both REG_RESPONSE and REG_FAILED params > if some of the registrations succeeded and some failed? > Yes. I tried to clarify the current wording, please see later below. > Minor details: > > Sec 3, bullet 3: > > 3. At this point, the registrar tries to authenticate the > > requester based on currently available information. The details > > of this authentication procedure are not specified in this > > document. If > > It would be good to be more specific in the second statement, and > refer directly to the base spec. Also make the difference between > authentication (as a part of the base exchange) vs. authorisation > (which is a matter local to the registrar). What about: At this point, the registrar is able to authenticate the requester based on the Host Identity it includes in I2. Then, it has to verify that this Host Identity is in fact authorized to register for the requested service(s), based on policy local to the registrar. The details of this authorization procedure are dependent on the type of the requested service(s) and on the registrar local policy, and are therefore not specified in this document. Then, the registrar includes in its R2 response a REG_RESPONSE parameter containing the service(s) type(s) for which the registration was authorized, and one or more REG_FAILED parameter containing the service(s) type(s) for which registration failed or was not authorized. In particular a REG_FAILED with a failure type of zero would contain the service(s) type(s) for which registration requires further credentials. > Sec 3, second list, bullet 1: > > exchanges or later announces its capabilities by sending > > the > > It might be good to discuss briefly when REG_INFO might be sent in > an UPDATE; i.e., when the registrar changes its configuration. > It would also be good to note that there may be a long time between > R1 with REG_INFO and UPDATE with REG_REQUEST... What about: A host that is capable and willing to act as a registrar includes a REG_INFO parameter in the R1 packets it sends during base exchanges, or later in an UPDATE packet when a change of its registar-related configuration occurs. > Sec 3, second list, bullet 3: > > Please clarify the authenticate vs. authorise language. I think > the first sentence uses authenticate while it should use authorise. How about: The registrar has to verify that the requester is in fact authorized to register for the requested service(s), based on policy local to the registrar. Then, the registrar includes in its UPDATE response a REG_RESPONSE parameter containing the service(s) type(s) for which the registration was authorized, and one or more REG_FAILED parameter containing the service(s) type(s) for which registration failed or was not authorized. In particular a REG_FAILED with a failure type of zero would contain the service(s) type(s) for which registration requires further credentials. > Sec 3, 2nd para after second list: > > Both the requester and registrar can cancel the created > > registration before its expiration. > > I don't understand what that is trying to say. I guess this is > part of the language being too abstract or fluffy... Or otherwise > I just need more coffee.... What about: Both the requester and registrar can cancel a registration before it expires, if the services afforded by this registration are no longer needed by the requester, or cannot be provided any longuer by the registrar (for instance because its configuration changed). > Sec 4.2: > > REG_REQUEST parameter is in an UPDATE packet, the registrar > > SHOULD NOT modify the registrations of registration types which > > are not listed in the parameter. Moreover, the requester SHOULD > > NOT include > > IMHO these "SHOULD NOT"s should be "MUST NOT"s.... In the former > case, violating the rule would lead to inconsistent state (enough > for a MUST), in the latter case apply the "be strict in what you > sent (and liberal in what you expect) principle". I'll make the change. > > the parameter unless the registrar's I1 packet or an earlier > > received > > s/an earlier/latest/ > > > signature. The requester SHOULD support inclusion of multiple > > instances of the REG_REQUEST parameter in its I2 packets. > > What happens if it does not? Hhmm... nothing :) So perhaps it is better to say: The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets. > Sec 4.3: > > The registrar SHOULD include the REG_RESPONSE parameter in its > > R2 or UPDATE packet only if a registration has successfully > > completed. > > I don't understand why we have here a "SHOULD"?? What is the > rationale? Doesn't the registrar just include it if and only if the > rgistration has been succesfully completed? Yep. What about: The registrar include the REG_RESPONSE parameter in its R2 or UPDATE packet when a registration has successfully completed. And then if we apply the "be (strict in what you sent and) liberal in what you accept" principle once more, is it okay to modify the following paragraph like this: The registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets, while the requester MUST be able to process one or more REG_REQUEST parameters in received R2 or UPDATE packets. > Sec 4.4: > > The registrar SHOULD include the REG_FAILED parameter in its > > R2 or UPDATE packet if registering with registration types listed > > has not completed successfully and a requester is asked to try > > again with additional credentials. > > I don't understand the rationale for the SHOULD here either. So let's remove it. > Sec 5: > > REG_RESPONSE parameters. Therefore, registration type > > definitions MAY define dependencies for HIP parameters that are > > not defined in > > ... specifications that define different registration types and > corresponding services MAY define ... I'll make the change. Thank you very much for your comments, it surely helps to improve the document. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 28 07:52:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEdP-00085X-Qa; Tue, 28 Jun 2005 07:52:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEdN-00085K-4d for hipsec@megatron.ietf.org; Tue, 28 Jun 2005 07:52:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26906 for ; Tue, 28 Jun 2005 07:52:07 -0400 (EDT) Received: from mx.laposte.net ([80.245.62.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnF2b-00011K-1G for hipsec@ietf.org; Tue, 28 Jun 2005 08:18:20 -0400 Received: from [192.168.10.130] (62.206.52.42) by mx.laposte.net (7.2.060.1) (authenticated as julien.laganier) id 42B69F970069BFEF; Tue, 28 Jun 2005 13:51:04 +0200 From: Julien Laganier To: hipsec@ietf.org, hipsec@ietf.org Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Tue, 28 Jun 2005 13:52:22 +0000 User-Agent: KMail/1.8 References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> In-Reply-To: <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506281352.23011.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: 7bit Cc: Lars Eggert 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Hi Pekka, On Wednesday 22 June 2005 13:50, Pekka Nikander wrote: > I read this document again, and in general it looks good to me. Thanks for reviewing it. Please find answers, but also questions :) inlined below. > The language could be improved, now it is a little bit too > "abstract" or fluffy to my taste. Changing some of the terminology > and especially the definitions of terms would make it easier to > read. Also considering advice from draft-iab-model-XX.txt might > help. But content-wise, once a proper security considerations > section is added, I think the document starts to be ready > for a WG LC, though most probably we have to wait for the base spec > to first advance to WG LC. I will try to improve the terminology and definitions following advices from draft-iab-model-03.txt > Major detail: > > Did we discuss using exponential seconds instead of seconds for > the lifetimes? I don't remember any more. In general, I'm in > favour of fixed point exponential times instead of integer > times... I don't think we discussed them yet. Right now the specification uses 32-bits integer lifetimes, with a MUST minimum of 10s and a SHOULD maximum of 120s. First of all, even if we stick to integer lifetimes, I think we can at least reduce the field size from 32-bits (~136 years) to 16-bits (~18 hours), that it is still enough, in my opinion. Then yes, we can also use exponential times; with 8-bits fields (or perhaps even less, i.e. 4 bits) that would allow to pack most of the REG_* TLV parameter into 8-bytes. For instance: 4.1 REG_INFO 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Min LifeT Exp | Max LifeT Exp | Reg Type #1 | Reg Type #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ What does other people think about having a 2^(Lifetime exponent) lifetime then? > > Can a reply include both REG_RESPONSE and REG_FAILED params > if some of the registrations succeeded and some failed? > Yes. I tried to clarify the current wording, please see later below. > Minor details: > > Sec 3, bullet 3: > > 3. At this point, the registrar tries to authenticate the > > requester based on currently available information. The details > > of this authentication procedure are not specified in this > > document. If > > It would be good to be more specific in the second statement, and > refer directly to the base spec. Also make the difference between > authentication (as a part of the base exchange) vs. authorisation > (which is a matter local to the registrar). What about: At this point, the registrar is able to authenticate the requester based on the Host Identity it includes in I2. Then, it has to verify that this Host Identity is in fact authorized to register for the requested service(s), based on policy local to the registrar. The details of this authorization procedure are dependent on the type of the requested service(s) and on the registrar local policy, and are therefore not specified in this document. Then, the registrar includes in its R2 response a REG_RESPONSE parameter containing the service(s) type(s) for which the registration was authorized, and one or more REG_FAILED parameter containing the service(s) type(s) for which registration failed or was not authorized. In particular a REG_FAILED with a failure type of zero would contain the service(s) type(s) for which registration requires further credentials. > Sec 3, second list, bullet 1: > > exchanges or later announces its capabilities by sending > > the > > It might be good to discuss briefly when REG_INFO might be sent in > an UPDATE; i.e., when the registrar changes its configuration. > It would also be good to note that there may be a long time between > R1 with REG_INFO and UPDATE with REG_REQUEST... What about: A host that is capable and willing to act as a registrar includes a REG_INFO parameter in the R1 packets it sends during base exchanges, or later in an UPDATE packet when a change of its registar-related configuration occurs. > Sec 3, second list, bullet 3: > > Please clarify the authenticate vs. authorise language. I think > the first sentence uses authenticate while it should use authorise. How about: The registrar has to verify that the requester is in fact authorized to register for the requested service(s), based on policy local to the registrar. Then, the registrar includes in its UPDATE response a REG_RESPONSE parameter containing the service(s) type(s) for which the registration was authorized, and one or more REG_FAILED parameter containing the service(s) type(s) for which registration failed or was not authorized. In particular a REG_FAILED with a failure type of zero would contain the service(s) type(s) for which registration requires further credentials. > Sec 3, 2nd para after second list: > > Both the requester and registrar can cancel the created > > registration before its expiration. > > I don't understand what that is trying to say. I guess this is > part of the language being too abstract or fluffy... Or otherwise > I just need more coffee.... What about: Both the requester and registrar can cancel a registration before it expires, if the services afforded by this registration are no longer needed by the requester, or cannot be provided any longuer by the registrar (for instance because its configuration changed). > Sec 4.2: > > REG_REQUEST parameter is in an UPDATE packet, the registrar > > SHOULD NOT modify the registrations of registration types which > > are not listed in the parameter. Moreover, the requester SHOULD > > NOT include > > IMHO these "SHOULD NOT"s should be "MUST NOT"s.... In the former > case, violating the rule would lead to inconsistent state (enough > for a MUST), in the latter case apply the "be strict in what you > sent (and liberal in what you expect) principle". I'll make the change. > > the parameter unless the registrar's I1 packet or an earlier > > received > > s/an earlier/latest/ > > > signature. The requester SHOULD support inclusion of multiple > > instances of the REG_REQUEST parameter in its I2 packets. > > What happens if it does not? Hhmm... nothing :) So perhaps it is better to say: The requester MUST NOT include more than one REG_REQUEST parameter in its I2 or UPDATE packets, while the registrar MUST be able to process one or more REG_REQUEST parameters in received I2 or UPDATE packets. > Sec 4.3: > > The registrar SHOULD include the REG_RESPONSE parameter in its > > R2 or UPDATE packet only if a registration has successfully > > completed. > > I don't understand why we have here a "SHOULD"?? What is the > rationale? Doesn't the registrar just include it if and only if the > rgistration has been succesfully completed? Yep. What about: The registrar include the REG_RESPONSE parameter in its R2 or UPDATE packet when a registration has successfully completed. And then if we apply the "be (strict in what you sent and) liberal in what you accept" principle once more, is it okay to modify the following paragraph like this: The registrar MUST NOT include more than one REG_RESPONSE parameter in its R2 or UPDATE packets, while the requester MUST be able to process one or more REG_REQUEST parameters in received R2 or UPDATE packets. > Sec 4.4: > > The registrar SHOULD include the REG_FAILED parameter in its > > R2 or UPDATE packet if registering with registration types listed > > has not completed successfully and a requester is asked to try > > again with additional credentials. > > I don't understand the rationale for the SHOULD here either. So let's remove it. > Sec 5: > > REG_RESPONSE parameters. Therefore, registration type > > definitions MAY define dependencies for HIP parameters that are > > not defined in > > ... specifications that define different registration types and > corresponding services MAY define ... I'll make the change. Thank you very much for your comments, it surely helps to improve the document. --julien _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Tue Jun 28 07:57:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEi8-0000xu-3r; Tue, 28 Jun 2005 07:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEi5-0000xp-W1 for hipsec@megatron.ietf.org; Tue, 28 Jun 2005 07:57:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27373 for ; Tue, 28 Jun 2005 07:57:00 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnF7Q-0001Vl-EN for hipsec@ietf.org; Tue, 28 Jun 2005 08:23:13 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 201AD149FE; Tue, 28 Jun 2005 14:15:23 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 13:58:22 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id E1A3E12F372; Tue, 28 Jun 2005 13:56:46 +0200 (CEST) In-Reply-To: <200506281352.23011.julien.IETF@laposte.net> References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> <200506281352.23011.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <71712981-E8F5-4E99-A9C7-FF9D8A3108F1@netlab.nec.de> From: Lars Eggert Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Tue, 28 Jun 2005 13:56:44 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 28 Jun 2005 11:58:22.0495 (UTC) FILETIME=[AEC0CAF0:01C57BD8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 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: , Content-Type: multipart/mixed; boundary="===============0643289302==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============0643289302== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-54--81315462; protocol="application/pkcs7-signature" --Apple-Mail-54--81315462 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On 2005-6-28, at 15:52 , Julien Laganier wrote: >> Major detail: >> >> Did we discuss using exponential seconds instead of seconds for >> the lifetimes? I don't remember any more. In general, I'm in >> favour of fixed point exponential times instead of integer >> times... ... > Then yes, we can also use exponential times; with 8-bits fields (or > perhaps even less, i.e. 4 bits) that would allow to pack most of the > REG_* TLV parameter into 8-bytes. For instance: ... > What does other people think about having a 2^(Lifetime exponent) > lifetime then? In a recent tcpm draft, we used a "granularity" bit, i.e.: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind = X | Length = 4 |G| User Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Granularity (1 bit) Granularity bit, indicating the granularity of the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout" field MUST be interpreted as minutes. Otherwise (G = 0), the time interval in the "User Timeout" field MUST be interpreted as seconds. User Timeout (15 bits) Specifies the user timeout suggestion for this connection. It MUST be interpreted as a 15-bit unsigned integer. The granularity of the timeout (minutes or seconds) depends on the "G" field. This may be another choice in this case as well. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-54--81315462 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw7yUjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjE4MDczODIzWhcNMDYwNjE4MDczODIzWjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAwC64+CjRjFft0NL8szfPoms1+W/AsJ96uZ0SxhZXWynorOKPLaoCYWuE3a9SsUY5Pfj5 KQjMh6Dcv1F3LwQ/cdkiFzGBYkHU8IxKMjhZtCanKHTwyKC4Zhuy4pSArJUhsl/3z7FNKUaK7HXn JEfAvheuXQ7ve+vF+IF4uorvTmjQrvQJWjpJBIqgmya2GSnv7eZJIJmXE1sfCrVHes2eiLsxWNz+ ZB/N5h8v6NxxcrWcJa0C/IvMc2nH8dYwIk5++LV/0Ua2IDxWV/dodXxMxWoihkNUiMIZIDwgvITi 7eyStEddqzUFiTQtsasSfC2KQDrFu2J3IrdE2kkpOJ/unwIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAFxcPmBBZLSD6vhqZW 852TSPZfQZFNWg+y5lT/+Jbb5qlYjd6pTEYQIZ4I5JAcN1T8a5JkAU3ZKB0eP5mhFrptyHtpQ1hy KSq8BBF/RVFYt1Irz88+SgQ6L+1LT4lcgvxy4PGIQCLtqbvr0w29w/i7MGr+mUpjI+T1F+nKAI4m GTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMO8lIwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUwNjI4MTE1NjQ1WjAjBgkqhkiG9w0BCQQxFgQU6BRmFEULmBBDwhF8UpHn sqUeiQ8wgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAGV8R6iifgO2iEvzcUlqjaD91ibHIKmBe3xm7PZoS3NymwU3CftYFV8UVQNTL5VI8O5ZO877 7vRc9WWmMPm+U25KYehkShKfjIFbgcIA/CHSMJJtQ250zzOod6LfDHv2WopnwGtTGPWbKQ/MUIc6 81Vjc0NMb0V9R1JWDzxTWe/MTL7uVRtYa3JKEPTz9Ot9kX3cukx798kQLk1/Td4M7hfBguJX6nWu adcYlas5qqJlXU1iEpa1lCVaVRMgeKQymoAq4QjxIxHIlL/kDZWHrVpF1KRr04astDk0/wtv0Wdk ZM64lL329zXt3OpEz787/0y1OiUTa4u/5ewvhbg+ZjoAAAAAAAA= --Apple-Mail-54--81315462-- --===============0643289302== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0643289302==-- From hipsec-bounces@lists.ietf.org Tue Jun 28 07:57:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEiP-00010O-KR; Tue, 28 Jun 2005 07:57:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnEiO-00010H-EL for hipsec@megatron.ietf.org; Tue, 28 Jun 2005 07:57:20 -0400 Received: from smtp0.netlab.nec.de (smtp0.netlab.nec.de [195.37.70.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27403 for ; Tue, 28 Jun 2005 07:57:18 -0400 (EDT) Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 201AD149FE; Tue, 28 Jun 2005 14:15:23 +0200 (CEST) Received: from n-eggert.office ([10.1.1.112]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 13:58:22 +0200 Received: from [127.0.0.1] (localhost [127.0.0.1]) by n-eggert.office (Postfix) with ESMTP id E1A3E12F372; Tue, 28 Jun 2005 13:56:46 +0200 (CEST) In-Reply-To: <200506281352.23011.julien.IETF@laposte.net> References: <808825C6-FD57-48E5-8E49-F97B5FA62AD9@netlab.nec.de> <0b5f3731394d5e8ce681c033a0b87a52@nomadiclab.com> <200506281352.23011.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: <71712981-E8F5-4E99-A9C7-FF9D8A3108F1@netlab.nec.de> From: Lars Eggert Subject: Re: [Hipsec] A new I-D: HIP Registration Extension Date: Tue, 28 Jun 2005 13:56:44 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.730) X-OriginalArrivalTime: 28 Jun 2005 11:58:22.0495 (UTC) FILETIME=[AEC0CAF0:01C57BD8] 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: , Content-Type: multipart/mixed; boundary="===============0677899077==" Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org --===============0677899077== Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-54--81315462; protocol="application/pkcs7-signature" --Apple-Mail-54--81315462 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On 2005-6-28, at 15:52 , Julien Laganier wrote: >> Major detail: >> >> Did we discuss using exponential seconds instead of seconds for >> the lifetimes? I don't remember any more. In general, I'm in >> favour of fixed point exponential times instead of integer >> times... ... > Then yes, we can also use exponential times; with 8-bits fields (or > perhaps even less, i.e. 4 bits) that would allow to pack most of the > REG_* TLV parameter into 8-bytes. For instance: ... > What does other people think about having a 2^(Lifetime exponent) > lifetime then? In a recent tcpm draft, we used a "granularity" bit, i.e.: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind = X | Length = 4 |G| User Timeout | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Granularity (1 bit) Granularity bit, indicating the granularity of the "User Timeout" field. When set (G = 1), the time interval in the "User Timeout" field MUST be interpreted as minutes. Otherwise (G = 0), the time interval in the "User Timeout" field MUST be interpreted as seconds. User Timeout (15 bits) Specifies the user timeout suggestion for this connection. It MUST be interpreted as a 15-bit unsigned integer. The granularity of the timeout (minutes or seconds) depends on the "G" field. This may be another choice in this case as well. Lars -- Lars Eggert NEC Network Laboratories --Apple-Mail-54--81315462 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKgzCCAyAw ggKJoAMCAQICAw7yUjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDUwNjE4MDczODIzWhcNMDYwNjE4MDczODIzWjBgMQ8wDQYDVQQE EwZFZ2dlcnQxDTALBgNVBCoTBExhcnMxFDASBgNVBAMTC0xhcnMgRWdnZXJ0MSgwJgYJKoZIhvcN AQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAwC64+CjRjFft0NL8szfPoms1+W/AsJ96uZ0SxhZXWynorOKPLaoCYWuE3a9SsUY5Pfj5 KQjMh6Dcv1F3LwQ/cdkiFzGBYkHU8IxKMjhZtCanKHTwyKC4Zhuy4pSArJUhsl/3z7FNKUaK7HXn JEfAvheuXQ7ve+vF+IF4uorvTmjQrvQJWjpJBIqgmya2GSnv7eZJIJmXE1sfCrVHes2eiLsxWNz+ ZB/N5h8v6NxxcrWcJa0C/IvMc2nH8dYwIk5++LV/0Ua2IDxWV/dodXxMxWoihkNUiMIZIDwgvITi 7eyStEddqzUFiTQtsasSfC2KQDrFu2J3IrdE2kkpOJ/unwIDAQABo2IwYDAqBgUrZQEEAQQhMB8C AQAwGjAYAgEEBBNMMnVNeWZmQk5VYk5KSmNkWjJzMCQGA1UdEQQdMBuBGWxhcnMuZWdnZXJ0QG5l dGxhYi5uZWMuZGUwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQAFxcPmBBZLSD6vhqZW 852TSPZfQZFNWg+y5lT/+Jbb5qlYjd6pTEYQIZ4I5JAcN1T8a5JkAU3ZKB0eP5mhFrptyHtpQ1hy KSq8BBF/RVFYt1Irz88+SgQ6L+1LT4lcgvxy4PGIQCLtqbvr0w29w/i7MGr+mUpjI+T1F+nKAI4m GTCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1 bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMT G1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJl ZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNa LIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1Ud HwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWls Q0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVs Mi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYf qi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa 9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggQYMIIDgaADAgECAgEAMA0G CSqGSIb3DQEBBQUAMIG/MQswCQYDVQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVy ZzETMBEGA1UEBxMKSGVpZGVsYmVyZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsT FE5ldHdvcmsgTGFib3JhdG9yaWVzMRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkq hkiG9w0BCQEWGWxhcnMuZWdnZXJ0QG5ldGxhYi5uZWMuZGUwHhcNMDQwNjE4MTE1MzA4WhcNMDkw NjE3MTE1MzA4WjCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRlbWJlcmcx EzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYDVQQLExRO ZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgwJgYJKoZI hvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB iQKBgQC0OQwsE86Rrt0Zs0GOCsYmkGpPwcCFvVpOijIPv1dGolr5a8+7hXSAgRlUyoclq9xfhsUT wlU1qkvVRD3/QOfQyPUxQktxba2ksfsPAKUHovInWydC6rvLU89jtYGEdnRCyA+cEB/XcSADbd2z 9/XK4A2cxmMQiYpXIphYQAxIBwIDAQABo4IBIDCCARwwHQYDVR0OBBYEFOh7L9eqGHnAhbJdO4PY LYzxCaNNMIHsBgNVHSMEgeQwgeGAFOh7L9eqGHnAhbJdO4PYLYzxCaNNoYHFpIHCMIG/MQswCQYD VQQGEwJERTEcMBoGA1UECBQTQmFkZW4tV8N1ZXJ0dGVtYmVyZzETMBEGA1UEBxMKSGVpZGVsYmVy ZzEXMBUGA1UEChMOTkVDIEV1cm9wZSBMdGQxHTAbBgNVBAsTFE5ldHdvcmsgTGFib3JhdG9yaWVz MRswGQYDVQQDExJrb2JlLm5ldGxhYi5uZWMuZGUxKDAmBgkqhkiG9w0BCQEWGWxhcnMuZWdnZXJ0 QG5ldGxhYi5uZWMuZGWCAQAwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQCX6Ipd3AF9 3FDzBaw3ZVvQzzCv/kGPBBzzrJ3n5u+4eQppmOifhuWHZfb8h8S++jqcoPHGVjjlP5PaFb+wL0NR piBalRclikD3xIY/hFoxJ1AHCO0AzfFxEflO10b4+smMrBYJtk5d9EAhr5hEgoGCM7QijBtnCwZB KLI9pFgW1zGCA6UwggOhAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMO8lIwCQYFKw4DAhoFAKCCAhEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDUwNjI4MTE1NjQ1WjAjBgkqhkiG9w0BCQQxFgQU6BRmFEULmBBDwhF8UpHn sqUeiQ8wgdYGCSsGAQQBgjcQBDGByDCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVu LVfDdWVydHRlbWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUg THRkMR0wGwYDVQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIu bmVjLmRlMSgwJgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMIHYBgsq hkiG9w0BCRACCzGByKCBxTCBvzELMAkGA1UEBhMCREUxHDAaBgNVBAgUE0JhZGVuLVfDdWVydHRl bWJlcmcxEzARBgNVBAcTCkhlaWRlbGJlcmcxFzAVBgNVBAoTDk5FQyBFdXJvcGUgTHRkMR0wGwYD VQQLExROZXR3b3JrIExhYm9yYXRvcmllczEbMBkGA1UEAxMSa29iZS5uZXRsYWIubmVjLmRlMSgw JgYJKoZIhvcNAQkBFhlsYXJzLmVnZ2VydEBuZXRsYWIubmVjLmRlAgEAMA0GCSqGSIb3DQEBAQUA BIIBAGV8R6iifgO2iEvzcUlqjaD91ibHIKmBe3xm7PZoS3NymwU3CftYFV8UVQNTL5VI8O5ZO877 7vRc9WWmMPm+U25KYehkShKfjIFbgcIA/CHSMJJtQ250zzOod6LfDHv2WopnwGtTGPWbKQ/MUIc6 81Vjc0NMb0V9R1JWDzxTWe/MTL7uVRtYa3JKEPTz9Ot9kX3cukx798kQLk1/Td4M7hfBguJX6nWu adcYlas5qqJlXU1iEpa1lCVaVRMgeKQymoAq4QjxIxHIlL/kDZWHrVpF1KRr04astDk0/wtv0Wdk ZM64lL329zXt3OpEz787/0y1OiUTa4u/5ewvhbg+ZjoAAAAAAAA= --Apple-Mail-54--81315462-- --===============0677899077== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec --===============0677899077==-- From hipsec-bounces@lists.ietf.org Wed Jun 29 13:54:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dngld-0000Qz-Qk; Wed, 29 Jun 2005 13:54:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnglc-0000Qu-Ho for hipsec@megatron.ietf.org; Wed, 29 Jun 2005 13:54:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17863 for ; Wed, 29 Jun 2005 13:54:31 -0400 (EDT) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnhBC-0000Wh-Oe for hipsec@ietf.org; Wed, 29 Jun 2005 14:21:00 -0400 Message-ID: <08d601c57cd3$c86541b0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Wed, 29 Jun 2005 10:55:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Subject: [Hipsec] BOF at IETF 63 on Network-based Localized Mobility Management 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org Phil Roberts and I are organizing a BOF on network based localized mobility management (netlmm) for IETF 63. The idea is to provide support in the local access network for mobility management so that a mobile node doesn't have to change its IP address so frequently. The BOF description is at: http://www.geocities.com/kempf42/netlmm-bof.txt There's a mailing list: netlmm@ngnet.it https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm, to subscribe Currently, the list is being used by co-authors of the problem statement and requirements drafts, but please subscribe and join in discussion if you would like. Please don't respond to this message, since any discussion on the proposed BOF should be on the BOF list. The problem statement draft is available from the Internet Drafts repository: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=13248 The requirements draft is about complete and will be posted to the Internet Drafts repository by the end of the week. I'll send email to the list about it when its posted. Phil and I are working on a proposed WG charter, we'll post the charter to the list when its complete. jak _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec From hipsec-bounces@lists.ietf.org Wed Jun 29 16:57:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnjcz-0004Je-JM; Wed, 29 Jun 2005 16:57:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnjcx-0004Il-NO for hipsec@megatron.ietf.org; Wed, 29 Jun 2005 16:57:48 -0400 Received: from n2.nomadiclab.com (n2.nomadiclab.com [193.234.219.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24916 for ; Wed, 29 Jun 2005 16:57:44 -0400 (EDT) Received: from [IPv6:::1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 79BC0212C4E; Wed, 29 Jun 2005 23:57:12 +0300 (EEST) In-Reply-To: <200506271611.21480.julien.IETF@laposte.net> References: <200506241524.52846.julien.laganier@laposte.net> <5c13a3eb820fd00c18d67dda2c60b46b@nomadiclab.com> <200506271611.21480.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Pekka Nikander Date: Wed, 29 Jun 2005 22:57:10 +0200 To: Julien Laganier X-Mailer: Apple Mail (2.622) Content-Transfer-Encoding: 7bit Cc: Lars Eggert , hipsec@ietf.org Subject: [Hipsec] Re: Processing of R1 w/ RVS [Was:] I-D ACTION:draft-ietf-hip-rvs-02.txt 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: , Sender: hipsec-bounces@lists.ietf.org Errors-To: hipsec-bounces@lists.ietf.org >>> Because the state is indexed by source and destination HI/HITs, >>> and not IP address, I assume that we don't need specific text on >>> how to handle an R1 when a RVS was involved in I1 delivery, with >>> or without presence of a VIA_RVS parameter. >>> >>> Is that correct or I am missing something? >> >> Hmm. I can see some implementations checking also the IP >> fields in incoming R1s in order to weed out potential replay >> attacks. Hence, I think we should include a few sentences here >> stating the perhaps obvious: that incoming R1s SHOULD be verified >> based on state on HITs only, and if IP addresses are checked, >> also include RVS to the check.... >> >> Or what do you think? Perhaps I am missing something? > > No that is fine. Do you think we should have also a SHOULD requirement > for the case where IP address are also checked? FWIW, I think that the base spec should simply say that when matching an incoming R1, the IP addresses SHOULD be ignored and the match SHOULD be based on HITs only. Of course, that is usually impossible for opportunistic connections, though. The RVS spec could then state that if an implementation checks the IP addresses anyway, it MUST check for an VIA_RVS parameter and use that for matching. --Pekka _______________________________________________ Hipsec mailing list Hipsec@lists.ietf.org https://www1.ietf.org/mailman/listinfo/hipsec