- Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.
News:
Welcome to Hurricane Electric's Tunnelbroker.net forums!
Recent posts
#41
IPv6 on Routing Platforms / Re: Problème avec la sécurisat...
Last post by snarked - September 27, 2024, 12:07:59 PMThere really isn't any way to validate the content of the ND packet itself. If one already knew where his neighbor(s) connect(s), one wouldn't need the ND packet to begin with (and would populate the local route table manually).
I have not used "SEND." I don't know of any way to detect that a neighbor was hacked if the packets comprising the hack did not pass through my system or network. Furthermore, a neighbor could be passing bad routes learnt from its other neighbor(s), so it/they might not be hacked at all.
I simply don't see how the data could be validated. All one can validate is that a neighbor delivered the data.
I have not used "SEND." I don't know of any way to detect that a neighbor was hacked if the packets comprising the hack did not pass through my system or network. Furthermore, a neighbor could be passing bad routes learnt from its other neighbor(s), so it/they might not be hacked at all.
I simply don't see how the data could be validated. All one can validate is that a neighbor delivered the data.
#42
IPv6 on Routing Platforms / Re: Problème avec la sécurisat...
Last post by gabinlm - September 27, 2024, 11:26:14 AMThank you for your detailed response! Your explanation about the trusted FE80::/10 range and the use of TTL 255 to ensure a direct connection makes sense. However, my concern is more about a potential attack vector where a malicious device on the same link might insert false Neighbor Advertisements, which could lead to man-in-the-middle attacks or routing issues.
I understand that IPSec can be a solution for securing ND packets, but in practice, it seems challenging to implement and maintain, especially in large networks. Have you had any experience using Secure Neighbor Discovery (SEND) as an alternative, or do you know of any other lightweight methods to prevent these types of attacks?
I understand that IPSec can be a solution for securing ND packets, but in practice, it seems challenging to implement and maintain, especially in large networks. Have you had any experience using Secure Neighbor Discovery (SEND) as an alternative, or do you know of any other lightweight methods to prevent these types of attacks?
#43
IPv6 on Routing Platforms / Re: Problème avec la sécurisat...
Last post by snarked - September 26, 2024, 11:28:31 AMFrench isn't among my top languages, but as I understand your post, you are concerned about route spoofing. You should be able to trust that the ND packets themselves are authentic as they are required to be link-level, and thus the source address should always be within FE80::/10, the destination within FE80::/10 or FF02::/16 (FF02::1 or FF02::2 specified in the RFC's, except redirect), and a TTL of 255, which makes certain it is from a direct connection. ICMP packets can be IPSec wrapped if further security hardening is needed.
As for the content of the packet, you are correct in that if the neighbor is compromised, bad routes can be inserted. However, if your system cannot trust its immediate neighbors, it should not accept data from them. Does that satisfy your question?
As for the content of the packet, you are correct in that if the neighbor is compromised, bad routes can be inserted. However, if your system cannot trust its immediate neighbors, it should not accept data from them. Does that satisfy your question?
#44
IPv6 on Routing Platforms / Problème avec la sécurisation ...
Last post by gabinlm - September 25, 2024, 12:19:22 PMBonjour à tous,
Je travaille actuellement sur la mise en place d'un réseau avec un support complet d'IPv6, mais je rencontre des difficultés concernant la sécurisation du protocole Neighbor Discovery (ND). Je cherche à protéger le réseau contre les attaques comme le Neighbor Spoofing ou d'autres formes d'usurpation d'adresses, mais je ne suis pas sûr que mes configurations soient optimales.
J'ai lu sur certaines méthodes, comme l'utilisation de SEND (Secure Neighbor Discovery), mais la complexité de sa mise en œuvre me pose problème. Est-ce que vous avez déjà utilisé SEND ou d'autres approches pour sécuriser ND dans un environnement IPv6 ? Quels seraient les meilleurs outils ou configurations pour renforcer la sécurité ? J'ai trouvé un lien sur les solutions que j'ai appliquées en IPv4, qui pourrait être utile pour la transition vers IPv6 contre l'ARP spoofing.
Je travaille actuellement sur la mise en place d'un réseau avec un support complet d'IPv6, mais je rencontre des difficultés concernant la sécurisation du protocole Neighbor Discovery (ND). Je cherche à protéger le réseau contre les attaques comme le Neighbor Spoofing ou d'autres formes d'usurpation d'adresses, mais je ne suis pas sûr que mes configurations soient optimales.
J'ai lu sur certaines méthodes, comme l'utilisation de SEND (Secure Neighbor Discovery), mais la complexité de sa mise en œuvre me pose problème. Est-ce que vous avez déjà utilisé SEND ou d'autres approches pour sécuriser ND dans un environnement IPv6 ? Quels seraient les meilleurs outils ou configurations pour renforcer la sécurité ? J'ai trouvé un lien sur les solutions que j'ai appliquées en IPv4, qui pourrait être utile pour la transition vers IPv6 contre l'ARP spoofing.
#45
Questions & Answers / Re: Native IPv6 configuration ...
Last post by troz - September 24, 2024, 02:32:38 AMFC00::/8 is reserved for currently unspecified use. (basically, no one can agree on how to use it.) FD00::/8 is for non-public use. Technically, you can do whatever you want with it, but there are some "karen" RFC's telling you what to do. (in short, use random prefixes -- "global id" -- to minimize any collisions with other networks, should they ever need to be connected. if you've ever tried to merge to 10/8-using enterprise networks...) Should the IETF ever agree on how to manage "fc", cjdns will have to stop squatting on the space; shame on them for ever doing this in the first place.
#46
IPv6 Basics & Questions & General Chatter / ping to 2600:: not working, ne...
Last post by zervaninfo - September 23, 2024, 02:38:49 AMIt seems that there are more troubles with connectivity, some Android apps are not working through HE Tunnel Broker.
For example, some times ago, my Strava and AliExpress apps stopped to worked correctly. Here are details:
I have set IPv6 address to 100:: to those names on my local DNS (MikroTik router) and now both apps are working correctly:
But there are 70+ more CNAMEs to cloudfront.net in my DNS cache - it means, many apps are not working or working very slowly (after app realizes that IPv6 is not working and uses IPv4).
Unfortunately, I can't find a way to completely change *.cloudfront.net in MikroTik (.*\.cloudfront\.net is not working, because it is checking only original name, not CNAME, I will consult it with MikroTik).
However, this is not solution, it is just quick hack. Why is cloudfront.net not working through HE tunnel? Who is responsible? Who could fix that?
For example, some times ago, my Strava and AliExpress apps stopped to worked correctly. Here are details:
- AliExpress is loading media from ae-pic-a1.aliexpress-media.com, which is CNAME to cloudfront.net (actually d3e2y37tle8w9m.cloudfront.net, 2600:9000:...) - not reachable from HE;
- Strava is loading data from cdn-1.strava.com, which is CNAME to cloudfront.net (actually d3u3hkafyj3iak.cloudfront.net, 2600:9000:...).
I have set IPv6 address to 100:: to those names on my local DNS (MikroTik router) and now both apps are working correctly:
- .*\.aliexpress-media\.com
- cdn.*\.strava\.com
But there are 70+ more CNAMEs to cloudfront.net in my DNS cache - it means, many apps are not working or working very slowly (after app realizes that IPv6 is not working and uses IPv4).
Unfortunately, I can't find a way to completely change *.cloudfront.net in MikroTik (.*\.cloudfront\.net is not working, because it is checking only original name, not CNAME, I will consult it with MikroTik).
However, this is not solution, it is just quick hack. Why is cloudfront.net not working through HE tunnel? Who is responsible? Who could fix that?
#47
IPv6 Basics & Questions & General Chatter / Re: Usage Poll
Last post by sdgathman - September 16, 2024, 06:22:21 AMOther: business. In 2024, major ISPs still do not implement IPv6 in a usable manner. Even with a business account, first level tech support has never heard of IPv6!
Conspiracy theory: Big Tech purposely suppresses IPv6 because IPv4 forces consumers to use centralized services (as static IPv4s are scarce). We don't want Uncle Tim hosting his personal web page on his personal computer again like in the 90s!
Conspiracy theory: Big Tech purposely suppresses IPv6 because IPv4 forces consumers to use centralized services (as static IPv4s are scarce). We don't want Uncle Tim hosting his personal web page on his personal computer again like in the 90s!
#48
Questions & Answers / Re: Native IPv6 configuration ...
Last post by sdgathman - September 16, 2024, 05:54:27 AMQuote from: cshilton on August 22, 2024, 09:34:07 AMQuestion: With Verizon's native IPv6 I'm getting 3 meaningful IP addresses on my interface, public - [2600:4040:xxxx:yyyy::host-part], and ULA - [fdww:xxxx:yyyy:zzzz::host-part] and of course, an link-local [fe80::host-part] address. Is the function of the ULA assignment to run local services?The fd00::/8 (actually fc00::/7) IPs are the IPv6 equivalent of 192.168.0.0/16 or 10.0.0.0/8. Link local (fe80) addresses could be used for services, but are inconvenient because you always have to specify the interface - and not all clients know how to do this, and the naming can be quite fickle.
Question: Is it safe to run services on the link local address?
For local services, use fc00::/7 - which you can route within your private network (all over the world, if your private network extends that far, which it might with VPN tunnels). Actually, just use fd00::/8, because fc00::/8 is used by the Cjdns protocol. I run services on Cjdns fc00::/8 ips because they are authenticated and e2e encrypted (and global). Cjdns is inspired by IPv6 CGA, where the host part is a fingerprint of the TLS cert. Cjdns extends this to where the entire IPv6 is a fingerprint of the TLS cert (throwing away certs outside the fc00::/8 fingerprint range).
#49
Questions & Answers / Re: AWS Public IP marked "This...
Last post by sdgathman - September 15, 2024, 03:38:04 PMI think he.net is cracking down on using a VPS to forward proto 41 past Evil™ ISPs and routers that block it. Not all hosting providers are blocked. Ramnode is still allowed. I would not use AWS anyway - they are way too centralized and monopolistic.
#50
Questions & Answers / Re: IP is not ICMP pingable. C...
Last post by snarked - September 15, 2024, 12:04:46 AMNote that you can change the endpoint IPv4 address without having to delete and recreate the tunnel. However, the address needs to be pingable. It's possible that the new ISP blocks pings. You should also try UDP pings to see if those make it to rule out unreachability.