Re: [Hipsec] Opsdir last call review of draft-ietf-hip-dex-06

Qin Wu <bill.wu@huawei.com> Sat, 23 March 2019 14:42 UTC

Return-Path: <bill.wu@huawei.com>
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 067401200ED; Sat, 23 Mar 2019 07:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 HeUFafJevakA; Sat, 23 Mar 2019 07:42:29 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A39AE127964; Sat, 23 Mar 2019 07:42:28 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id CC5A7BBE5067F41DCF77; Sat, 23 Mar 2019 14:42:26 +0000 (GMT)
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 23 Mar 2019 14:42:26 +0000
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Sat, 23 Mar 2019 14:42:26 +0000
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Sat, 23 Mar 2019 14:42:25 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.81]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Sat, 23 Mar 2019 22:42:18 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Miika Komu <miika.komu@ericsson.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: Robert Moskowitz <rgm@htt-consult.com>, "hipsec@ietf.org" <hipsec@ietf.org>, "draft-ietf-hip-dex.all@ietf.org" <draft-ietf-hip-dex.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [Hipsec] Opsdir last call review of draft-ietf-hip-dex-06
Thread-Index: AdThhkQ8j5sGnyHXQlKbzOsJJuf67g==
Date: Sat, 23 Mar 2019 14:42:18 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9B2FA0F3@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.220.65.93]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/PYdxJoMgKW-cPfQ00vK4Cu85Znk>
Subject: Re: [Hipsec] Opsdir last call review of draft-ietf-hip-dex-06
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Mar 2019 14:42:31 -0000

Thanks Miika and Robert for clarification, you clear my comments.

-Qin
-----邮件原件-----
发件人: Miika Komu [mailto:miika.komu@ericsson.com] 
发送时间: 2019年3月23日 22:34
收件人: Qin Wu <bill.wu@huawei.com>;; ops-dir@ietf.org
抄送: Robert Moskowitz <rgm@htt-consult.com>;; hipsec@ietf.org; draft-ietf-hip-dex.all@ietf.org; ietf@ietf.org
主题: Re: [Hipsec] Opsdir last call review of draft-ietf-hip-dex-06

Hi Qin,

I am stepping in and helping the authors to finalize this draft.

On 3/2/18 20:15, Robert Moskowitz wrote:
> 
> 
> 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.

https://tools.ietf.org/html/rfc7401#section-1.2

"The base protocol does not cover all the fine-grained policy control found in Internet Key Exchange (IKE) [RFC7296] that allows IKE to support complex gateway policies.  Thus, HIP is not a complete replacement for IKE."

>>   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...

RFC7401 lists some things relevant to local policies:

https://tools.ietf.org/html/rfc7401#page-106

The relevant ones are repeated also in HIP DEX:

https://tools.ietf.org/html/draft-ietf-hip-dex-06#section-7

>>   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.

agree with Robert, ACLs are not carried in HIP messages.

 >> Would it be great to provide example to clarify this.

Section 7 lists policy examples (please check my earlier comment).

>> 2. Is Nonce I same as radom value #I?

yes, it is the same. I added to section 2.3. Definitions:

    Nonce #I and #J:  Nonce #I and nonce #J refer to the corresponding
       fields in the PUZZLE parameter (see section 5.2.4 in [RFC7401].
       They are also referred as "random value #I and #J" in this
       document.

>> 3. Is puzzle difficulty K same as #K used in the HIP R1 described in section 7?

this is correct. I clarified in section 2.3 Definitions:

    Puzzle difficulty K:  The Initiator has to compute a solution for the
       puzzle.  The level of computational difficulty is denoted by the
       #K field in the puzzle parameter (see section 5.2.4 in [RFC7401].

and section 7 (#K is now without the hash):

  The value of puzzle difficulty K used
    in the HIP R1 must be chosen with care.  Values for the K that are
    too high will exclude clients with weak CPUs because these devices
    cannot solve the puzzle within a reasonable amount of time.  The K
    value should only be raised if a Responder is under high load, i.e.,
    it cannot process all incoming HIP handshakes any more.  If a
    Responder is not under high load, K SHOULD be 0.

>> 4. Is puzzle difficulty K same as low-order #K bits of the RHASH?

no, K is the #K field in the puzzle parameter (as now clarified in the Definitions). It refers is the number of bits that should be zero when calculating the puzzle solution from the RHASH as mentioned in section
5.3.3 in the DEX draft:

The low-order #K bits of the RHASH(I | ... | J) 

            MUST be zero.

>> 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.

I have now clarified the terms and their variants now in section 2.3, I hope this works for you?

Thanks for your comments and I hope this resolves your concerns!