Earlier, someone wrote:
> it's expensive because you have to set them aside and re-assemble
> and nd is going to be reassembled in a control-plane processor,
> which leads to cases where the attacker deliberately maximizes
> the expense associated with doing so.
For fragmented ND packets the above is clearly true for many
(most ?) implementations. So I totally understand the
motivation for disallowing fragmentation of ND packets.
I suspect that most folks agree with this subset of the
RA Guard I-D. Certainly I agree with this.
Banning all forms of the IPv6 Routing Header in ND packets
also seems reasonable, primarily because in all cases ND packets
ought to be bridged (i.e. via link layer methods) between
source and destination, rather than routed. So I also
suspect that most folks agree with this. Just to be clear,
I agree with this.
What I don't find convincing, and I gather some other folks
also don't find convincing, is Fernando's extrapolation that
any and all IPv6 extensions should be prohibited in ND packets.
The philosophy of the RA-Guard I-D seems to be "ban everything,
just in case it might be a problem later". I think that is
too strong a position and needlessly limits IPv6 evolution,
for little to no actual reduction of operational risk.
I propose to invert that philosophy to one where "known
serious risks" (e.g. Fragmentation Header, Routing Header)
are prohibited while other extensions are permitted.
In the special case of ND packets, the Hop-by-Hop Extension
Header has behaviour identical to the Destination Options Header
-- because there are no hops between source and destination.
As RFC-2460, Section 4.3 clearly shows, it IS possible for
a device functioning as an RA-Guard to parse *past* the
Hop-by-Hop header without knowing anything about its
contents (and without needing to know anything about its
contents). So in this case, the Hop-by-Hop Extension Header
does NOT have the problematic behaviours that it would have
in many other situation (e.g. the potential to DOS transit
routers simply does NOT exist for an ND packet because those
packets are *never* routed).
In particular, I believe that ND packets should be allowed
to have at least 1 instance each of the IPv6 Hop-by-Hop Options
Header, IPv6 Destination Options header, and IP Authentication
Header. In practice, such packets will be extremely uncommon.
The IPv6 packet design makes it computationally simple and easy
to move past that header to get to whatever payload is behind
(e.g. ICMPv6, TCP, UDP, SCTP). The incremental cost to a
low-cost CPU-based implementation to support this would be
incurred only on packets that contained one of these 3 IPv6
extension headers. The cost per extension header present
in the packet would be (roughly) to read 2 bytes extra
(i.e. the "Next Header" field in the extension header and
also the "Hdr Ext Len" field), and then add the value of
"Hdr Ext Len" that was just read to the packet pointer.
For all 3 of those IPv6 Extension Headers, those 2 bytes are
located in precisely the same place, eliminating a need for
per-extension special case code. This is a tiny amount
of code, with a tiny memory footprint, and would consume a
tiny amount of additional CPU instructions, so any device
that already is parsing into the IPv6 frame to perform the
RA-Guard checks could easily support the presence of these
extension headers.
While I realise most folks here already understand this,
I think it is really important for everyone to understand
that it is *impossible* to prevent Denial-of-Service attacks
in a useful network deployment. What can and should be done
is to find ways to increase the work function of the
attacker's least/less expensive attack vectors. The DoS
attackers (or at least the attack tool authors) are not
stupid and they are lazy, so operational experience
consistently has shown that they consistently deploy the
least expensive (to the attacker) viable DoS attack they can.
So I do not find Denial-of-Service attack concerns particularly
credible in the special case of "these 3 (DO, HbH, AH) extension
headers appearing in ND packets", because the attacker already
would have to be on-link to undertake an ND-oriented DoS attack.
An on-link attacker has *numerous* simpler, widely known, and
lower-cost-to-the-attacker ways of DoS'ing *any device* on that
same link.
[WELL KNOWN EXAMPLE: Perhaps the simplest on-link DoS attack
would be to flood a large number of link-layer broadcast frames.
Even if the receivers simply discarded the frames, such a flood
could be quite damaging to normal use of the network. Many many
other low-cost link-layer DOS attack vectors are widely known;
this is just a simple example.]
Yours,
Ran Atkinson
PS: Having a CALIPSO option (RFC-5570) in an ND packet is a real-world
use case, albeit an extremely uncommon kind of IPv6 deployment at
present. In an MLS network deployment, devices that have disjoint
authorised sensitivity-label ranges ought not be aware of each other.
This is easy to achieve by simply putting a CALIPSO option in all
IPv6 packets sent within the MLS network deployment. The receiving
MLS-enabled node will perform the CALIPSO label check early in the
ipv6_input() code, before either passing the packet up to the
next protocol xor dropping the packet as having an out-of-range
sensitivity label. Per the CALIPSO spec, the CALIPSO option is
ignored by nodes that don't support it.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
