Le lundi 4 juin 2007, vous avez écrit : > In writing the I-D, I was not particularly concerned about Teredo > being used by malware on an internal host. The inbound direction was > more of a concern, e.g., Teredo opening opportunities for connecting > to a client that exceed what the administrator would want. I note that blocking all INBOUND UDP traffic FROM port 3544 effectively prevents from Teredo bubbles from doing hole punching, rendering unsolicited inbound through Teredo impossible, unless the host is behind a full cone NAPT (in which case it definitely is not in a security-sensitive perimiter). I maintain that any sane administrator of any vaguely sensitive network drops everything by default except a few known services, but if (s)he does not, blocking outbound packets with destination port 3544 and inbound UDP packets with source port 3544 is more than enough to make 100% sure Teredo will not work. There is zero need for deep packet inspection. Inspection would only make sense if you wanted to partially allow IPv6 traffic through Teredo, but I think we have consensus that Teredo must not be used in managed networks instead of native IPv6 (or ISATAP by default), so deep inspection is indeed really useless here, and there is no need to upgrade the firewalling software either. The I-D notes that blocking port 3544 might adversely affect other protocols. This has a very low probability, but technically is true nevertheless. However port 3544 is only ever used: - by the Teredo protocol, or - as a random ephemeral (source) port If the point of the firewall is to block incoming traffic, the outside port should ought to be a well-known one, while the inside port might be ephemeral. Hence blocking port 3544 from/to the "outside" is very safe. IMHO, if there is something to worry about w.r.t firewalling, Skype and HTTP/CONNECT are more like it. -- Rémi Denis-Courmont http://www.remlab.net/
Attachment:
signature.asc
Description: This is a digitally signed message part.