Early Review of draft-dunbar-armd-arp-nd-scaling-practices-07
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.
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?
Shouldn't it be possible to avoid ND load by proper setting of the ReachableTime variable?
-- This wouldn't require any protocol changes.
Snooping ARP packets probably means increased load (a disadvantage you didn't mention).
When address resolution is needed to deliver a packet, some routers just drop the packet
when they engage in ARP (see
). The same is true for
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
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"
Please expand UNA (possibly in the terminology section) -- you probably mean "Unsolicited..",
but this should be explicit.
secdir [mailto:secdir-bounces at ietf.org]
On Behalf Of
Friday, February 14, 2014 2:52 AM
secdir at ietf.org; iesg at ietf.org; draft-housley-pkix-oids.all at tools.ietf.org
[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.
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:
be related to X.509 certificate/be related to X.509 certificates/
In Section 3.1:
to points to this document/to point to this document/