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

Request Review of draft-dunbar-armd-arp-nd-scaling-practices
Requested rev. no specific revision (document currently at 08)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2014-02-19
Requested 2014-02-13
Other Reviews
Review State Completed
Reviewer Tina Tsou
Review review-dunbar-armd-arp-nd-scaling-practices-07-secdir-early-tsou-2014-02-19
Posted at https://www.ietf.org/mail-archive/web/secdir/current/msg04611.html
Reviewed rev. 07 (document currently at 08)
Review result Has Issues
Draft last updated 2014-02-19
Review completed: 2014-02-19

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






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/