100 likes | 118 Views
Teredo Security Concerns. draft-hoagland-v6ops-teredosecconcerns-01 Suresh Krishnan & Jim Hoagland. Classification of security concerns. Bypassing network security Inspecting contents of Teredo data packets Increased attack surface Guessable addresses due to structured addressing
E N D
Teredo Security Concerns draft-hoagland-v6ops-teredosecconcerns-01 Suresh Krishnan & Jim Hoagland
Classification of security concerns • Bypassing network security • Inspecting contents of Teredo data packets • Increased attack surface • Guessable addresses due to structured addressing • Misleading claims in RFC4380
Bypassing network security • Evasion by tunneling is a common problem • Firewall vendors need to add support for detunneling each tunneling protocol • Current firewalls may not be aware of the IP payload over UDP • Tunnel allows bidirectional traffic • Burden of filtering this traffic is shifted to the host • Bypasses ingress and egress filtering • Source routing past the Teredo host • Recommendations : • disable Teredo in managed networks • Prefer native IPv4 access to IPv6 Teredo • Perform ingress and egress filtering on all teredo packets • Clients to discard source routed packets
Content filtering of Teredo packets • Easy to filter Teredo signaling packets (connection requests) • Harder to filter the contents of Teredo data packets • Algorithm for deep packet inspection is complex • Recommendations: • In managed networks filter out Teredo connection requests • If the network wishes to monitor IPv6 traffic, discourage use of Teredo
Increased attack surface • Teredo creates NAT holes • Teredo NAT holes are usually open for a longer duration than a typical NAT hole • External IP address and port are visible in the Teredo address • Bubbles • Recommendations: • Restrict Teredo use to when it is required and turn it off otherwise.
Guessable addresses • Teredo addresses are predictable • Teredo prefix,server,flags,client port,client ipv4 address • Cone bit divulges the posture of the NAT and helps the attacker infer that he/she needs a bubble. • Recommendations: • Use random values in flags • Randomize Teredo service port on client • Deprecate cone bit
Misleading claim in RFC4380 • “Teredo improves security” • It does in some ways • But it makes security worse in some cases • Recommendation: • Remove such claims in teredo bis or qualify them
Teredo Deep Packet Inspection Algorithm • 1. The packet is not Teredo if it is not UDP over IPv4. • 2. Set T to the UDP payload offset. • 3. Set E to the end of the packet plus one. • 4. If E-T < 40 (the length of an IPv6 base header), the packet is not Teredo. • 5. If the octets starting with T are 0x0001 (an indication of authentication data), T= T+13 plus the lengths of the client identifier and the authentication value, assuming T is the start of authentication data. • 6. If E-T < 40, the packet is not Teredo. • 7. If the octets starting with T are 0x0000 (an indication of origin encapsulation), T= T+8. • 8. If E-T < 40, the packet is not Teredo. • 9. If the octets starting with T is 0x0000 or 0x0001, loop back to step 5. • 10. If the most significant nibble of the octet at T is not 6, the packet is not Teredo. • 11. Assuming T is the start of an IPv6 header, set L to value of the payload length field, S to the start of the source address, and D to the start of the destination address. • 12. If E-T != L+40, the packet is not Teredo. • 13. If neither S nor D start with 0x20010000 (the Teredo prefix), the packet is not Teredo. • 14. The packet is assumed to be Teredo, with the IPv6 header starting at T.
Address Format +-------------+-------------+-------+------+-------------+ | Prefix | Server IPv4 | Flags | Port | Client IPv4 | +-------------+-------------+-------+------+-------------+