On the whole, this draft is already in a very good state.
I have some additional input for this draft
I think it's also useful to distinguish between on-link and on-net attacks.
New reconnaissance method:
3.1.2.1 Snooping of DHCPv6 relay packets
DHCPv6 deployment in enterprise networks often relies on one or more
centrally located DHCPv6 servers that serve the entire enterprise from
one or more highly-available sites.
Although the end host interacts with local on-link routers, these router
may forward the DHCPv6 requests over the WAN to the centrally located
DHCPv6 server(s) using DHCPv6 relay
[https://tools.ietf.org/html/rfc3315#section-7]
The relay packets are not encrypted and thus may be vulnerable to on-net
snooping, potentially allowing an attacker to leverage existing on-net
access to gain additional knowledge about remote LANs that they do not
yet have access to. Obtaining access to a DHCPv6 server would also be a
very high value target, and such servers should be tightly secured.
Some potential additional text for 3.2.1
> 3.2.1. Reducing the subnet ID search space
There are a number of documents available online e.g.
[http://www.ietf.org/rfc/rfc5375.txt
http://www.ripe.net/ripe/docs/ripe-552 ] that provide recommendations
for allocation of address space in the /3 to /64 range, which address
various operational considerations, including: RIR assignment policy,
ability to delegate reverse DNS zones to different servers, ability to
aggregate routes efficiently, address space preservation, ability to
delegate address assignment within the organization, ability to add
allocate new sites/prefixes to existing entities without updating ACLs,
and ability to de-aggregate and advertise sub-spaces via various AS
interfaces.
Some of the allocation databases may even be publicly searchable.
Allocation schemes may also be algorithmic e.g. simple incremental from
1 upwards, but also sparse allocation over a fixed bit range
[http://www.ripe.net/ripe/docs/ripe-343#3]
The net effect of these administrative policies is that the address
space from 2000/3 to the /64 prefix assigned to a LAN may be highly
structured, and allocations of individual elements within this structure
may be predictable once other elements are known. For example, if an
attacker assumes or knows that the address space contains a "region of 6
bits that is sparsely assigned" then region 1 =1 region 2 may be 32,
region 3 may be 16). This assumption may be easily tested with just a
few probes (e.g. by waiting for an ICMP unreachable reply from an
upstream router).
Thus the amount of entropy for this portion of the address search space
from /3 to /64 may be vastly reduced compared to uniformly random /64
allocations.
12. Obtaining Network Information with traceroute6
As well as using traceroute6 as a source of information, if an
organization allows ICMP unreachable messages from routers, an on-net
attacker could probe the subnet search space to gain knowledge of the
network structure, and thus the address assignment policy. For example,
if a large number of traceroutes, or indeed any other connection probe,
consistently generate a response with an ICMP unreachable Type 1 code 0
"no route to destination", all originating from a common router on the
path, this could indicate that this router is either a boundary router,
or a router that it performs route aggregation. This then gives a hint
of how the address space is structured for reducing the subnet ID search
space.
11. Gleaning Information from switch MAC tables and other equipment
using SNMP
If the underlying infrastructure is not properly secured, an attacker
can use knowledge gained from the switch TCAM forwarding table to learn
network structure, as well as MAC addresses in use in the network, which
can in many cases be mapped back to IPv6 addresses and machines.
Obviously SNMP and other management access should be secured.
--
Regards,
RayH
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
