On 13-Jun-2007, at 04:53, Thomas Narten wrote:
On the whole, looks pretty good.
Abstract
The functionality provided by IPv6's Type 0 Routing Header can be
exploited in order to achieve packet amplification for the
purposes
of generating denial-of-service traffic. This document updates
the
IPv6 specification to deprecate the use of IPv6 Type 0 Routing
Headers, in the light of the severity of this security concern.
The "amplification" terminology seems imprecise/wrong. When I think of
amplification attacks, I think of one packet causing more packets to
be generated or one packet resulting in a bigger response. I.e., there
is amplification of the amount of data sent. In case at hand, packets
are not amplified, they are just routed in a sort of loop. Is there
more precise terminology that could be used? (Then again, maybe this
particular terminology is already widely used here.)
How about if I say "traffic amplification over a remote path" instead
of "packet amplification"?
The functionality provided by IPv6's Type 0 Routing Header can be
exploited in order to achieve packet amplification for the
purposes
of generating denial-of-service traffic. This document updates
the
Seems like a sentence or two describing the exploitation itself would
be good. Not a lot of detail, but more than just "it can be
exploited". (Later, I see that you include such text in the security
considerations section. I think it should be moved to (or included in)
the beginning of the document.
Would a forward reference to the Security Considerations section be a
reasonable compromise?
4.2. Packet Filtering
Firewall policy intended to protect against packets containing RH0
should be constructed such that routing headers of other types
(which
may well have legitimate and benign applications) are handled on
their own merits. For example, discarding all packets with any
type
of routing header simply as a reaction to the problems with RH0 is
inappropriate, and may hamper future functionality designed using
non-type 0 routing headers. For example, Mobile IPv6 uses the
type 2
Routing Header [RFC3775].
The next to last sentence is a bit weak. Dropping all packets with
routing headers will flat-out break MIPv6. If routers/firewalls start
doing that, that would be very bad. From a standards perspecive, we
should clearly flag that as bad/non compliant.
If I understand your point, you are happy with the meaning of this
section but wish that it made its point more forcefully.
From other comments on previous revisions of this document, people
expressed concern over whether normative language had any place in
descriptions of operational practice (as opposed to protocol
implementation). As such it's not clear to me whether MUST NOTs in
this section would have any teeth.
How about replacing "hamper" with something stronger ("defeat"?
"break"?) If you have other suggestions for text, I would be happy to
see them.
Where filtering capabilities do not facilitate matching specific
types of Routing Headers, filtering based on the presence of any
Routing Headers on IPv6 routers, without explicitly checking the
Routing Header type, is strongly discouraged.
Again, this is too weak, IMO. "strongly discouraged" is not the same
as "don't do that". It should be clear that from a standards
perspective that that sort of filtering is non-compliant.
I wonder again about normative language being applied to operational
practices, and would appreciate enlightenment.
How about adding a sentence which is a little more blunt, along the
lines of "filtering routing headers indiscriminately, without regard
to type, will seriously impair future extensions of the IPv6 protocol
which make use of Routing Headers"? Other suggestions?
8.1. Normative References
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
Shouldn't this reference be informative?
The document states that it update RFC4294 in section 1, so I
presumed that reference needed to be normative.
Joe
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
