[secdir] SecDir review of draft-ietf-core-http-mapping-15

zhangdacheng <dacheng.zhang@huawei.com> Wed, 12 October 2016 10:30 UTC

Return-Path: <dacheng.zhang@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CEBD4126D74; Wed, 12 Oct 2016 03:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.216
X-Spam-Status: No, score=-7.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LxbUHERQ9BKb; Wed, 12 Oct 2016 03:30:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9392A1294CA; Wed, 12 Oct 2016 03:30:54 -0700 (PDT)
Received: from (EHLO lhreml707-cah.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTA32919; Wed, 12 Oct 2016 10:30:52 +0000 (GMT)
Received: from SZXEMI404-HUB.china.huawei.com ( by lhreml707-cah.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Wed, 12 Oct 2016 11:30:51 +0100
Received: from SZXEMI502-MBX.china.huawei.com ([]) by SZXEMI404-HUB.china.huawei.com ([]) with mapi id 14.03.0235.001; Wed, 12 Oct 2016 18:30:48 +0800
From: zhangdacheng <dacheng.zhang@huawei.com>
To: secdir <secdir@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: SecDir review of draft-ietf-core-http-mapping-15
Thread-Index: AdIkcJXPoDb4VkyJR6aWZmojm3TBBQ==
Date: Wed, 12 Oct 2016 10:30:47 +0000
Message-ID: <879E76B64CF340468BF5E4DE504C2242C02004@szxemi502-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_879E76B64CF340468BF5E4DE504C2242C02004szxemi502mbxchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.57FE10DD.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4575ace9e52abcd0b1888d4264a279ae
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/VxSUquOfprpHtX24lh8_lPS7NMA>
Cc: "draft-ietf-core-http-mapping.all@tools.ietf.org" <draft-ietf-core-http-mapping.all@tools.ietf.org>
Subject: [secdir] SecDir review of draft-ietf-core-http-mapping-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Oct 2016 10:30:58 -0000


I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

I think this document is nearly ready for publication.

This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to CoAP.

The security considerations section is quite extensive. However, some contents in this section have not been well organized yet. The issues caused by lacking protection to multi-cast addresses has been discussed in sections 10.1, 10.2, 10.3, and 10.4. Same recommendation that requests to multicast resources are access controlled with a default-deny policy has been provided in both 10.1 and 10.4. I suggest to put the issues with multi cast into 10.1 and remove the redundant information in other places. In addition, it is a common method to deal with DoS attacks by limit the request rate. So, maybe it is worthwhile to mention this in section 10.2.