Hi, Ray, Thanks so much for your usual great feedback! -- Please find my comments in-line....
On 01/23/2015 07:54 AM, Ray Hunter wrote: > On the whole, this draft is already in a very good state. Thanks! > 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] Dumb question: Doesn't this imply that if you have e.g. issues with the WAN link you cannot even bootstrap your local nodes? > 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. I'm unsure regarding whether to include this as 3.1.2.*, or rather include a more general top-level section of snooping, which mentions DHCPv6 as a particular case -- e.g., ND snooping is another interesting case. Thoughts? > 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. I like the text you've suggested. My only observation would be: not sure why you mention /3.. Unless the attacker mens to "scan the whole IPv6 Internet (unlikely), he'l probably start with a /32 or /48... > 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. I'm not sure I followed the part "This then gives a hint...".. Would you mind elaborating a it? > 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. This makes sense. Now, since SNMP is also mentioned for the Neighbor Cache, I wonder how to include this info. -- e.g., keep the document "as is" and just add a top-level section entitled "Gleaning Information from network devices using SNMP" and have that section cover switch TCAM table, Neighbor Cache, routing table and others? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
