Last Call Review of draft-ietf-6man-oversized-header-chain-08
review-ietf-6man-oversized-header-chain-08-secdir-lc-gondrom-2013-10-17-00
Request | Review of | draft-ietf-6man-oversized-header-chain |
---|---|---|
Requested revision | No specific revision (document currently at 09) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2013-10-16 | |
Requested | 2013-10-03 | |
Authors | Fernando Gont , Vishwas Manral , Ron Bonica | |
I-D last updated | 2013-10-17 | |
Completed reviews |
Genart Last Call review of -08
by Peter E. Yee
(diff)
Genart Telechat review of -08 by Peter E. Yee (diff) Secdir Last Call review of -08 by Tobias Gondrom (diff) |
|
Assignment | Reviewer | Tobias Gondrom |
State | Completed | |
Request | Last Call review on draft-ietf-6man-oversized-header-chain by Security Area Directorate Assigned | |
Reviewed revision | 08 (document currently at 09) | |
Result | Ready | |
Completed | 2013-10-17 |
review-ietf-6man-oversized-header-chain-08-secdir-lc-gondrom-2013-10-17-00
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 ust like any other last call comments. This ID is Standards Track and and updates RFC 2460 such that the first fragment of a packet MUST contain the entire IPv6 header chain. The security considerations section is good. In fact the whole draft's objective is to solve a potential security problem with super-large IPv6 header chains and enable reliable stateless packet filtering for IPv6. COMMENTS: 1. A question, less from a security, but interoperability perspective: is there any deplyoment data on any potential backwards compatibility issues with current IPv6 deployments? Namely are there noteworthy deployments with large IPv6 header chains beyond the first fragment currently in deployment? 2. section 5 third paragraph: I wonder whether we should be more strict and replace the "MAY" with a "SHOULD"? This would make intermediate behavior consistent with the host from the previous paragraph and should avoid inconsistencies within the network topology? Best regards, Tobias