Early Review of draft-dunbar-armd-arp-nd-scaling-practices-07
review-dunbar-armd-arp-nd-scaling-practices-07-secdir-early-tsou-2014-02-19-00

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 at ietf.org]

On Behalf Of

Matthew Lepinski

Sent:

 Friday, February 14, 2014 2:52 AM

To:

 secdir at ietf.org; iesg at ietf.org; draft-housley-pkix-oids.all at
 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/