[secdir] SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07

Tina TSOU <Tina.Tsou.Zouting@huawei.com> Sat, 15 February 2014 03:08 UTC

Return-Path: <Tina.Tsou.Zouting@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479371A0035; Fri, 14 Feb 2014 19:08:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level:
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
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 h_261O076idQ; Fri, 14 Feb 2014 19:08:02 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC501A001E; Fri, 14 Feb 2014 19:08:00 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD63210; Sat, 15 Feb 2014 03:07:57 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 03:07:33 +0000
Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 15 Feb 2014 03:07:54 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.63]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.03.0158.001; Sat, 15 Feb 2014 11:07:50 +0800
From: Tina TSOU <Tina.Tsou.Zouting@huawei.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-dunbar-armd-arp-nd-scaling-practices@tools.ietf.org" <draft-dunbar-armd-arp-nd-scaling-practices@tools.ietf.org>
Thread-Topic: SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07
Thread-Index: AQHPKfsc65F4O1ntVkqzN1q05nHFcA==
Date: Sat, 15 Feb 2014 03:07:50 +0000
Message-ID: <C0E0A32284495243BDE0AC8A066631A818119BA2@szxeml557-mbs.china.huawei.com>
References: <CANTg3aABqjC8QcrvQSs9ppYskLjWb9DJxqr0oMR2wMkQ_Xe_UQ@mail.gmail.com>
In-Reply-To: <CANTg3aABqjC8QcrvQSs9ppYskLjWb9DJxqr0oMR2wMkQ_Xe_UQ@mail.gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.87.91]
Content-Type: multipart/alternative; boundary="_000_C0E0A32284495243BDE0AC8A066631A818119BA2szxeml557mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Yo2yDjcuJbfLDaYVP0Byb9rZFlA
Subject: [secdir] SECDIR early review of draft-dunbar-armd-arp-nd-scaling-practices-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sat, 15 Feb 2014 03:08:05 -0000

Dear  all,
I have reviewed this document as part of the security directorate's ongoing effort to for early review of WG drafts.  These comments were written primarily for the benefit of the security area directors.  Document editors and working group chairs should treat these comments just like any other comments.

Section 1:
Please expand ToR upon first occurrence.

Section 2, page 3/4:
Could you please clarify the difference between "node" and "end station"? Are they synonyms?


Section 5.1.1:

Shouldn't it be possible to avoid ND load by proper setting of the ReachableTime variable? -- This wouldn't require any protocol changes.


Section 5.1.1:

Snooping ARP packets probably means increased load (a disadvantage you didn't mention).


Section 5.1.1:

When address resolution is needed to deliver a packet, some routers just drop the packet when they engage in ARP (see http://tools.ietf.org/html/rfc6274#section-4.2.3). The same is true for
IPv6 ND.


Section 8:

While this document does not introduce new issues itself, it should at least mention how the same ARP/ND issues may be intentionally triggered by an attacker. For example, you may reference RFC 6583


* Nits

Section 4, page 4:
> There are no address
>    resolution issue in this design.

Replace "issue" with "issues"


Section 5.1.1, page 5:

"Ipv6" -> "IPv6"


Section 5.1.2:

Please expand UNA (possibly in the terminology section) -- you probably mean "Unsolicited..", but this should be explicit.


Thank you,
Tina

From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Matthew Lepinski
Sent: Friday, February 14, 2014 2:52 AM
To: secdir@ietf.org; iesg@ietf.org; draft-housley-pkix-oids.all@tools.ietf.org
Subject: [secdir] SECDIR review of draft-housley-pkix-oids

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 working group chairs should treat these comments just like any other last call comments.

This document returns control of the PKIX object identifier arc to IANA. That is, it establishes a new IANA registry for OIDs in the PKIX arc and populates that registry with the existing OID assignments. Finally, the document establishes expert review as the criteria for future additions to the registry and includes guidance that for review.

After reviewing the document, I agree with the author that this document introduces no new security concerns.

I found no issues in the document and I believe it is ready for publication.

-------------------------------

Nits

The author should consider including an expansion of the acronym SMI, which is used frequently in the document. (I believe in this context SMI = Structure of Management Information)

In Section 3:
s/be related to X.509 certificate/be related to X.509 certificates/

In Section 3.1:
s/to points to this document/to point to this document/