From nobody Thu May 4 05:46:56 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017671294A2 for ; Thu, 4 May 2017 05:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iD5HliDGhV5 for ; Thu, 4 May 2017 05:46:52 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59ABA120727 for ; Thu, 4 May 2017 05:46:52 -0700 (PDT) X-AuditID: c1b4fb30-663149a00000015f-03-590b22bad4d3 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CB.6C.00351.AB22B095; Thu, 4 May 2017 14:46:50 +0200 (CEST) Received: from [100.94.39.60] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.339.0; Thu, 4 May 2017 14:46:49 +0200 To: =?UTF-8?Q?Ren=c3=a9_Hummen?= References: <2a03c2d9-5a92-f630-d445-54313a231123@ericsson.com> CC: Tom Henderson , HIP From: Gonzalo Camarillo Message-ID: <9eff5119-2830-29d9-e3a8-8279bde233ad@ericsson.com> Date: Thu, 4 May 2017 15:46:48 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2a03c2d9-5a92-f630-d445-54313a231123@ericsson.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM2K7pe4uJe5Ig71T9S2mLprMbPHu6HcW i5nnD7I5MHvsnHWX3WPJkp9MHi3XYwKYo7hsUlJzMstSi/TtErgy5v9TKthjVtG75ih7A+MO tS5GDg4JAROJVz+Uuhi5OIQEjjBKXNq2jBXCWckosfXWFvYuRk4OYQFDifYp7WwgtoiAncSS Iw+hin4ySWxqnMIIMolZwFni9/lEkBo2AQuJLbfus4DYvAL2Ep+ePmcEsVkEVCS6Djezgtii AjESLUs+MELUCEqcnPkErJ5TwEFi7o4b7BAjNSXW79IHCTMLyEs0b53NDGILCWhLLH/WwjKB UWAWku5ZCB2zkHQsYGRexShanFqclJtuZKSXWpSZXFycn6eXl1qyiREYoge3/DbYwfjyueMh RgEORiUe3oRHnJFCrIllxZW5hxglOJiVRHi5FbgjhXhTEiurUovy44tKc1KLDzFKc7AoifM6 7rsQISSQnliSmp2aWpBaBJNl4uCUamBcZayqZ77QYJ9w/GHZbSEOOpGvpzS83SDy4+O+GCk9 lfXGrjxxkZlm+7l+dkkKW97gvnpry4FsnyWly6rF7jJ9V9NfEG735s3aO24fChaoMX7b9PyY 6Afb+YmGv0/80//LdWPqqQncOpN6Cp83J8QxMIZMe6ww1zyUM/fK1UPtCUWW5b3bDs9SYinO SDTUYi4qTgQAEgdJ9k0CAAA= Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-dex-04 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 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: , X-List-Received-Date: Thu, 04 May 2017 12:46:55 -0000 Rene, I am re-sending my email below. Thanks! Gonzalo On 27/04/2017 2:14 PM, Gonzalo Camarillo wrote: > Hi Rene, > > to be clear, you had 3 questions on your email below and you said you > needed further input from the group. Do you mean version 05 of the draft > is ready to be sent to the IESG (i.e., ready for publication request), > or you will revise the draft once more before it is ready? > > Thanks, > > Gonzalo > > > On 26/03/2017 7:16 PM, René Hummen wrote: >> Hi Gonzalo, >> >> I did not receive any comments indicating the need to make further >> changes. From my side, we are ready to finalize the draft. >> >> BR >> René >> >> 2017-03-16 16:25 GMT+01:00 Gonzalo Camarillo >> >: >> >> Hi Rene, >> >> did you get answers to your questions below and, in general, enough >> input to finalize the draft? >> >> Thanks, >> >> Gonzalo >> >> On 05/02/2017 11:59 PM, René Hummen wrote: >> > Hi Tom, >> > >> > thanks for your review! >> > >> > I have addressed most of your comments in the new revision 05 that I >> > just uploaded before. For your remaining comments, I need additional >> > input from you and the rest of this group: >> > >> > 1) The text from Section 6.3 that you refer to is the same as in >> RFC5201 >> > (HIPv1). I agree with you on the endianess. However, I assume that >> there >> > was a good reason why the sort() was specified this way in the >> original >> > HIP version. I would therefore prefer to keep the text as is. >> > Concerning the 96 vs. 128 bit issue, the draft defines HITs the >> same way >> > as HIPv2, which from my understanding are the full 128bit. >> > >> > 2) Concerning Sec. 6.5 through 6.8, I consciously chose to provide the >> > full specification here in order to significantly increase the >> > readability of these sections. When only stating the differences, I >> > found myself constantly changing between two documents (RFC7401 >> for the >> > content and the DEX draft to see if the content was relevant, removed, >> > or modified). To support those interested in the changes between >> RFC7401 >> > and the DEX draft, I specifically call out the main differences at the >> > end of each section. Does this satisfy your comment? >> > >> > 3) If your suggestion for Section 10 is purely cosmetic in nature, I >> > would prefer to not put additional effort into the IANA section. >> So, are >> > these changes cosmetic or mandatory? >> > >> > BR >> > René >> > >> > 2016-11-20 3:32 GMT+01:00 Tom Henderson > >> > >>: >> > >> > Gonzalo, I have reviewed HIP DEX again and believe it is ready to >> > publish, although I spotted a few minor items below that can be >> > handled in the next revision. >> > >> > - Tom >> > >> > Editorial/minor: >> > >> > Section 1: The numbered list is somewhat tersely written and may be >> > hard to interpret by the newcomer to HIP specifications. Consider >> > to elaborate more (using fuller sentences and not sentence >> > fragments). e.g.: >> > >> > "Forfeit of Perfect Forward Secrecy with the dropping of an >> > ephemeral Diffie-Hellman key agreement." could be >> > "Forfeit of the HIPv2 Perfect Forward Secrecy property due to the >> > removal of the HIPv2 ephemeral Diffie-Hellman key agreement." >> > >> > Section 1.1, spell out 'DoS' first time usage >> > >> > Section 4.1: "Note that x and y each constitute half the final >> > session key material." (change to 'half of the') >> > >> > The figure in 4.1 does not have a caption, and also, why is 'mac' >> > lowercased? >> > >> > Sec 4.1.3.1 : "Since only little data is >> protected >> > by this SA" (perhaps s/little/a small amount/) >> > >> > Sec. 5.2.4: "The following new HIT Suite IDs are defined..." >> (s/IDs >> > are/ID is/ because there is only one defined) >> > >> > Sec. 6.3: "sort(HIT-I | HIT-R) is defined as the network byte >> order >> > concatenation of the two HITs... comparison of the two HITs >> > interpreted as positive (unsigned) 128-bit integers in network >> byte >> > order" what does it mean to define a sort on a network byte order >> > concatenation? It seems perhaps clearer to leave endian >> issues out >> > (they are implicit everywhere in a protocol) and just define >> it as a >> > comparison on HITs interpreted as unsigned 128-bit integers >> (and by >> > the way, is the full 128 bits including prefix included or >> just the >> > 96 bits)? >> > >> > Sec. 6.5 through 6.8: Unlike much of this draft, these >> sections do >> > not just specifically call out the differences from the >> > corresponding RFC 7401 sections, but instead restate the modified >> > processing flow, and it is hard to spot what is different here. I >> > wonder whether it would be clearer to just refer to those >> processing >> > steps in RFC 7401 that are changed. >> > >> > Sec. 8: Can a MITM reply to I1 with ICMP parameter problem, >> causing >> > the true response (coming later) to be ignored because the >> initiator >> > already gave up? Maybe clarify here or in sec 5.4 to wait a >> little >> > while before accepting the result of an ICMP. >> > >> > Sec. 10: Consider to update the IANA section in the style >> that RFC >> > 8003 (and others) used, stating the history of the registry >> and what >> > exactly is requested to be changed. For example, something like >> > "RFC 5201 and later RFC 7401 established the following registry >> > .... This document defines the following new codepoints for that >> > registry ..." >> > >> > >> > _______________________________________________ >> > Hipsec mailing list >> > Hipsec@ietf.org >> > >> > https://www.ietf.org/mailman/listinfo/hipsec >> >> > > > >> > >> > >> >> > From nobody Sun May 14 08:48:21 2017 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8459120724 for ; Sun, 14 May 2017 08:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXpS5EHRD6Xk for ; Sun, 14 May 2017 08:48:16 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2476512947E for ; Sun, 14 May 2017 08:46:55 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id v4so22797001wmb.2 for ; Sun, 14 May 2017 08:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=i4V+q6jPuDiSIFecwPn5/Rh7w3bAKd94f7DW71mYElQ=; b=J37lYaXAmP5PYTuWrSbLspLyrVZf5TbOQnlIecGritbL49P6lpcQj8jubsBaqNpyX8 tagrePLMME2ZqlSlCV3O8o65E2DfKUyu9v1LBPY33luZUz6KyYJ3yOLwnS8QO4J7WjRp 5pTTjh0RULvHcDrT8QszkJq3ahN8Bu6UaAM4cdh90CnMHdDJnAN29ZpzrKtX5dAhVkP3 ITNxW9oHSBb6FQ/dZLbfxfVwsG09bvq0Z5zQDYPiAUjLfyK+7GSASPX8CJ9au4HhXWjr vgbM3csWqo/juG6z2KGjXrtMl/t8edDtrIdp9iiFGsXVstZQkTCq99PaJAOgOL8N1nRs s1Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=i4V+q6jPuDiSIFecwPn5/Rh7w3bAKd94f7DW71mYElQ=; b=cV8CwCY5IrSObXO8m2YTVaSk7R51yn2+M0cIeJOakmrWLaZpsO+jLqpdz30gBkSdEp VNQSD5AL091Bt4YUa038a0U02Mf7gvoF/cLHySMtnOXHdUKFsv+wjiHHlTvwUw+YUHKg YUznhB2uEgzAe3Cevsf4LMxyEwWb4RPu7u6zWGUPjpA35DBGii+1q80Ihl4pyzzKAe7X uIf2JdspBMXLXB46t3FCehPNbju+YxD2TMbGZM1nLhalJ8yJ4MjYvWb0pHWblm+UyAaL Z6+NT4JkEdcREI6ZetbI1dtVNayrV8Tmj2Fze4CdvgTNstuAsbDS0EDYZ7QXjhri/J3r mKMA== X-Gm-Message-State: AODbwcDwcsZXJcXwNQ1MMO5I6huyVSRuinD30A8cjptqwysJhXKKE0RJ ztMFeXCbxUV0QQ== X-Received: by 10.28.65.213 with SMTP id o204mr1392914wma.43.1494776813663; Sun, 14 May 2017 08:46:53 -0700 (PDT) Received: from DESKTOPPC (HSI-KBW-046-005-254-107.hsi8.kabel-badenwuerttemberg.de. [46.5.254.107]) by smtp.gmail.com with ESMTPSA id o17sm7223884wra.56.2017.05.14.08.46.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 May 2017 08:46:53 -0700 (PDT) From: =?UTF-8?Q?Ren=C3=A9_Hummen?= To: "'Gonzalo Camarillo'" Cc: "'Tom Henderson'" , "'HIP'" References: <2a03c2d9-5a92-f630-d445-54313a231123@ericsson.com> <9eff5119-2830-29d9-e3a8-8279bde233ad@ericsson.com> In-Reply-To: <9eff5119-2830-29d9-e3a8-8279bde233ad@ericsson.com> Date: Sun, 14 May 2017 17:46:54 +0200 Message-ID: <024401d2ccc9$4fed99f0$efc8cdd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFGAPKJUdOWOk9LfCDa9woiKhUCVgHPnArZAlIuZfQCL4HPVwHNQAjaAonyia0C4PtDL6KhRDsw Content-Language: de Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-dex-04 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 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: , X-List-Received-Date: Sun, 14 May 2017 15:48:20 -0000 Hi Gonzalo, draft-ietf-hip-dex-05 is ready to be sent to the IESG. BR Ren=C3=A9 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Donnerstag, 4. Mai 2017 14:47 To: Ren=C3=A9 Hummen Cc: Tom Henderson ; HIP Subject: Re: [Hipsec] WGLC: draft-ietf-hip-dex-04 Rene, I am re-sending my email below. Thanks! Gonzalo On 27/04/2017 2:14 PM, Gonzalo Camarillo wrote: > Hi Rene, >=20 > to be clear, you had 3 questions on your email below and you said you=20 > needed further input from the group. Do you mean version 05 of the=20 > draft is ready to be sent to the IESG (i.e., ready for publication=20 > request), or you will revise the draft once more before it is ready? >=20 > Thanks, >=20 > Gonzalo >=20 >=20 > On 26/03/2017 7:16 PM, Ren=C3=A9 Hummen wrote: >> Hi Gonzalo, >> >> I did not receive any comments indicating the need to make further=20 >> changes. From my side, we are ready to finalize the draft. >> >> BR >> Ren=C3=A9 >> >> 2017-03-16 16:25 GMT+01:00 Gonzalo Camarillo=20 >> >: >> >> Hi Rene, >> >> did you get answers to your questions below and, in general, = enough >> input to finalize the draft? >> >> Thanks, >> >> Gonzalo >> >> On 05/02/2017 11:59 PM, Ren=C3=A9 Hummen wrote: >> > Hi Tom, >> > >> > thanks for your review! >> > >> > I have addressed most of your comments in the new revision 05 = that I >> > just uploaded before. For your remaining comments, I need = additional >> > input from you and the rest of this group: >> > >> > 1) The text from Section 6.3 that you refer to is the same as = in >> RFC5201 >> > (HIPv1). I agree with you on the endianess. However, I assume = that >> there >> > was a good reason why the sort() was specified this way in the >> original >> > HIP version. I would therefore prefer to keep the text as is. >> > Concerning the 96 vs. 128 bit issue, the draft defines HITs the >> same way >> > as HIPv2, which from my understanding are the full 128bit. >> > >> > 2) Concerning Sec. 6.5 through 6.8, I consciously chose to = provide the >> > full specification here in order to significantly increase the >> > readability of these sections. When only stating the = differences, I >> > found myself constantly changing between two documents (RFC7401 >> for the >> > content and the DEX draft to see if the content was relevant, = removed, >> > or modified). To support those interested in the changes = between >> RFC7401 >> > and the DEX draft, I specifically call out the main differences = at the >> > end of each section. Does this satisfy your comment? >> > >> > 3) If your suggestion for Section 10 is purely cosmetic in = nature, I >> > would prefer to not put additional effort into the IANA = section. >> So, are >> > these changes cosmetic or mandatory? >> > >> > BR >> > Ren=C3=A9 >> > >> > 2016-11-20 3:32 GMT+01:00 Tom Henderson = > >> > >>: >> > >> > Gonzalo, I have reviewed HIP DEX again and believe it is = ready to >> > publish, although I spotted a few minor items below that = can be >> > handled in the next revision. >> > >> > - Tom >> > >> > Editorial/minor: >> > >> > Section 1: The numbered list is somewhat tersely written = and may be >> > hard to interpret by the newcomer to HIP specifications. = Consider >> > to elaborate more (using fuller sentences and not sentence >> > fragments). e.g.: >> > >> > "Forfeit of Perfect Forward Secrecy with the dropping of an >> > ephemeral Diffie-Hellman key agreement." could be >> > "Forfeit of the HIPv2 Perfect Forward Secrecy property due = to the >> > removal of the HIPv2 ephemeral Diffie-Hellman key = agreement." >> > >> > Section 1.1, spell out 'DoS' first time usage >> > >> > Section 4.1: "Note that x and y each constitute half the = final >> > session key material." (change to 'half of the') >> > >> > The figure in 4.1 does not have a caption, and also, why is = 'mac' >> > lowercased? >> > >> > Sec 4.1.3.1 : "Since only little data is >> protected >> > by this SA" (perhaps s/little/a small amount/) >> > >> > Sec. 5.2.4: "The following new HIT Suite IDs are = defined..." >> (s/IDs >> > are/ID is/ because there is only one defined) >> > >> > Sec. 6.3: "sort(HIT-I | HIT-R) is defined as the network = byte >> order >> > concatenation of the two HITs... comparison of the two HITs >> > interpreted as positive (unsigned) 128-bit integers in = network >> byte >> > order" what does it mean to define a sort on a network = byte order >> > concatenation? It seems perhaps clearer to leave endian >> issues out >> > (they are implicit everywhere in a protocol) and just = define >> it as a >> > comparison on HITs interpreted as unsigned 128-bit integers >> (and by >> > the way, is the full 128 bits including prefix included or >> just the >> > 96 bits)? >> > >> > Sec. 6.5 through 6.8: Unlike much of this draft, these >> sections do >> > not just specifically call out the differences from the >> > corresponding RFC 7401 sections, but instead restate the = modified >> > processing flow, and it is hard to spot what is different = here. I >> > wonder whether it would be clearer to just refer to those >> processing >> > steps in RFC 7401 that are changed. >> > >> > Sec. 8: Can a MITM reply to I1 with ICMP parameter = problem, >> causing >> > the true response (coming later) to be ignored because the >> initiator >> > already gave up? Maybe clarify here or in sec 5.4 to wait = a >> little >> > while before accepting the result of an ICMP. >> > >> > Sec. 10: Consider to update the IANA section in the style >> that RFC >> > 8003 (and others) used, stating the history of the registry >> and what >> > exactly is requested to be changed. For example, something = like >> > "RFC 5201 and later RFC 7401 established the following = registry >> > .... This document defines the following new codepoints = for that >> > registry ..." >> > >> > >> > _______________________________________________ >> > Hipsec mailing list >> > Hipsec@ietf.org >> > >> > https://www.ietf.org/mailman/listinfo/hipsec >> >> > > > >> > >> > >> >> >=20