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 | |
| Draft 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 | |
| Review |
review-ietf-6man-oversized-header-chain-08-secdir-lc-gondrom-2013-10-17
|
|
| 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