Last Call Review of draft-ietf-6man-deprecate-atomfrag-generation-06
review-ietf-6man-deprecate-atomfrag-generation-06-secdir-lc-wierenga-2016-08-19-00

Request Review of draft-ietf-6man-deprecate-atomfrag-generation
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-08-22
Requested 2016-08-11
Authors Fernando Gont, Will LIU, Tore Anderson
Draft last updated 2016-08-19
Completed reviews Genart Last Call review of -07 by Joel Halpern (diff)
Intdir Early review of -06 by Carlos Bernardos (diff)
Intdir Early review of -06 by Ted Lemon (diff)
Secdir Last Call review of -06 by Klaas Wierenga (diff)
Assignment Reviewer Klaas Wierenga 
State Completed
Review review-ietf-6man-deprecate-atomfrag-generation-06-secdir-lc-wierenga-2016-08-19
Reviewed rev. 06 (document currently at 08)
Review result Ready
Review completed: 2016-08-19

Review
review-ietf-6man-deprecate-atomfrag-generation-06-secdir-lc-wierenga-2016-08-19




Hi,
















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.











Note: I noticed that there is also a version 07, and i have looked at that. My comments pertain to both versions.














IPv6 allows for specifying ‘atomic fragments’, where the packet is not really fragmented but the ‘fragmented’ header is to indicate that on the path there are network elements in the path that have an MTU size below the mandatory minimum of 1280 for IPv6 (for
 example IPv4/IPv6 translators). According to draft-ietf-6man-deprecate-atomfrag-generation-06 this introduces security risks, and has no benefits, and therefore proposes to remove atomic fragments from IPv6.














I am not at all an IPv6 expert, so my comments may not be valid and feel free to ignore them. But I can’t help thinking that much of the motivation for removal of this feature is in the fact that implementations misbehave. I find that a weak argument. Not being
 an expert, I can not judge well whether removing the feature is harmless, but I would be very cautious with removing extension headers for that reason. 














Fragmentation in itself is an attack vector, but I don’t understand why that is more of a problem with atomic fragments, apart from the aforementioned implementation errors.














Apart from that, I see no glaring security issues, so if there is broad consensus in the WG that this is the right thing to do, I consider the document ready.














Klaas














  










-- 


Klaas Wierenga


Identity Architect




Cisco Cloud Services