IPv6Samurais.com: OpenBSD-current IPv6 audit

$Id: index.html,v 1.3 2007/09/06 14:32:14 itojun Exp $

Project overview

The result will be fed back into KAME tree, and then all the BSD communities/ commercial users.

Terminology

• nodes: devices that implement and speak IPv6.
• routers: nodes that would forward packet which has an IPv6 address in destination address field in IPv6 header, which is different from IPv6 address that is assigned to that device.
• hosts: nodes that are not routers.

The issues and results

2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4

2.1. IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 5

2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5

• Issues with Routing Header Type 0 was addressed around April 22, 2007. OpenBSD implements most paranoid approach to combat this problem: every node (not even a router) drops packets with rthdr0, and there is no sysctl(8) knob to turn rthdr0 processing to come back.
• Therefore, OpenBSD does not implement any of routing headers at this point. Therefore, there is no code that handles rthdr2.
• OpenBSD do respond with ICMPv6 parameter problem if it sees unknown routing header type (including rthdr0/2), but ICMPv6 errors are rate-limited so there is certain amont of protetion against DoS attacks. This behavior has no amplification (1 ICMPv6 error packet per 1 packet with unknown rthdr type).

2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6

• See above.

2.1.3. Site-scope Multicast Addresses . . . . . . . . . . . . 7

• An OpenBSD node does not join site-scope multicast by default, and an OpenBSD router does not run multicast routing protocol by default.
• For the attacks described in this section to be successful, (1) the site network has to have working multicast routing infrastructure, and (2a) the site network border is misconfigured so that it would pass IPv6 packets with site-local destination address into the site network, or (2b) there is some machine which acts as a "hole" which invites IPv6 packets with site-local destination address into the site network (such as Teredo-enabled machine or IPv6-enabled VPN gateway).
  (2b) would be a big problem which needs a careful study.

2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7

• The problem described in this section is real, and it is a bit difficult to combat against. OpenBSD can enable uRPF using PF (xxx need checking), but beyond that, it would be difficult.
• One approach might be to limit the size of worldwide/site-scope multicast packet to be smaller than certain size. However, this would need an IETF consensus or two.

2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8

• This section is about TCP behavior against spoofed ICMPv6 error packets. The OpenBSD behavior is documented in "Network Randomness in OpenBSD" near page 12. The draft suggests stateful inspection in firewalls, however, due to the complexity and the amount of states that would be created at the firewalls, it would be better to use OpenBSD way of TCP protection for all of the machines in a particular site.

2.1.6. Anycast Traffic Identification and Security . . . . . 9

• The draft is written under IETF's confusion about anycast address. The clarification is provided in draft-ietf-ipngwg-ipv6-anycast-analysis-01.txt. But with the recent "IPv6 addressing architecture" document, the limitation on the use of IPv6 anycast address as the source in RFC2373 anycast was lifted. So there's no real point in fighting against it...
• OpenBSD implements RFC2373 anycast with ifconfig(8) "anycast" flag. which translates into IN6_IFF_ANYCAST. This has no use any longer. (xxx need to update manpage)
• The draft talks about disclosure of network topology information if an unicast source address is used for a response to anycast queries. The impact of this is a bit questionable, given that you can run traceroute6(8) or whatever to probe for the topological information.
• The paragraph on subnet-router anycast address is a non-issue, given that scoped routing is working properly. OpenBSD do implement scoped routing properly.

2.1.7. Address Privacy Extensions Interact with DDoS Defenses . . . . . . . . . . . . . . . . . . . . . . . 10

• OpenBSD does not implement RFC3041 and variants. A separate document provides reasoning behind this decision.

2.1.8. Dynamic DNS: Stateless Address Auto-Configuration, Privacy Extensions and SEND . . . . . . . . . . . . . 10

• OpenBSD does not implement RFC3041 nor SEND. So that leaves only stateless address autoconfiguration to our table.
• OpenBSD does not implement interactions with dynamic DNS and stateless address autoconfiguration at this point of time. We are not aware of programs that would achieve this effect, maybe there are. The issue described in this section is basically an issue of trust information distribution (scalability) with dynamic DNS, nothing more.

2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11

• Let me remind you that Masataka Ohta has been saying that we should have upper-limit on the total size of headers (including the base IPv6 header and extension headers), like 256 bytes, so that even links under 1280 bytes we can ensure we have 1024 bytes of payload. You know, he does not know how to deliver his message to the IETF, he almost always push the wrong button on people, but he is, in many cases, right. Dig up ipv6wg archive and get surprised.

2.1.9.1. Processing Extension Headers in Middleboxes . . . . 11

• The section shows conflicting views of the IETF documents. RFC2460 and other IPv6 standard documents describe normal IPv6 nodes, i.e. routers are expected to forward packets, that's all. The draft talks about middleboxes that need to inspect the internals of the packet to enforce certain "policy" onto the packet, like firewalls.
• Of course, RFC2460 does not describe what kind of behavior middleboxes should implement. The implementers of those middleboxes has to read documents really carefully, so that implementations would not harm future protocol developments and enhancements.
• To respond to the question on page 11. To quote: "A further ambiguity relates to whether an intermediate node should discard a packet that contains a header or destination option which it does not recognize." My answer would be, of course, middleboxes HAVE TO let it go through, since end nodes may have implemented some protocol that middleboxes does not recognize! Of course I understand the desire from some network administrators who wants to ban any new protocol that they are not aware of, but, hey, get real, you cannot really control what kind of protocol people are running! Remember "end-to-end principle".
• For what matters to OpenBSD, PF implements full depth inspection of IPv6 packets. sys/net/pf.c:pf_test6() function do go through all the extension headers.

2.1.9.2. Processing Extension Header Chains . . . . . . . . . 12

• The problem described in the section is, of course, present, if you implement some middleboxes to apply "policy" against packets that go through, and that is not a simple router.
• Maybe we could have IETF/ipv6wg consensus to make IPv6 option header format be uniform to fit certain style. However, it is a bit too late: AH is already different in the way we need to compute the option header length.
• For what matters to OpenBSD, PF parses option header it knows about, and consider it is a "final" header if it sees something unknown to it. A user can still configure PF rules to check and allow/deny traffic based on protocol number on the option header, but no further inspection is allowed.

2.1.9.3. Unknown Headers/Destination Options and Security Policy 12

• Same story as 2.1.9.1 and 2.1.9.2. Not sure why it needs to be separate.

2.1.9.4. Excessive Hop-by-Hop Options . . . . . . . . . . . . 13

• It may be feasible to limit the number of hop-by-hop option headers on a single packet, maybe "at most 1", as the sender can put as many hop-by-hop options as needed into a single hop-by-hop option header. However, since it is permitted to put as many hop-by-hop option headers as needed in a single packet, some naive implementation may choose to put many hop-by-hop option headers as needed.
• We do not want to see an incident like rthdr0 again, of course, so we need some consensus on this, quickly.
• As for OpenBSD, we have upper limit for the number of total extension headers in a packet (net.inet6.ip6.hdrnestlimit, the default value is 10) but we do not enforce any limit on the number of simultaneous hop-by-hop option headers. Maybe we should.
  Proposed diff (not really tested but should work fine, not spec conformant)
• For more discussion on this topic, check out draft-krishnan-ipv6-hopbyhop-01.txt too.

2.1.9.5. Misuse of Pad1 and PadN Options . . . . . . . . . . 13

• The issue with covert channel is pretty popular. There is nothing new.
• The issue with PadN with strange size may be worth checking, but it is actually sometimes useful to alter packet size just like "random sized" padding in IPsec.
• As for OpenBSD, there is no code to log/control traffic with weird PadN options. OpenBSD does not check the content of PadN option. Not sure if it is the right thing or not, but it should not be critical.

2.1.9.6. Overuse of Router Alert Option . . . . . . . . . . . 14

• It is fairly common. Routers has to cope with high volume traffic with of Router Alert option, that's all.
• As for OpenBSD, there's no distinction between fast path and slow path. Packets with router alert option goes to normal input path on an OpenBSD router. What kind of processing load it would impose on an OpenBSD router depends on the upper-layer protocol layout the packet has.

2.1.10. Fragmentation: Reassembly and Deep Packet Inspection . . . . . . . . . . . . . . . . . . . . . . 14

• The draft has some points, but the problem is certainly not news to us. A possible approach would be to set the minimum size for non-terminal fragments to be 1280 bytes (larger fragments are okay). Even in the cases with links with weird scatter-and-gather which requires RFC2460 page 25 behavior (the last paragraph of section 5) we already have the fragment option header so we do not need to do anything. It needs an IETF consensus or two.
• As for OpenBSD, (1) PF does not reassemble IPv6 fragments so inspection would still be a problem, we need to improve this, and (2) in sys/netinet6/frag6.c we reject fragments if it overwraps, so we may be a bit too paranoid but we can avoid issues with overwrapping framgents. For the latter, malicious party may be able to inject overwrapping fragments and mount a kind of DoS attack, however, it is fairly common issue for all of the stacks and we should be able to prevent this by using pseudo-random numbers for fragment IDs, just like OpenBSD does.

2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15

• Again, just like mentioned in 2.1.10, a possible approach would be to set the minimum size for non-terminal fragments to be 1280 bytes (larger fragments are okay). The draft suggests 640 bytes, maybe it is safe to enforce it even without IETF consensus, but of course we cannot be sure about minimal IPv6 implementations out there which would create weird fragments.

2.1.12. Link-Local Addresses and Securing Neighbor Discovery . . . . . . . . . . . . . . . . . . . . . . 15

• While agreeing on the problems described in the section, this is a bit pointless to talk about the theft of bandwidth. If an attacker gets associated with the wireless link, or has access to the wired ethernet link, then he can abuse it no matter what kind of protection you have - the only protection you may be able to have is to authenticate the source MAC address at the wireless base stations and/or switches. It can be EtherTalk, DECNet, whatever. It even does not have to be a registered ethernet protocol type, it just has to be a random number which goes through the wireless base station /ethernet switch!
• OpenBSD of course implements link-local addresses. Handling of link-local addresses are embedded into getaddrinfo(3) and getnameinfo(3) API. If people uses those APIs, they can automatically handle IPv6 scoepd address notation such as ff02::1%fxp0. If people uses struct in6_addr directly, they will be in a serious trouble.

2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17

• My guess is that it would be better if we can implement filtering within layer 2 device - just like limiting DHCP server/relay agent from showing up on particular ethernet switch ports. With SEND administrators will face a kind of boot strap problem where they needs to distribute certificates of all of the routers within the campus/corporate - note that it is fairly normal for a computer to move from one link to another.
• OpenBSD does not, and I guess it will not, implement SEND.

2.1.14. Host to Router Load Sharing . . . . . . . . . . . . . 18

• I have difficulty understanding what the section is talking about... Is there stronger impact than normal attacks to routers?
• OpenBSD does not implement RFC4311. OpenBSD picks a single outgoing default router when it gets multiple RAs, and then switches the default router when some event happens - such as an unreachability detected for the previously-selected default router.

2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18

• OpenBSD does not implement mobile-ipv6.

2.1.15.1. Obsolete Home Address Option in Mobile IPv6 . . . . 18

• OpenBSD does not implement mobile-ipv6, nor old version of mobile-ipv6 draft proposals.

2.2. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 18

• See draft-cmetz-v6ops-v4mapped-api-harmful-01.txt and draft-itojun-v6ops-v4mapped-harmful-02.txt for detailed discussions. Actually the section of the draft is taken from those two drafts mentioned in the above.
• OpenBSD does not implement SIIT. OpenBSD does not implement "IPv4 packet on top of AF_INET6 sockets using IPv4 mapped address". OpenBSD /etc/netstart script installs reject routes for ::ffff:0.0.0.0/96 to avoid any of the bounce attacks that may be mounted by malicious parties. OpenBSD rejects traffic with IPv4 mapped address in various places: TCP/UDP code, IPv6 pcb handling, IPv6 input, raw IPv6 socket code, and routing header code.
• Still, malicious parties can use OpenBSD boxes to generate traffic with fabricated source address - using BPF writes. To do this malicious parties have to obtain root privilege on the box, either by hijacking the machine (unlikely) or installing the OpenBSD box on their own (noone can stop this).

2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20

• First of all, security mechanisms using IP address access limitation should go away. Operating systems has to be implemented so that it will not be affected by address scanning and/or TCP/UDP port scanning attempts. To achieve this OpenBSD has been implementing special measures in protocol implementation.

2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20

• Transparency achieved through the deployment of IPv6 is not a bad thing - we just have to correct the worng model believed by people. NAT box is a single point of failure. It limits scalability down to the table size limitation of the NAT mapping table. Redundant NAT boxes reduces NAT's MTBF in total so you won't be able to scale it by having more boxes.

2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 20

• All of the myth of security from filtering, address-based access control and NAT seem very bogus when we think about OpenBSD-style "secure by default" technology. We do not need to care about being port-scanned at all, for instance. OpenBSD-style security would be the model we need to pursue when we think about IPv6 security. We do not need to backport IPv4-style goos.

2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22

• The topic is not new. IPv4-over-IPv4 tunnel has the same property.

3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 22

3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . . 22

• The entire issue presented here is documented in draft-itojun-ipv6-transition-abuse-01.txt.
• OpenBSD PF may need to be extended so that it can inspect packets with multiple encapsulations.

3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23

• OpenBSD does not implement any of the automatic tunnelling technology. Because of the security implication, OpenBSD does not import KAME stf(4) interface code on purpose.

3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4 Network Security Assumptions . . . . . . . . . . . . . . . 24

• This problem not specific to OpenBSD.
• OpenBSD PF cannot filter Teredo traffic. Some may want this functionality, some may not. This would be a bit difficult as Teredo tries its best to punch hole in NAT. Existing solutions are (1) use TCP relay-based firewalls instead of per-packet NAT, or (2) to deploy IPv6 in the enterprise to disable Teredo on clients.

4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 25

4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 25

• The problem presented here are basically saying "we need every tool for IPv6 otherwise we will not migrate". It is not a technical discussions.

4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 27

• We cannot really help broken DNS server implementation.

4.3. Addressing Schemes and Securing Routers . . . . . . . . . 27

• Security through address block-based filtering is bogus.

4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 27

• OpenBSD does not implement RFC3041 and variants. A separate document provides reasoning behind this decision.

4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 28

• It is a bad practice to drop ICMP packets.

4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 29

• The section talks about covert channel using ICMPv6. The problem is not new.

4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 29

• IPsec protects end-to-end traffic, and it is impossible for firewalls to police it. It is just like https traffic. Get real. It is impossible from the start.

4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 30

• It does not apply to OpenBSD. In fact, small devices are getting much more computing power and are likely to run BSDs, so there's no issue.

4.8. Operational Factors when Enabling IPv6 in the Network . . 30

• Problem with implementation maturity is chicken-and-egg issue: if noone tests it it will never go mature.

4.9. Security Issues Due to Neighbor Discovery Proxies . . . . 31

• ND proxy is simply evil, we should just prevent it, that is all.

5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31

6. Security Considerations . . . . . . . . . . . . . . . . . . . 31

7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31

8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8.1. Normative References . . . . . . . . . . . . . . . . . . . 32

8.2. Informative References . . . . . . . . . . . . . . . . . . 33

Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 36

Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 37

B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 37

B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 38

B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 38

Contact

We would love to see someone to fund this project.