From nobody Thu Mar 1 06:13:04 2018 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 9E19A12E057 for ; Thu, 1 Mar 2018 06:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 0yDlIjUdNGEy for ; Thu, 1 Mar 2018 06:13:01 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 BC8A5124234 for ; Thu, 1 Mar 2018 06:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519913579; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a0VZrr9PqEfU+lE8z1RZPF+OgN4fjJzm6LzJQdMacFc=; b=TG8/ZmNT3pd5uaefLTOttzKSISuJDuFtA1j1n33/zm69MqtRYzStSu3sxhzh6ptI 0NQNiSISZW/AKV+Zowo0ZGL7E0pJ4fIPbU18/FKAi5UnrGMimyBcE+C6F5N8osqC /M8FUfE2A2iaaQDBqgpjYfdZUjfr+9nURBgiI5/Knmo=; X-AuditID: c1b4fb25-083ff70000002d5f-ad-5a980a6a4c6f Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 69.8A.11615.A6A089A5; Thu, 1 Mar 2018 15:12:59 +0100 (CET) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.352.0; Thu, 1 Mar 2018 15:12:58 +0100 From: Miika Komu To: Roni Even , CC: , , References: <151965127608.31482.7946240138786040730@ietfa.amsl.com> Organization: Ericsson AB Message-ID: <07dbd7e2-ad0b-8483-e181-b911f3b4a7ba@ericsson.com> Date: Thu, 1 Mar 2018 16:12:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151965127608.31482.7946240138786040730@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2K7sW4214wog0d7mCw2nd7DanH11WcW i6mLJjNbPNs4n8XibzuzA6vHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJUx58EO9oJvshUH Z95ia2BcJ97FyMkhIWAi8ePjRMYuRi4OIYHDjBIbFr5ngnBWM0oc+L2fFaSKTUBLYtWd68wg trCAn8ShvzvZuhg5OEQErCQ2znYBMZkFYiSal5uBVAgJOEvsmfiGEcTmF5CU2NCwG6yTV8Be Yt6B3UwgNouAisSl2R9ZQGxRgQiJzpXzWSBqBCVOznwCZnMKuEg83rMarJdZwEJi5vzzjBC2 uMStJ/OZIGx5ie1v5zCDnCAENPPiseAJjEKzkEyahaR7FpLuWUi6FzCyrGIULU4tTspNNzLW Sy3KTC4uzs/Ty0st2cQIDPuDW36r7mC8/MbxEKMAB6MSD+92hhlRQqyJZcWVuYcYJTiYlUR4 T2+fFiXEm5JYWZValB9fVJqTWnyIUZqDRUmcd45we5SQQHpiSWp2ampBahFMlomDU6qB0aVy 412L1YszeqbY1TGfqnjKXZOyTz3icnbnoYC414V/Ss6E9/j+nrTwd3bU7vlMCi3VZ4J/+BTq W03JTNWXm6uymiGhTPgSy6lLh+ct19q0y8532z+miUfDf3T83Xn5M2tc0oEdjKy++mosWusf rwmYKLX3wasOnwp+h/+bXhnUnfpz3K4vSomlOCPRUIu5qDgRAAVrbjJ3AgAA Archived-At: Subject: Re: [Hipsec] Genart last call review of draft-ietf-hip-native-nat-traversal-27 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, 01 Mar 2018 14:13:03 -0000 Hi Roni, thanks for the detailed review! My comments are below. On 02/26/2018 03:21 PM, Roni Even wrote: > Reviewer: Roni Even > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-hip-native-nat-traversal-?? > Reviewer: Roni Even > Review Date: 2018-02-26 > IETF LC End Date: 2018-02-26 > IESG Telechat date: Not scheduled for a telechat > > Summary: > The document is almost ready for publication as a standard track RFC > > Major issues: > > Minor issues: > > 1. in section 4.2 "Gathering of candidates MAY also be performed by other means > than described in this section. For example, the candidates could be > gathered as specified in Section 4.2 of [RFC5770] if STUN servers are > available, or if the host has just a single interface and no STUN orData > Relay Server are available." I did not see this a different ways since > section 3 says "The hosts use either Control Relay Servers or Data Relay > Servers (or other infrastructure including STUN or TURN servers) for > gathering the candidates." so STUN is mentioned also here. I suggest to remove the remark in parenthesis (or other infrastructure including STUN or TURN servers). Does this solve the issue? > 2. In section 4.6.2 "The connectivity check messages MUST be paced by the Ta > value negotiated during the base exchange as described in Section 4.4. If > neither one of the hosts announced a minimum pacing value, a value of 20 ms > SHOULD be used." in section 4.4 the default value is 50 ms? Good catch! I double checked this from the ICE spec, which defaults also to 50 ms. So, I change the value to 50 ms also in section 4.6.2. > 3. in section 5.4 what about "ICE-STUN-UDP 2" ; I assume it is not > relevant but this is also the IANA registeration I think it makes sense to add the missing one as you suggest, but omit it from the IANA registration since it is already registered for RFC5770. > 4. In section 5.5 "The TRANSACTION_PACING is a new parameter" it is not new it > is in RFC5770 You're right, I'll change this. > 5. In section 5.10 "SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63" is the > only new one. this also relates to section 7 that says that all error values in > section 5.10 are new while the rest are in RFC5770. Also there is no mention in > section 7 of which registry is used for the error values. Good catch, I'll correct these and add the IANA registry. > Nits/editorial comments: > 1. Expand SPI and LSI when first appear in the document > > 2. in section 2 "the base of an candidate" should be "a candidate" > > 3. In section 3 "so it is the Initiator may also have registered to a Control > and/or Data Relay Server" maybe "so the Initiator may also need to register to > a Control and/or Data Relay Server" > > 4. In section 4.2 "However, it is RECOMMENDED that a Data Relay Client > registers a new server reflexive candidate for each its peer for the reasons > described" maybe "for each of its..." Thanks for spotting these, will fix as suggested. > 5. In section 4.2 I could not parse the sentence "where Ta is the value used > for Ta is the value used for the" Should be "where Ta is the value used for the"... > 6. in section 4.6 "as defined in section in 6.7 in [RFC7401]:" change to "as > defined in section 6.7 in [RFC7401]:" Will fix this too. Should I post a new version with the suggested changes? From nobody Fri Mar 2 10:16:15 2018 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 625B012E8C1; Fri, 2 Mar 2018 10:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AvOFrcyMALvR; Fri, 2 Mar 2018 10:15:52 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 5337912E884; Fri, 2 Mar 2018 10:15:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CFBEB622A7; Fri, 2 Mar 2018 13:15:43 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z0j3goXdS3HE; Fri, 2 Mar 2018 13:15:39 -0500 (EST) Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 10D1762272; Fri, 2 Mar 2018 13:15:37 -0500 (EST) To: Qin Wu , ops-dir@ietf.org Cc: hipsec@ietf.org, draft-ietf-hip-dex.all@ietf.org, ietf@ietf.org References: <151937418915.22547.2306442974033264477@ietfa.amsl.com> From: Robert Moskowitz Message-ID: <1855cb41-2fce-e3c1-2fbd-0adf969ccb46@htt-consult.com> Date: Fri, 2 Mar 2018 13:15:35 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <151937418915.22547.2306442974033264477@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Hipsec] Opsdir last call review of draft-ietf-hip-dex-06 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: Fri, 02 Mar 2018 18:15:59 -0000 On 02/23/2018 03:23 AM, Qin Wu wrote: > Reviewer: Qin Wu > Review result: Ready > > Summary: > This document defines the Host Identity Protocol Diet EXchange (HIP > DEX) protocol for constrained devices. The draft is well written. I believe > it is ready for publication. > Major issue: None > Minor issue: Editorial > 1.It is not clear how fine-grained policy control defined in IKEv2 is different > from policy control defined in HIP DEX protocol? There is a long-standing difference in HIP to IKE policy. I am "shooting from the hip" a bit here, as it has been years since having this sort of discussion. For starters, HIP does not have policyu bound to an interface IP address. Then there is the nature of parameters in HIP DEX like the size of the cookie puzzle and how in some IOT cases, this can actually be used as an attack so policy may be used to manage this. Much is left to the implementer, it is true. > In the draft, local policies > are mentioned many times, however it is not clear what local policy for HIP DEX > Protocol looks like? To this I have to defer to Rene, who has implemented DEX... > Is it possbile to carry policy control parameters(e.g., > ACL parameter) in the HIP DEX protocol message? HIP has avoided negotiating policies, and thus carrying them in messages. I am working some drafts that does provide for limited policy control parameters. > Would it be great to provide > example to clarify this. 2. Is Nonce I same as radom value #I? 3. Is puzzle > difficulty K same as #K used in the HIP R1 described in section 7? 4. Is puzzle > difficulty K same as low-order #K bits of the RHASH? If the answer is yes, > please make the term and symbol used in the draft consistent. Good catch on this. I will check this over. Bob From nobody Sat Mar 3 23:23:18 2018 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 C51F7126FDC; Sat, 3 Mar 2018 23:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tN8FI_4BuYlT; Sat, 3 Mar 2018 23:23:10 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 1F8791241F5; Sat, 3 Mar 2018 23:23:10 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7BE8D2B0A58CA; Sun, 4 Mar 2018 07:23:06 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 4 Mar 2018 07:23:07 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Sun, 4 Mar 2018 15:22:59 +0800 From: "Roni Even (A)" To: Miika Komu , Roni Even , "gen-art@ietf.org" CC: "hipsec@ietf.org" , "ietf@ietf.org" , "draft-ietf-hip-native-nat-traversal.all@ietf.org" Thread-Topic: [Gen-art] Genart last call review of draft-ietf-hip-native-nat-traversal-27 Thread-Index: AQHTsWd46nuHzli77kintpr2h56DIaO/rmhQ Date: Sun, 4 Mar 2018 07:22:59 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD869DEA@DGGEMM506-MBX.china.huawei.com> References: <151965127608.31482.7946240138786040730@ietfa.amsl.com> <07dbd7e2-ad0b-8483-e181-b911f3b4a7ba@ericsson.com> In-Reply-To: <07dbd7e2-ad0b-8483-e181-b911f3b4a7ba@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Hipsec] [Gen-art] Genart last call review of draft-ietf-hip-native-nat-traversal-27 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, 04 Mar 2018 07:23:12 -0000 Hi Miika, All your responses are OK with me. As for posting a new version, I think it will be good to submit one with al= l the changes that came in the IETF LC Roni -----Original Message----- From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of Miika Komu Sent: Thursday, March 01, 2018 4:13 PM To: Roni Even; gen-art@ietf.org Cc: hipsec@ietf.org; ietf@ietf.org; draft-ietf-hip-native-nat-traversal.all= @ietf.org Subject: Re: [Gen-art] Genart last call review of draft-ietf-hip-native-nat= -traversal-27 Hi Roni, thanks for the detailed review! My comments are below. On 02/26/2018 03:21 PM, Roni Even wrote: > Reviewer: Roni Even > Review result: Almost Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area=20 > Review Team (Gen-ART) reviews all IETF documents being processed by=20 > the IESG for the IETF Chair. Please treat these comments just like=20 > any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-hip-native-nat-traversal-?? > Reviewer: Roni Even > Review Date: 2018-02-26 > IETF LC End Date: 2018-02-26 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: > The document is almost ready for publication as a standard track RFC >=20 > Major issues: >=20 > Minor issues: >=20 > 1. in section 4.2 "Gathering of candidates MAY also be performed by=20 > other means than described in this section. For example, the candidates = could be > gathered as specified in Section 4.2 of [RFC5770] if STUN servers are > available, or if the host has just a single interface and no STUN orD= ata > Relay Server are available." I did not see this a different ways sinc= e > section 3 says "The hosts use either Control Relay Servers or Data Re= lay > Servers (or other infrastructure including STUN or TURN servers) for > gathering the candidates." so STUN is mentioned also here. I suggest to remove the remark in parenthesis (or other infrastructure incl= uding STUN or TURN servers). Does this solve the issue? [Roni] Yes > 2. In section 4.6.2 "The connectivity check messages MUST be paced by=20 > the Ta value negotiated during the base exchange as described in=20 > Section 4.4. If neither one of the hosts announced a minimum pacing=20 > value, a value of 20 ms SHOULD be used." in section 4.4 the default valu= e is 50 ms? Good catch! I double checked this from the ICE spec, which defaults also to= 50 ms. So, I change the value to 50 ms also in section 4.6.2. [Roni] OK > 3. in section 5.4 what about "ICE-STUN-UDP 2" ; I assume it is n= ot > relevant but this is also the IANA registeration I think it makes sense to add the missing one as you suggest, but omit it f= rom the IANA registration since it is already registered for RFC5770. [Roni] OK > 4. In section 5.5 "The TRANSACTION_PACING is a new parameter" it is=20 > not new it is in RFC5770 You're right, I'll change this. [Roni]OK > 5. In section 5.10 "SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63"=20 > is the only new one. this also relates to section 7 that says that all=20 > error values in section 5.10 are new while the rest are in RFC5770.=20 > Also there is no mention in section 7 of which registry is used for the e= rror values. Good catch, I'll correct these and add the IANA registry. [Roni]OK > Nits/editorial comments: > 1. Expand SPI and LSI when first appear in the document >=20 > 2. in section 2 "the base of an candidate" should be "a candidate" >=20 > 3. In section 3 "so it is the Initiator may also have registered to a=20 > Control and/or Data Relay Server" maybe "so the Initiator may also=20 > need to register to a Control and/or Data Relay Server" >=20 > 4. In section 4.2 "However, it is RECOMMENDED that a Data Relay Client=20 > registers a new server reflexive candidate for each its peer for the=20 > reasons described" maybe "for each of its..." Thanks for spotting these, will fix as suggested. > 5. In section 4.2 I could not parse the sentence "where Ta is the=20 > value used for Ta is the value used for the" Should be "where Ta is the value used for the"... > 6. in section 4.6 "as defined in section in 6.7 in [RFC7401]:" change=20 > to "as defined in section 6.7 in [RFC7401]:" Will fix this too. Should I post a new version with the suggested changes? _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art From nobody Mon Mar 5 00:46:23 2018 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED3512E04F; Mon, 5 Mar 2018 00:45:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152023955727.27866.10043556777810233077@ietfa.amsl.com> Date: Mon, 05 Mar 2018 00:45:57 -0800 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-28.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 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: Mon, 05 Mar 2018 08:45:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol WG of the IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Authors : Ari Keranen Jan Melén Miika Komu Filename : draft-ietf-hip-native-nat-traversal-28.txt Pages : 62 Date : 2018-03-05 Abstract: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-28 https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-28 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 5 00:57:22 2018 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 142A812D893 for ; Mon, 5 Mar 2018 00:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 2GgdJGf0DCTA for ; Mon, 5 Mar 2018 00:57:11 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 CAE7212DA19 for ; Mon, 5 Mar 2018 00:57:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1520240229; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FQkJ1K6WNLV2V9oEeF7j2u3vD1NLuO145033ry3ruC0=; b=FSvpt+tHA+q3oweMr3oq6NsKjiy9JKXOefODMuWIHJNuZ8erT4qawif0F0jPik1x 3HS8UTuGihWOXPWW7vQ379Yk55O1XQq7xxbV2LO0dx+JxgpiEjHyS6c6Rn2oQtWZ PR8uOVkVBSktV8YMfo9kC09N2+nXl76eDGbLGy2zhYg=; X-AuditID: c1b4fb25-44ba69c000002d5f-ba-5a9d066441e4 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0F.B3.11615.4660D9A5; Mon, 5 Mar 2018 09:57:09 +0100 (CET) Received: from [131.160.50.242] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.352.0; Mon, 5 Mar 2018 09:56:25 +0100 To: "Roni Even (A)" , Roni Even , "gen-art@ietf.org" CC: "hipsec@ietf.org" , "ietf@ietf.org" , "draft-ietf-hip-native-nat-traversal.all@ietf.org" References: <151965127608.31482.7946240138786040730@ietfa.amsl.com> <07dbd7e2-ad0b-8483-e181-b911f3b4a7ba@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD869DEA@DGGEMM506-MBX.china.huawei.com> From: Miika Komu Organization: Ericsson AB Message-ID: Date: Mon, 5 Mar 2018 10:56:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD869DEA@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7h24q29wog2MfuSw2nd7DanH11WcW i6mLJjNbPNs4n8Xibzuzxadj51kc2Dx2zrrL7tFy5C2rx5IlP5kCmKO4bFJSczLLUov07RK4 Mm6+WcBe8FmtYvmcs4wNjCfluhg5OCQETCQ696p3MXJxCAkcZpT4Om0rO4SzmlHi+tM9rF2M nBzCAlESWw8+ArNFBMolFh5oZwIpYhbYzCjxsvM8C1z7ukd9bCBVbAJaEqvuXGcGsfkFJCU2 NOxmBlnHK2AvsXtfKEiYRUBF4vnsu0wgtqhAhETnyvksIDavgKDEyZlPwGxOgRCJzZcnsIPY zAIWEjPnn2eEsMUlbj2ZzwRhy0tsfzsHbLwQ0MyLx4InMArNQjJpFpLuWUi6ZyHpXsDIsopR tDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMB4ObvmtuoPx8hvHQ4wCHIxKPLwH/s6JEmJNLCuu zD3EKMHBrCTCW/YZKMSbklhZlVqUH19UmpNafIhRmoNFSZx3jnB7lJBAemJJanZqakFqEUyW iYNTqoFRNmMCk8QvuRMiy1iTrXVvd3TYq3tfPS60Um5uJbdPgdKVTud7Jq6Lgx7aT1H6fJOP 4Zaz78aoWfJ5u8NVjCL+aFWeWiU94e8f3ru2azq0eSPFvzA2nONhkC2OLtVhXOi0s5g9S8fz 2rsnK6QZ311+1DVj08N6PtNfNT97RDYaelmuWPrJj02JpTgj0VCLuag4EQAf9eT/gwIAAA== Archived-At: Subject: Re: [Hipsec] [Gen-art] Genart last call review of draft-ietf-hip-native-nat-traversal-27 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: Mon, 05 Mar 2018 08:57:21 -0000 Hi Roni, sorry, I read your email a bit too late today. I was too trigger happy and posted a new version... I thought it would be good to avoid blocking IANA with some missing and incorrect details. On 03/04/2018 09:22 AM, Roni Even (A) wrote: > Hi Miika, > All your responses are OK with me. > > As for posting a new version, I think it will be good to submit one with all the changes that came in the IETF LC > > Roni > > -----Original Message----- > From: Gen-art [mailto:gen-art-bounces@ietf.org] On Behalf Of Miika Komu > Sent: Thursday, March 01, 2018 4:13 PM > To: Roni Even; gen-art@ietf.org > Cc: hipsec@ietf.org; ietf@ietf.org; draft-ietf-hip-native-nat-traversal.all@ietf.org > Subject: Re: [Gen-art] Genart last call review of draft-ietf-hip-native-nat-traversal-27 > > Hi Roni, > > thanks for the detailed review! My comments are below. > > On 02/26/2018 03:21 PM, Roni Even wrote: >> Reviewer: Roni Even >> Review result: Almost Ready >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed by >> the IESG for the IETF Chair. Please treat these comments just like >> any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-hip-native-nat-traversal-?? >> Reviewer: Roni Even >> Review Date: 2018-02-26 >> IETF LC End Date: 2018-02-26 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: >> The document is almost ready for publication as a standard track RFC >> >> Major issues: >> >> Minor issues: >> >> 1. in section 4.2 "Gathering of candidates MAY also be performed by >> other means than described in this section. For example, the candidates could be >> gathered as specified in Section 4.2 of [RFC5770] if STUN servers are >> available, or if the host has just a single interface and no STUN orData >> Relay Server are available." I did not see this a different ways since >> section 3 says "The hosts use either Control Relay Servers or Data Relay >> Servers (or other infrastructure including STUN or TURN servers) for >> gathering the candidates." so STUN is mentioned also here. > > I suggest to remove the remark in parenthesis (or other infrastructure including STUN or TURN servers). Does this solve the issue? > > [Roni] Yes > >> 2. In section 4.6.2 "The connectivity check messages MUST be paced by >> the Ta value negotiated during the base exchange as described in >> Section 4.4. If neither one of the hosts announced a minimum pacing >> value, a value of 20 ms SHOULD be used." in section 4.4 the default value is 50 ms? > > Good catch! I double checked this from the ICE spec, which defaults also to 50 ms. So, I change the value to 50 ms also in section 4.6.2. > [Roni] OK > >> 3. in section 5.4 what about "ICE-STUN-UDP 2" ; I assume it is not >> relevant but this is also the IANA registeration > > I think it makes sense to add the missing one as you suggest, but omit it from the IANA registration since it is already registered for RFC5770. > [Roni] OK > >> 4. In section 5.5 "The TRANSACTION_PACING is a new parameter" it is >> not new it is in RFC5770 > > You're right, I'll change this. > [Roni]OK > >> 5. In section 5.10 "SERVER_REFLEXIVE_CANDIDATE_ALLOCATION_FAILED 63" >> is the only new one. this also relates to section 7 that says that all >> error values in section 5.10 are new while the rest are in RFC5770. >> Also there is no mention in section 7 of which registry is used for the error values. > > Good catch, I'll correct these and add the IANA registry. > > [Roni]OK > >> Nits/editorial comments: >> 1. Expand SPI and LSI when first appear in the document >> >> 2. in section 2 "the base of an candidate" should be "a candidate" >> >> 3. In section 3 "so it is the Initiator may also have registered to a >> Control and/or Data Relay Server" maybe "so the Initiator may also >> need to register to a Control and/or Data Relay Server" >> >> 4. In section 4.2 "However, it is RECOMMENDED that a Data Relay Client >> registers a new server reflexive candidate for each its peer for the >> reasons described" maybe "for each of its..." > > Thanks for spotting these, will fix as suggested. > >> 5. In section 4.2 I could not parse the sentence "where Ta is the >> value used for Ta is the value used for the" > > Should be "where Ta is the value used for the"... > >> 6. in section 4.6 "as defined in section in 6.7 in [RFC7401]:" change >> to "as defined in section 6.7 in [RFC7401]:" > > Will fix this too. > > Should I post a new version with the suggested changes? > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art > From nobody Mon Mar 5 08:11:01 2018 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 9D16E12D964 for ; Mon, 5 Mar 2018 08:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 R-KMdykIUubL for ; Mon, 5 Mar 2018 08:10:49 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 3C17112EB22 for ; Mon, 5 Mar 2018 08:10:13 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id f25so21232192qkm.0 for ; Mon, 05 Mar 2018 08:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dImOYBZ/jzpScMePEIT6j9OPCXJZCkHP+8aoV4+mmOA=; b=NAsHFI09AAhiMkD/yG9sIvT8jAV9f1XDTn07ixK6O/UKuFl1kmc45QUxjC6C/tWfBT CmLap8CR6EU2GAl55dwF2ComBJgedixeTBYGOQI0Kq20FdN/MaxK8MfxYlAy7w4YZo/G 1J4sa0w2o1i6dUxsMdDB6yD+mPmzrz+8HV9pQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dImOYBZ/jzpScMePEIT6j9OPCXJZCkHP+8aoV4+mmOA=; b=aPJ7x6CfGdClQjhvvk7AASxAOs2dLt/cAYpUs0ukaetqdaVsKEVgXVXcUCnuJacrLq /SzCvKJ1mnxDUWsxdq85ztyfha+TWRutkKUsga9ocX8Hm7IR6L+5+W2UfE6ZibJY+o4K s/XTCW1IrOu22OHLuHwH4xSdBwc6yMBX8VT/P9xmACdrs7zaAV5UmD/bs/CNU3l8B+a4 Xvt8Jcv6+jr45Vu9ZISrJtuoiDP6bVg7n7nyMchXnS3MgD/oiMdXe9ddszrHhRoe5/eq t1Cc5NhDeQPW38xxME5Zwh4rrYZdBUynltnLMtGEkuConAP98m1EVjOOTAZvd6mg3ujI Cjdg== X-Gm-Message-State: AElRT7HsSnS7jx9gSvf7uC56/K6uOrsOPskGBBVL1JHWI62nM0mjUD22 YPudZs4wW8SAlIjFv+GIsiZBNL/porw= X-Google-Smtp-Source: AG47ELtGFy1cgABAgr949wWLtbUmvoAJrgI7CenLy9T1osj+Og3VyGsKqVoRvOoaFIQRD9KmuKPjKQ== X-Received: by 10.55.153.3 with SMTP id b3mr21615233qke.65.1520266212308; Mon, 05 Mar 2018 08:10:12 -0800 (PST) Received: from [172.16.0.18] ([96.231.225.106]) by smtp.gmail.com with ESMTPSA id n29sm9516747qtf.18.2018.03.05.08.10.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Mar 2018 08:10:11 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <61df7006-3ce9-2929-b58d-af500fa40ea8@ericsson.com> Date: Mon, 5 Mar 2018 11:10:09 -0500 Cc: secdir@ietf.org, draft-ietf-hip-rfc4423-bis.all@ietf.org, hipsec@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <151974401093.28581.6727583492292312298@ietfa.amsl.com> <61df7006-3ce9-2929-b58d-af500fa40ea8@ericsson.com> To: Miika Komu X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Hipsec] Secdir last call review of draft-ietf-hip-rfc4423-bis-19 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: Mon, 05 Mar 2018 16:10:51 -0000 > On Feb 28, 2018, at 10:34, Miika Komu wrote: >=20 > Hi Sean, >=20 > On 02/27/2018 05:06 PM, Sean Turner wrote: >> Reviewer: Sean Turner >> Review result: Has Nits >> This is a bis draft of the HIP (Host Identity Protocol) Architecture = and >> because of that I focused on what=E2=80=99s changed (i.e., I reviewed = the diffs from >> = https://www.ietf.org/rfcdiff?url1=3Drfc4423&url2=3Ddraft-ietf-hip-rfc4423-= bis-18). >> It=E2=80=99s still HIP but with a slightly expanded scope; it=E2=80=99s= still Informational. >> 1. s4: The one place where I=E2=80=99ll step out from not looking at = the old is a >> similar-ish recommendation that was in the RF4423: >> In this document, the non-cryptographic forms of HI and HIP are >> presented to complete the theory of HI, but they should not be >> implemented as they could produce worse denial-of-service attacks >> than the Internet has without Host Identity. >> Should the should not be a SHOULD NOT? >=20 > I can change this for sure but the whole document is written without = the capitalized terms due to its informal nature... actually, this = sentence is a bit moot since non-cryptographic forms of HI are only = referenced in the text. I would suggest rephrasing this as follows: >=20 > "In this document, some non-cryptographic forms of HI and HIP are > referenced, but cryptographic forms should be preferred because they = are more secure than their non-cryptographic counterparts." >=20 > Would that work for you? Yep - works just fine. >> 2. (none security) s4.4: Is the paragraph about IPv4 vs IPv6 vs LSI = really >> necessary? I.e., is this yet another thing that folks are going to = use to not >> transition to IPv6? >=20 > I think the draft should discuss IPv4 compatibility because it is part = of architecture design. >=20 > Btw, do you mean this paragraph or something else? >=20 > The interoperability mechanism > should not be used to avoid transition to IPv6; the authors firmly > believe in IPv6 adoption and encourage developers to port existing > IPv4-only applications to use IPv6. However, some proprietary, > closed-source, IPv4-only applications may never see the daylight of > IPv6, and the LSI mechanism is suitable for extending the lifetime = of > such applications even in IPv6-only networks. >=20 > IMHO, the LSIs should be supported mainly for the sake of proprietary, = legacy applications which should be supported for backwards = compatibility. The next paragraph also mentions a limitation of the = LSIs: >=20 > The main disadvantage of an LSI is its local scope. Applications may > violate layering principles and pass LSIs to each other in > application-layer protocols. >=20 > Let me know if you would like change or emphasize something? No - I think after re-reading this the LSI is sufficiently poo-pooed to = not be something folks will want to use ;) >> 3. s11.2: Isn=E2=80=99t an additional drawback the need to have a = HIP-aware firewall? >=20 > Good point. It's both a benefit and drawback from the viewpoint of = firewalls. s11.1 mentions: >=20 > [...] First, the use of > HITs can potentially halve the size of access control lists > because separate rules for IPv4 are not needed [komu-diss]. > Second, HIT-based configuration rules in HIP-aware middleboxes > remain static and independent of topology changes, thus > simplifying administrative efforts particularly for mobile > environments. >=20 > As a drawback, I could add something like this to s11.2: >=20 > In the current Internet, firewalls are commonly used to control access = to various services and devices. Since HIP introduces a new namespace, = it is expected that also the HIP namespace would be filtered for = unwanted connectivity. While this can be achieved with existing tools = directly in the end-hosts, filtering at the middleboxes requires = modifications to existing firewall software or new middleboxes = [RFC6538]. >=20 > How does this sound? wfm Cheers, spt