Last Call Review of draft-ietf-opsec-igp-crypto-requirements-
review-ietf-opsec-igp-crypto-requirements-secdir-lc-weiler-2010-09-15-00

Request Review of draft-ietf-opsec-igp-crypto-requirements
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-09-21
Requested 2010-08-25
Draft last updated 2010-09-15
Completed reviews Secdir Last Call review of -?? by Samuel Weiler
Assignment Reviewer Samuel Weiler
State Completed
Review review-ietf-opsec-igp-crypto-requirements-secdir-lc-weiler-2010-09-15
Review completed: 2010-09-15

Review
review-ietf-opsec-igp-crypto-requirements-secdir-lc-weiler-2010-09-15

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.






This is an informational document that appearently recaps requirement 


levels for implementation and use of crypto algorithms for hop-by-hop 


authentication of routing data.  Assuming that no requirements are 


being changed, I have no objections to the security considerations 


analysis, but I do have editorial comments.






I got lost as to the purpose of this doc.  Please reword the abstract 


and intro to make it clear that you're merely recapping requirements, 


not setting them (if that is indeed true).






Is there a way to present this information more compactly?  I suggest 


a table with routing protocol on one axis, crypto suite on another, 


and requirement status in the elements (perhaps with a cite to the doc 


that sets the requirement).  You might separely say "MANDATORY to 


implement, OPTIONAL to use, NOT SUGGESTED for use".






You could also put suggestions and speculation about the future in the 


same table, though you may need to define some terms.  And it needs to 


be clear when this doc diverges from past ones or makes a new 


statement.  I have not gone back through the previous docs to confirm 


that this doc isn't changing anything.






I see a whole bunch of lower case "may" and "should", and I'm 


wondering what to make of them.






In describing each routing protocol's authentication options, it would 


be helpful to say whether there's any in-band negotiation available. 


If so, more needs to be said about that in the security 


considerations.  If not, it should be documented here.






I don't need to hear three or four separate times that cleartext 


passwords are bad.




Minor: remove citations from the abstract (per rfc editor policy).

-- Sam