All,
I have performed my initial AD review of this draft. The
following are my comments on the content. I am open to discussing these
in order to move this document forward...
Substantive
----------------
* It would be quite useful to explicitly define "atomic fragment" prior
to using it in the document. This could be done in the Introduction in
a formal manner and the use of "atomic fragments" in the Abstract can be
re-worded.
* The Introduction needs to provide more motivation as to why we should
allow these atomic fragments to exist. Please provide the rationale
discussed on the mailing list about how v4/v6 translators use the
fragmentation information.
* The core source of this attack is that some implementations have
predictable algorithms for generating the Fragmentation ID, allowing
attackers to launch these types of attacks. It would be good to
reference that work in this draft as well.
* What is the purpose of the indented paragraph within the first bullet
of the list in section 2? Is it a quote from one of the two referenced
RFCs?
* It is not clear to me why the document spends much time on discussing
ICMP-based attacks on the source of traffic, especially ones that ignore
existing RFCs, when the issue is really with devices that don't do the
right thing on the receiving end.
* I am rather disappointed with the Security Considerations section
given that this draft is addressing a perceived security vulnerability.
In fact, I would like to ask the WG if the solution actually creates
an attack vector on receiving hosts. An on-device path could modify
packets with Fragmentation headers by setting Offset=0 and M=0. This
would cause the receiver to blindly treat the packet as an atomic and
pass it up to the upper-layer protocol. Is this an acceptable risk?
Obviously, packets protected by IPsec would be immune to this attack.
At a minimum, the Security Considerations should spend some time
discussing the potential new attacks based on these rules.
Editorial
------------
- Abstract
* s/IPv6 specification allows/IPv6 specifications allow/
- Introduction
* s/[RFC2460] allowed/[RFC2460] allows/
* s/[RFC5722] forbid/[RFC5722] forbids/
* Provide a forward pointer to Appendix A in paragraph 4
Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
