So,still assuming the fact that attackers will use the same "traditional ipv4" methods to alter the correct functioning over a network?...Well, maybe. Toda's IPv6 expertise for some network andmins and security experts is minimal. So most trainning and understanding before implementing its a good idea. For example, the RA-Guard method has a significant vulnerability: It's not designed to identify a "complex" IPv6-many extension headers formed packet (F. Gont - 6Networks). Some other security oriented mechanisms may fail because of the low IPv6 compliance. Regards. -- Daniel Espejel Pérez Técnico Académico D.G.T.I.C. - U.N.A.M. GT-IPv6 CLARA / GT-IPv6 U.N.A.M.
I think of RA Guard as a Layer-2 stability feature, rather than a security feature. You're correct that it is unable to deal with RA crafted in a fragmented packet on the majority (if not all) of implementations. The issue of rogue RA exists on every network, regardless of whether or not the IT group has deployed IPv6 or is aware of the IPv6 traffic on that network. Windows ICS is the most common "accidental" cause of rogue RA on a LAN. On Mon, Dec 5, 2011 at 10:35 PM, Daniel Espejel <daniel.unam.ipv6@gmail.com> wrote:
So,still assuming the fact that attackers will use the same "traditional ipv4" methods to alter the correct functioning over a network?...Well, maybe. Toda's IPv6 expertise for some network andmins and security experts is minimal. So most trainning and understanding before implementing its a good idea.
For example, the RA-Guard method has a significant vulnerability: It's not designed to identify a "complex" IPv6-many extension headers formed packet (F. Gont - 6Networks). Some other security oriented mechanisms may fail because of the low IPv6 compliance.
Regards.
-- Daniel Espejel Pérez Técnico Académico D.G.T.I.C. - U.N.A.M. GT-IPv6 CLARA / GT-IPv6 U.N.A.M.
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Well, as a stability feature may work if better understanding of the internet protocols is given to all the network specialist (almost a paradox, all those documents are free to be checked for all the people). Of course, the problem with the rogue IPv6 packets and "malformed" packets will exists as long as IPv6 is being deployed wide spread, and the proposed mechanisms on how to deal with those problems is, as it seems, a passion for some guys, and a job for other ones, but always thinking on the Internet growth is the main focus of those whom participate actively to reach that objective. For Rogue V6's maybe some ACLs could work, but increases complexity. Maybe some mechanisms in the receiving nodes could work too, but requires a lot of computer resources and in that situations the LoWPAN will suffer its own success; so actually a solution should be adequate to each situation. BR On 06/12/11 07:46, Ray Soucy wrote:
I think of RA Guard as a Layer-2 stability feature, rather than a security feature.
You're correct that it is unable to deal with RA crafted in a fragmented packet on the majority (if not all) of implementations.
The issue of rogue RA exists on every network, regardless of whether or not the IT group has deployed IPv6 or is aware of the IPv6 traffic on that network.
Windows ICS is the most common "accidental" cause of rogue RA on a LAN.
On Mon, Dec 5, 2011 at 10:35 PM, Daniel Espejel <daniel.unam.ipv6@gmail.com> wrote:
So,still assuming the fact that attackers will use the same "traditional ipv4" methods to alter the correct functioning over a network?...Well, maybe. Toda's IPv6 expertise for some network andmins and security experts is minimal. So most trainning and understanding before implementing its a good idea.
For example, the RA-Guard method has a significant vulnerability: It's not designed to identify a "complex" IPv6-many extension headers formed packet (F. Gont - 6Networks). Some other security oriented mechanisms may fail because of the low IPv6 compliance.
Regards.
-- Daniel Espejel Pérez Técnico Académico D.G.T.I.C. - U.N.A.M. GT-IPv6 CLARA / GT-IPv6 U.N.A.M.
-- Daniel Espejel Pérez Técnico Académico D.G.T.I.C. - U.N.A.M. GT-IPv6 CLARA / GT-IPv6 U.N.A.M.
participants (2)
-
Daniel Espejel -
Ray Soucy