<div>voici le lien de l'article en anglais:</div><div><div><font size="2" face="Times New Roman"><span style="font-size: 11pt;"> </span></font></div><div><font size="2" face="Times New Roman"><span style="font-size: 11pt;"><a href="http://www.networkworld.com/news/2011/112811-hackers-ipv6-253408.html" target="_blank"><font color="blue" size="2" face="Arial"><span style="font-size: 10pt;"><u>http://www.networkworld.com/news/2011/112811-hackers-ipv6-253408.html</u></span></font></a></span></font></div>
<div style="margin-bottom: 5pt;"><font size="3"><span style="font-size: 12pt;"><b>Hackers target IPv6 </b></span></font></div><div style="margin-bottom: 5pt;"><b>Enterprises need to be aware of hidden IPv6 vulnerabilities</b></div>
<div>By Susan Perschke, Network World <br>November 28, 2011 06:10 AM ET </div><div style="margin-bottom: 5pt;">If your IPv6 strategy is to delay implementation as long as you can, you still must address IPv6 <a href="http://www.networkworld.com/topics/security.html" target="_blank"><font color="blue"><u>security</u></font></a> concerns right now.</div>
<div style="margin-bottom: 5pt;">If you plan to deploy <a href="http://www.networkworld.com/news/2009/073009-ipv6-guide.html" target="_blank"><font color="blue"><u>IPv6</u></font></a> in a dual-stack configuration with IPv4, you're still not off the hook when it comes to security. And if you think you can simply turn off IPv6, that's not going to fly either.</div>
<div style="margin-bottom: 5pt;">The biggest looming security threat lies in the fact that enterprise networks already have tons of IPv6 enabled devices, including every device running <a href="http://www.networkworld.com/topics/windows.html" target="_blank"><font color="blue"><u>Windows</u></font></a>Vista or Windows 7, Mac OS/X, all <a href="http://www.networkworld.com/topics/linux.html" target="_blank"><font color="blue"><u>Linux</u></font></a> devices and BSD.</div>
<div style="margin-bottom: 5pt;">And unlike its predecessor, DHCP for IPv4, stateless IPv6 doesn’t require manual configuration. This stateless auto-configuration feature, enabled by default in most operating systems, means that "IPv6-enabled devices are just waiting for a single router advertisement to identify themselves on the network," says Eric Vyncke, Distinguished Systems Engineer at Cisco Systems and co-author of the book “IPv6 Security."</div>
<div style="margin-bottom: 5pt;">He cautions that "IPv4-only routers and switches don't recognize or respond to IPv6 device announcements, but a rogue IPv6 router could send and interpret this traffic."</div>
<div style="margin-bottom: 5pt;">Stateless auto-configuration allows any IPv6-enabled device to communicate with other IPv6 network devices and services on the same LAN. To do this, the device advertises its presence and is located via the IPv6 Neighbor Discovery Protocol (NDP).</div>
<div style="margin-bottom: 5pt;">But left unmanaged, NDP may be a bit too neighborly, possibly exposing devices to attackers anxious to glean information about what's going on inside the network, or even allowing the device itself to be taken over and turned into a "zombie."</div>
<div style="margin-bottom: 5pt;">Vyncke says the threat is real. "We have observed worldwide that bots are increasing their use of IPv6 as a covert channel to communicate with their botmaster." Among its many disguises, IPv6-enabled malware can take the form of a malicious payload encapsulated in one or more IPv4 messages. Without IPv6-specific security measures such as deep packet inspection, this type of payload may pass through the IPv4 perimeter and DMZ defenses undetected.</div>
<div style="margin-bottom: 5pt;">SEND (SEcure Neighbor Discovery) is the IETF solution to Layer-2 IPv6 threats such as rogue RA and NDP spoofing, which equate to IPv4 threats named rogue DHCP and ARP spoofing. Some OS vendors support SEND, while others, notably <a href="http://www.networkworld.com/subnets/microsoft/" target="_blank"><font color="blue"><u>Microsoft</u></font></a> and <a href="http://www.networkworld.com/slideshows/2009/060309-apple-quiz.html" target="_blank"><font color="blue"><u>Apple</u></font></a>, do not.</div>
<div style="margin-bottom: 5pt;">Cisco and the IETF are in the process of implementing the same security mechanisms for IPv6 that are currently used to protect IPv4 against these threats.</div><div style="margin-bottom: 5pt;">
The IETF has a working group SAVI (Source Address Validation) and Cisco is implementing a three-phase plan to upgrade its IOS that started in 2010 and will be fully implemented by sometime in 2012, depending upon the switch type.</div>
<div style="margin-bottom: 5pt;">Vyncke notes that some of the more common IPv6 security risks are accidentally created by an improperly configured end-user device on the network, and that proper configuration and IPv6 security measures would eliminate many of these risks.</div>
<div style="margin-bottom: 5pt;">"The answer to this type of problem is to deploy native IPv6, and to protect IPv6 traffic at the same level and against the same kinds of threats you already defend in IPv4," Vyncke explains.</div>
<div><font color="#4f81bd"><b>The IPSec myth</b></font></div><div style="margin-bottom: 5pt;">There's a common perception that IPv6 is natively more secure than IPv4 because IPSec support is mandatory in IPv6. "This is a myth that needs to be debunked," Vyncke says.</div>
<div style="margin-bottom: 5pt;">He points out that, aside from the practical challenges associated with the broad-scale implementation of IPSec, the content of IPSec-encapsulated traffic becomes invisible to devices (routers/switches/firewalls), thereby interfering with their important security functions.</div>
<div style="margin-bottom: 5pt;">For this reason, Vyncke, who is also an active member of the IETF and the author of RFC 3585, reports that an IETF working group is considering a <a href="http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-11" target="_blank"><font color="blue"><u>change that would make IPSec support</u></font></a> "recommended" rather than "required" in IPv6 implementations.</div>
<div style="margin-bottom: 5pt;">Regarding disabling IPv6, Vyncke says it's a bad idea for two reasons. One, Microsoft has said that disabling IPv6 on Windows 2008 constitutes an unsupported configuration. And Vyncke says trying to disable IPv6 is a head-in-the-sand strategy that delays the inevitable and could make security worse because IPv6 enabled devices are going to be showing up on the network whether IT wants it or not.</div>
<div><font color="#4f81bd"><b>Momentum building</b></font></div><div style="margin-bottom: 5pt;">Security threats aside, there is a growing business case for IPv6 that is getting harder to sweep under the rug. Banks and online brokerages already face the challenge of losing communication with international customers whose networks no longer support IPv4.</div>
<div style="margin-bottom: 5pt;">Companies like Telefonica and T-Mobile are embracing IPv6 in a big way, especially for their European bases. And the U.S. government, which has been steadily migrating to IPv6, is clamoring for providers and vendors to deliver more IPv6 products and services.</div>
<div style="margin-bottom: 5pt;">"You never want to be in a position where you can't interact with your customers," says Keith Stewart, director of Brocade Communications Systems <a href="http://www.networkworld.com/topics/applications.html" target="_blank"><font color="blue"><u>Applications</u></font></a>Delivery Products. Nevertheless, sharing the prevalent view among network vendors, Stewart sees a gradual migration to IPv6.</div>
<div style="margin-bottom: 5pt;">"A wholesale upgrade to IPv6 across the Internet is neither practical nor effective," Stewart says. "Customers need a balanced, practical approach." He notes that service providers, who consume addresses faster than anyone else, are first in line for IPv6 upgrades, followed by content hosts (Google and Facebook), and finally end-users, whose home routers are still 99% IPv4-based.</div>
<div style="margin-bottom: 5pt;">When Brocade needed to move to IPv6, it took existing load balancers and turned on IPv6 translation to public-facing services, preserving IPv4 connectivity on the internal network. "The public stack is the most important. Pick a smaller project where you can make a business case to communicate with IPv6 customers. When building out your next set of services, demand that it's dual-stack capable or translation-capable for older IPv4 architectures. This allows you to build a business-facing ROI as your teams gain competence with IPv6. Any transition should be designed to be seamless for the end user," Stewart says.</div>
<div style="margin-bottom: 5pt;">Juniper Networks reports that up to now the majority of its customers requesting IPv6 services are from the education and government sectors, specifically university research labs and governmental units seeking to comply with federal IPv6 mandates.</div>
<div style="margin-bottom: 5pt;">Juniper predicts increased IPv6 activity for 2012, especially among service providers. "IPv4 address exhaustion is becoming a significant problem for our customers around the world," says Alain Durand, director of software engineering, Platform and Systems Division CTO group. Even so, Durand expects that most IPv6 deployments will be smaller projects with IPv6 implemented as an "add-on" (dual-stack) to existing IPv4 public-facing services. "To deal with the growing shortage of IPv4 addresses, customers always have the option of adding another layer of NAT," Durand says.</div>
<div style="margin-bottom: 5pt;">While there is no way to predict with certainty exactly how long it will take until all IPv4 addresses are exhausted, the daily statistics compiled by Geoff Huston, chief scientist at APNIC, are frequently cited as a reliable source. Huston's model, which is based on public data sources derived from data published by the IANA and the Regional Internet Registries, predicts full <a href="http://www.networkworld.com/news/2011/020111-ipv4-apnic.html" target="_blank"><font color="blue"><u>depletion of all remaining unallocated IPv4 addresses by 2014</u></font></a>.</div>
<div style="margin-bottom: 5pt;">However, it is important to note that Huston's model does not factor in addresses which may be held by private organizations for future use or sale. For example, it would not factor in the more than 600,000 IPv4 addresses recently acquired by Microsoft under its purchase of bankrupt Nortel's assets. While it may be safe to assume that sufficient IPv4 addresses will be available in the near term, many predict costs to rise as the supply dwindles.</div>
<div style="margin-bottom: 5pt;">Without established best practices for IPv6, many network managers have been reluctant to act. But with increasing security threats and concerns about losing communication with customers who are already migrating to IPv6-only systems, waiting for others go first and doing nothing in the meantime isn't the 'position-neutral' stance that it might seem.</div>
<div style="margin-bottom: 5pt;">The planning phase is a good time to establish or re-establish ties with a trusted network vendor who can provide architecture and security guidance, together with scalable solutions for a broad array of migration options.<br>
<br></div></div><div class="gmail_quote">Le 6 décembre 2011 14:02, <span dir="ltr"><<a href="mailto:africann-request@afrinic.net">africann-request@afrinic.net</a>></span> a écrit :<br><blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
Send AfrICANN mailing list submissions to<br>
<a href="mailto:africann@afrinic.net">africann@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/africann" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/africann</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:africann-request@afrinic.net">africann-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:africann-owner@afrinic.net">africann-owner@afrinic.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of AfrICANN digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: AfrICANN Digest, Vol 58, Issue 6 (<a href="mailto:pikanza@gmail.com">pikanza@gmail.com</a>)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 6 Dec 2011 12:53:23 +0000<br>
From: <a href="mailto:pikanza@gmail.com">pikanza@gmail.com</a><br>
Subject: [AfrICANN-discuss] Re: AfrICANN Digest, Vol 58, Issue 6<br>
To: <a href="mailto:africann@afrinic.net">africann@afrinic.net</a><br>
Message-ID:<br>
<251702105-1323176004-cardhu_decombobulator_blackberry.rim.net-848422175-@b11.c2.bise7.blackberry><br>
<br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
<a href="mailto:Pikanza@newvision.co.ug">Pikanza@newvision.co.ug</a><br>
S e n t f r o m m y B l a c k B e r r y ® s m a r t p h o n e<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:africann-request@afrinic.net">africann-request@afrinic.net</a><br>
Sender: <a href="mailto:africann-bounces@afrinic.net">africann-bounces@afrinic.net</a><br>
Date: Tue, 6 Dec 2011 14:50:30<br>
To: <<a href="mailto:africann@afrinic.net">africann@afrinic.net</a>><br>
Reply-To: <a href="mailto:africann@afrinic.net">africann@afrinic.net</a><br>
Subject: AfrICANN Digest, Vol 58, Issue 6<br>
<br>
Send AfrICANN mailing list submissions to<br>
<a href="mailto:africann@afrinic.net">africann@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/africann" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/africann</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:africann-request@afrinic.net">africann-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:africann-owner@afrinic.net">africann-owner@afrinic.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of AfrICANN digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Hackers target IPv6 (Nacer Adamou Saidou)<br>
2. RE: Hackers target IPv6 (Jean-Robert Hountomey)<br>
3. RE: Hackers target IPv6 (ISOC Cameroon Chapter)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 05 Dec 2011 14:31:30 +0100<br>
From: Nacer Adamou Saidou <<a href="mailto:adamou.nacer@gmail.com">adamou.nacer@gmail.com</a>><br>
Subject: Re: [AfrICANN-discuss] Hackers target IPv6<br>
To: <a href="mailto:africann@afrinic.net">africann@afrinic.net</a><br>
Message-ID: <<a href="mailto:4EDCC7B2.1060402@gmail.com">4EDCC7B2.1060402@gmail.com</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Bonjour,<br>
ce message est franchement utile, mais je pense qu'il s'agit du résultat<br>
d'une traduction automatique et le français qui en résulte est vraiment<br>
difficile à déchiffrer.<br>
Est ce possible d'avoir le lien original de l'article ou carrément la<br>
version en anglais?<br>
Amicalement<br>
<br>
Le 05/12/2011 13:48, Joseph Mandjolo a écrit :<br>
> Hackers target IPv6<br>
><br>
> Les entreprises ont besoin d'être conscient de la vulnérabilité cachée IPv6<br>
><br>
> Par Susan Perschke, Network World<br>
> 28 novembre 2011 06:10 HE<br>
><br>
> Si votre stratégie IPv6 est de retarder la mise en œuvre aussi longtemps<br>
> que vous le pouvez, vous devez toujours répondre aux préoccupations de<br>
> sécurité IPv6 dès maintenant.<br>
><br>
> Si vous envisagez de déployer l'IPv6 dans une configuration dual-stack avec<br>
> IPv4, vous n'êtes toujours pas décroché quand il s'agit de sécurité. Et si<br>
> vous pensez que vous pouvez simplement désactiver l'IPv6, cela ne va pas<br>
> voler non plus.<br>
><br>
> La plus grande menace imminente de sécurité réside dans le fait que les<br>
> réseaux d'entreprise ont déjà des tonnes d'appareils compatibles IPv6, y<br>
> compris tous les appareils fonctionnant sous Windows Vista ou Windows 7,<br>
> Mac OS / X, tous les périphériques sous Linux et BSD.<br>
><br>
> Et contrairement à son prédécesseur, le protocole DHCP pour IPv4, IPv6 sans<br>
> état ne nécessite pas de configuration manuelle. Cette auto-configuration<br>
> sans fonction, activée par défaut dans la plupart des systèmes<br>
> d'exploitation, signifie que «IPv6 appareils sont simplement en attente<br>
> d'un annonce de routeur simple de s'identifier sur le réseau», explique<br>
> Eric Vyncke, Distinguished Engineer chez Cisco Systems Systèmes et co -auteur<br>
> du livre «La sécurité IPv6."<br>
><br>
> Il avertit que «IPv4 uniquement les routeurs et les commutateurs ne<br>
> reconnaissent pas ou répondre aux annonces dispositif d'IPv6, mais un<br>
> routeur IPv6 voyous pouvaient envoyer et d'interpréter ce trafic."<br>
><br>
> L'auto-configuration permet à tout appareil compatible IPv6 pour<br>
> communiquer avec d'autres périphériques réseau et les services IPv6 sur le<br>
> même LAN. Pour ce faire, l'appareil annonce sa présence et se trouve via<br>
> l'IPv6 Neighbor Discovery Protocol (NPD).<br>
><br>
> Mais elle n'était pas maîtrisée, NPD peut être un peu trop de bon<br>
> voisinage, éventuellement exposer les dispositifs d'attaquants désireux de<br>
> glaner des informations sur ce qui se passe à l'intérieur du réseau, ou<br>
> même en tenant l'appareil lui-même pour être repris et transformé en un<br>
> "zombie".<br>
><br>
> Vyncke affirme que la menace est réelle. "Nous avons observé dans le monde<br>
> entier que les robots sont d'accroître leur utilisation de l'IPv6 comme un<br>
> canal caché pour communiquer avec leurs botmaster». Parmi ses nombreux<br>
> déguisements, IPv6 logiciels malveillants peuvent prendre la forme d'une<br>
> charge utile malveillante encapsulé dans un ou plusieurs messages IPv4. Sans<br>
> mesures de sécurité IPv6 spécifiques telles que l'inspection approfondie<br>
> des paquets, ce type de charge utile peut passer à travers le périmètre<br>
> IPv4 et défenses DMZ inaperçue.<br>
><br>
> ENVOYER (Secure Neighbor Discovery) est la solution IETF pour Layer-2<br>
> menaces telles que IPv6 voyous RA et l'usurpation du NPD, qui équivalent à<br>
> IPv4 menaces appelé DHCP voyous et de l'ARP spoofing. Certains fournisseurs<br>
> OS soutien envoient, tandis que d'autres, notamment Microsoft et Apple,<br>
> n'en ont pas.<br>
><br>
> Cisco et l'IETF est en train de mettre en œuvre les mécanismes de sécurité<br>
> de même pour IPv6 qui sont actuellement utilisés pour protéger contre ces<br>
> menaces IPv4.<br>
><br>
> L'IETF a un. Groupe de travail SAVI (validation d'adresse source) et Cisco<br>
> met en œuvre un plan en trois phases visant à moderniser son IOS qui a<br>
> débuté en 2010 et seront entièrement mises en œuvre par quelque part en<br>
> 2012, selon le type de commutateur<br>
><br>
> Vyncke note que certains des risques les plus communs de sécurité IPv6 sont<br>
> accidentellement créé par une mauvaise configuration de l'utilisateur final<br>
> périphérique sur le réseau, et que la configuration appropriée et de<br>
> mesures de sécurité IPv6 permettrait d'éliminer nombre de ces risques.<br>
><br>
> "La réponse à ce type de problème est de déployer l'IPv6 natif, et de<br>
> protéger le trafic IPv6 au même niveau et contre les mêmes types de menaces<br>
> que vous avez déjà de défendre en IPv4», explique Vyncke.<br>
><br>
> Le mythe IPSec<br>
><br>
> Il ya une perception commune que l'IPv6 est nativement plus sécurisé que<br>
> IPv4, car en charge IPSec est obligatoire dans IPv6. «C'est un mythe qui a<br>
> besoin d'être démystifié», dit Vyncke.<br>
><br>
> Il souligne que, outre les difficultés pratiques liées à la mise en œuvre à<br>
> grande échelle du protocole IPSec, le contenu de IPSec encapsulé le trafic<br>
> devient invisible pour périphériques (routeurs / commutateurs / firewalls),<br>
> interférant ainsi avec leurs fonctions de sécurité importantes.<br>
><br>
> Pour cette raison, Vyncke, qui est également un membre actif de l'IETF et<br>
> l'auteur de la RFC 3585, rapporte qu'un groupe de travail IETF envisage une<br>
> modification qui ferait en charge IPSec «recommandé» plutôt que<br>
> «nécessaire» dans les implémentations d'IPv6.<br>
><br>
> En ce qui concerne IPv6 invalidante, Vyncke dit que c'est une mauvaise idée<br>
> pour deux raisons. One, Microsoft a déclaré que la désactivation de l'IPv6<br>
> sur Windows 2008 constitue une configuration non prise en charge. Et Vyncke<br>
> dit essayer de désactiver l'IPv6 est une tête-de-sable-stratégie qui<br>
> retarde l'inévitable et pourrait faire de la sécurité pire parce que les<br>
> périphériques compatibles IPv6 vont être apparaître sur le réseau qu'il le<br>
> veuille ou non.<br>
><br>
> Renforcer la dynamique<br>
><br>
> Les menaces de sécurité côté, il ya une analyse de rentabilisation<br>
> croissante pour IPv6 qui devient plus difficile de balayer sous le tapis. Les<br>
> banques et les courtiers en ligne font déjà face au défi de perdre la<br>
> communication avec les clients internationaux dont les réseaux ne<br>
> supportent plus l'IPv4.<br>
><br>
> Des entreprises comme Telefonica et T-Mobile IPv6 sont embrassant dans une<br>
> grande manière, surtout pour leurs bases européennes. Et le gouvernement<br>
> américain, qui n'a cessé de migrer vers l'IPv6, réclame à grands cris pour<br>
> les prestataires et fournisseurs à fournir des produits plus IPv6 et des<br>
> services.<br>
><br>
> «Vous ne voulez jamais être dans une position où vous ne pouvez pas<br>
> interagir avec vos clients», affirme Keith Stewart, directeur des produits<br>
> Brocade Communications Systems livraison Applications. Néanmoins, le<br>
> partage de l'opinion la plus répandue parmi les fournisseurs de réseau,<br>
> Stewart voit une migration progressive vers IPv6.<br>
><br>
> "Une mise à niveau de gros à travers l'Internet IPv6 n'est ni pratique ni<br>
> efficace», dit Stewart. «Les clients ont besoin d'une approche équilibrée<br>
> et pratique." Il note que les fournisseurs de services, qui consomment<br>
> adresses plus vite que n'importe qui d'autre, sont en première ligne pour<br>
> les mises à niveau IPv6, suivie par les hébergeurs de contenu (Google et<br>
> Facebook), et enfin les utilisateurs finaux, dont la maison routeurs sont<br>
> encore 99%, basé sur IPV4.<br>
><br>
> Lorsque Brocade nécessaire pour passer à l'IPv6, il a fallu les<br>
> équilibreurs de charge existants et tourné sur la traduction IPv6 pour les<br>
> services au public, la préservation de la connectivité IPv4 sur le réseau<br>
> interne. "La pile du public est le plus important. Choisissez un petit<br>
> projet où vous pouvez faire une analyse de rentabilisation pour communiquer<br>
> avec les clients IPv6. Lors de la construction hors de votre prochaine<br>
> série de services, la demande que ce double pile capable ou traduction<br>
> capables d'anciens IPv4 architectures . Cela vous permet de bâtir une<br>
> entreprise orientée ROI que vos équipes acquérir une compétence avec IPv6.<br>
> Toute transition devrait être conçu pour être transparent pour<br>
> l'utilisateur final », dit Stewart.<br>
><br>
> Juniper Networks rapporte que jusqu'à présent, la majorité de ses clients<br>
> demandant des services IPv6 sont des secteurs de l'éducation et du<br>
> gouvernement, plus précisément laboratoires de recherche universitaires et<br>
> les unités gouvernementales qui cherchent à se conformer aux mandats<br>
> fédéraux IPv6.<br>
><br>
> Juniper prévoit une activité accrue d'IPv6 pour 2012, notamment chez les<br>
> fournisseurs de services. «IPv4 épuisement des adresses devient un problème<br>
> important pour nos clients du monde entier», explique Alain Durand,<br>
> directeur du génie logiciel, plate-forme et la Division des systèmes CTO du<br>
> groupe. Même ainsi, Durand s'attend à ce que la plupart des déploiements<br>
> IPv6 seront plus petits projets mis en œuvre avec le protocole IPv6 comme<br>
> un «add-on» (dual-stack) pour IPv4 existante services au public. «Pour<br>
> faire face à la pénurie croissante d'adresses IPv4, les clients ont<br>
> toujours la possibilité d'ajouter une autre couche de NAT", explique Durand.<br>
><br>
> Bien qu'il n'y ait aucun moyen de prédire avec certitude combien de temps<br>
> exactement il faudra attendre toutes les adresses IPv4 sont épuisés, les<br>
> statistiques quotidiennes compilées par Geoff Huston, chief scientist chez<br>
> APNIC, sont fréquemment citées comme une source fiable. Modèle de Huston,<br>
> qui est basé sur les sources de données publiques tirées de données<br>
> publiées par l'IANA et les Registres Internet Régionaux, prédit<br>
> l'épuisement complet de tous les autres adresses IPv4 non attribuées en<br>
> 2014.<br>
><br>
> Cependant, il est important de noter que le modèle de Huston ne tient pas<br>
> compte des adresses qui peuvent être détenus par des organisations privées<br>
> pour un usage futur ou de la vente. Par exemple, il ne serait pas facteur<br>
> de plus de 600.000 adresses IPv4 récemment acquis par Microsoft en vertu de<br>
> son acquisition d'actifs faillite de Nortel. Bien qu'il soit prudent de<br>
> supposer que IPv4 suffisante adresses seront disponibles à court terme,<br>
> beaucoup prédisent coûts augmenter à mesure que diminue l'offre.<br>
><br>
> Sans établir les meilleures pratiques pour l'IPv6, les gestionnaires de<br>
> réseau de nombreux ont été réticents à agir. Mais avec l'augmentation des<br>
> menaces de sécurité et les préoccupations concernant la perte de<br>
> communication avec les clients qui sont déjà migrer vers IPv6 uniquement<br>
> les systèmes, en attendant que d'autres vont d'abord et ne rien faire en<br>
> attendant la position n'est pas la «position neutre» qu'il n'y paraît.<br>
><br>
> La phase de planification est un bon temps pour établir ou rétablir des<br>
> liens avec un vendeur de réseau de confiance qui peut fournir<br>
> l'architecture et les conseils de sécurité, avec des solutions évolutives<br>
> pour un large éventail d'options de migration.<br>
><br>
> Perschke est co-propriétaire de deux sociétés de services informatiques<br>
> spécialisée dans l'hébergement web, SaaS (nuage) le développement<br>
> d'applications et la modélisation et l'intégration de SGBDR. Susan a<br>
> également la responsabilité exécutive pour la gestion des risques et la<br>
> sécurité du réseau au centre de ses entreprises »de données. Elle peut être<br>
> atteint à <a href="mailto:susan@arcseven.com">susan@arcseven.com</a>.<br>
><br>
> Avec nos meilleures salutations<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> AfrICANN mailing list<br>
> <a href="mailto:AfrICANN@afrinic.net">AfrICANN@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/africann" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/africann</a><br>
<br>
- --<br>
Nacer Adamou Saïdou<br>
LPC-1 Certified Engineer<br>
Wave: <a href="mailto:nacerix@waveinabox.net">nacerix@waveinabox.net</a><br>
Blog: <a href="http://nacerix.blogspot.com" target="_blank">http://nacerix.blogspot.com</a><br>
Twitter: nacerix<br>
Identi.ca: nacerix<br>
<a href="http://paper.li/nacerix" target="_blank">http://paper.li/nacerix</a><br>
<a href="http://netvibes.net/nacerix" target="_blank">http://netvibes.net/nacerix</a><br>
<a href="https://launchpad.net/~adamou-nacer" target="_blank">https://launchpad.net/~adamou-nacer</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
iQEcBAEBAgAGBQJO3MeyAAoJELZpU0pKyeBuHE8IAJfRdSej3XkX4C95bQhaT+kC<br>
yF0Ctraxkm6f4NIo6k74+o73UiXXgBZ/NeF1aXBbmte+sRaXWo8km79KS7WZayzt<br>
YDx2X3lEs0uA3IjjWqO1cBYpr5MiEmURsTkyl+szW9q3YnOp/wLPICUBjaMeFbmN<br>
nqrqb8Rs6zJiqm13Wo9FTTqmoZVSttyxVdaiFOPn+TwhOvUeazcjKAh1cFVf+NR2<br>
5btKv7AEQy5zHOAdTWdG0ep6pS7a4PIFqeVSWf4PaG1xB+WH22a3Kh+7SeUowG8W<br>
waOyCAiDcaib9Lj9z7lyDXYTjg8Bbkapv8VuucIYlenRJNgaYHu33tiPFxcnO8w=<br>
=lT9v<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 5 Dec 2011 08:09:44 -0600<br>
From: "Jean-Robert Hountomey" <<a href="mailto:hrobert@iservices.tg">hrobert@iservices.tg</a>><br>
Subject: RE: [AfrICANN-discuss] Hackers target IPv6<br>
To: <<a href="mailto:africann@afrinic.net">africann@afrinic.net</a>><br>
Message-ID: <007a01ccb357$8bce6df0$a36b49d0$@<a href="http://iservices.tg" target="_blank">iservices.tg</a>><br>
Content-Type: text/plain; charset="windows-1258"<br>
<br>
<a href="http://www.networkworld.com/news/2011/112811-hackers-ipv6-253408.html" target="_blank">http://www.networkworld.com/news/2011/112811-hackers-ipv6-253408.html</a><br>
<br>
-----Message d'origine-----<br>
De : <a href="mailto:africann-bounces@afrinic.net">africann-bounces@afrinic.net</a> [mailto:<a href="mailto:africann-bounces@afrinic.net">africann-bounces@afrinic.net</a>] De<br>
la part de Nacer Adamou Saidou<br>
Envoyé : Monday, December 05, 2011 7:32 AM<br>
À : <a href="mailto:africann@afrinic.net">africann@afrinic.net</a><br>
Objet : Re: [AfrICANN-discuss] Hackers target IPv6<br>
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Bonjour,<br>
ce message est franchement utile, mais je pense qu'il s'agit du résultat<br>
d'une traduction automatique et le français qui en résulte est vraiment<br>
difficile à déchiffrer.<br>
Est ce possible d'avoir le lien original de l'article ou carrément la<br>
version en anglais?<br>
Amicalement<br>
<br>
Le 05/12/2011 13:48, Joseph Mandjolo a écrit :<br>
> Hackers target IPv6<br>
><br>
> Les entreprises ont besoin d'être conscient de la vulnérabilité cachée<br>
> IPv6<br>
><br>
> Par Susan Perschke, Network World<br>
> 28 novembre 2011 06:10 HE<br>
><br>
> Si votre stratégie IPv6 est de retarder la mise en œuvre aussi<br>
> longtemps que vous le pouvez, vous devez toujours répondre aux<br>
> préoccupations de sécurité IPv6 dès maintenant.<br>
><br>
> Si vous envisagez de déployer l'IPv6 dans une configuration dual-stack<br>
> avec IPv4, vous n'êtes toujours pas décroché quand il s'agit de<br>
> sécurité. Et si vous pensez que vous pouvez simplement désactiver<br>
> l'IPv6, cela ne va pas voler non plus.<br>
><br>
> La plus grande menace imminente de sécurité réside dans le fait que<br>
> les réseaux d'entreprise ont déjà des tonnes d'appareils compatibles<br>
> IPv6, y compris tous les appareils fonctionnant sous Windows Vista ou<br>
> Windows 7, Mac OS / X, tous les périphériques sous Linux et BSD.<br>
><br>
> Et contrairement à son prédécesseur, le protocole DHCP pour IPv4, IPv6<br>
> sans état ne nécessite pas de configuration manuelle. Cette<br>
> auto-configuration sans fonction, activée par défaut dans la plupart<br>
> des systèmes d'exploitation, signifie que «IPv6 appareils sont<br>
> simplement en attente d'un annonce de routeur simple de s'identifier<br>
> sur le réseau», explique Eric Vyncke, Distinguished Engineer chez<br>
> Cisco Systems Systèmes et co -auteur du livre «La sécurité IPv6."<br>
><br>
> Il avertit que «IPv4 uniquement les routeurs et les commutateurs ne<br>
> reconnaissent pas ou répondre aux annonces dispositif d'IPv6, mais un<br>
> routeur IPv6 voyous pouvaient envoyer et d'interpréter ce trafic."<br>
><br>
> L'auto-configuration permet à tout appareil compatible IPv6 pour<br>
> communiquer avec d'autres périphériques réseau et les services IPv6<br>
> sur le même LAN. Pour ce faire, l'appareil annonce sa présence et se<br>
> trouve via<br>
> l'IPv6 Neighbor Discovery Protocol (NPD).<br>
><br>
> Mais elle n'était pas maîtrisée, NPD peut être un peu trop de bon<br>
> voisinage, éventuellement exposer les dispositifs d'attaquants<br>
> désireux de glaner des informations sur ce qui se passe à l'intérieur<br>
> du réseau, ou même en tenant l'appareil lui-même pour être repris et<br>
> transformé en un "zombie".<br>
><br>
> Vyncke affirme que la menace est réelle. "Nous avons observé dans le<br>
> monde entier que les robots sont d'accroître leur utilisation de<br>
> l'IPv6 comme un canal caché pour communiquer avec leurs botmaster».<br>
> Parmi ses nombreux déguisements, IPv6 logiciels malveillants peuvent<br>
> prendre la forme d'une charge utile malveillante encapsulé dans un ou<br>
> plusieurs messages IPv4. Sans mesures de sécurité IPv6 spécifiques<br>
> telles que l'inspection approfondie des paquets, ce type de charge<br>
> utile peut passer à travers le périmètre<br>
> IPv4 et défenses DMZ inaperçue.<br>
><br>
> ENVOYER (Secure Neighbor Discovery) est la solution IETF pour Layer-2<br>
> menaces telles que IPv6 voyous RA et l'usurpation du NPD, qui<br>
> équivalent à<br>
> IPv4 menaces appelé DHCP voyous et de l'ARP spoofing. Certains<br>
> fournisseurs OS soutien envoient, tandis que d'autres, notamment<br>
> Microsoft et Apple, n'en ont pas.<br>
><br>
> Cisco et l'IETF est en train de mettre en œuvre les mécanismes de<br>
> sécurité de même pour IPv6 qui sont actuellement utilisés pour<br>
> protéger contre ces menaces IPv4.<br>
><br>
> L'IETF a un. Groupe de travail SAVI (validation d'adresse source) et<br>
> Cisco met en œuvre un plan en trois phases visant à moderniser son IOS<br>
> qui a débuté en 2010 et seront entièrement mises en œuvre par quelque<br>
> part en 2012, selon le type de commutateur<br>
><br>
> Vyncke note que certains des risques les plus communs de sécurité IPv6<br>
> sont accidentellement créé par une mauvaise configuration de<br>
> l'utilisateur final périphérique sur le réseau, et que la<br>
> configuration appropriée et de mesures de sécurité IPv6 permettrait<br>
d'éliminer nombre de ces risques.<br>
><br>
> "La réponse à ce type de problème est de déployer l'IPv6 natif, et de<br>
> protéger le trafic IPv6 au même niveau et contre les mêmes types de<br>
> menaces que vous avez déjà de défendre en IPv4», explique Vyncke.<br>
><br>
> Le mythe IPSec<br>
><br>
> Il ya une perception commune que l'IPv6 est nativement plus sécurisé<br>
> que IPv4, car en charge IPSec est obligatoire dans IPv6. «C'est un<br>
> mythe qui a besoin d'être démystifié», dit Vyncke.<br>
><br>
> Il souligne que, outre les difficultés pratiques liées à la mise en<br>
> œuvre à grande échelle du protocole IPSec, le contenu de IPSec<br>
> encapsulé le trafic devient invisible pour périphériques (routeurs /<br>
> commutateurs / firewalls), interférant ainsi avec leurs fonctions de<br>
sécurité importantes.<br>
><br>
> Pour cette raison, Vyncke, qui est également un membre actif de l'IETF<br>
> et l'auteur de la RFC 3585, rapporte qu'un groupe de travail IETF<br>
> envisage une modification qui ferait en charge IPSec «recommandé»<br>
> plutôt que «nécessaire» dans les implémentations d'IPv6.<br>
><br>
> En ce qui concerne IPv6 invalidante, Vyncke dit que c'est une mauvaise<br>
> idée pour deux raisons. One, Microsoft a déclaré que la désactivation<br>
> de l'IPv6 sur Windows 2008 constitue une configuration non prise en<br>
> charge. Et Vyncke dit essayer de désactiver l'IPv6 est une<br>
> tête-de-sable-stratégie qui retarde l'inévitable et pourrait faire de<br>
> la sécurité pire parce que les périphériques compatibles IPv6 vont<br>
> être apparaître sur le réseau qu'il le veuille ou non.<br>
><br>
> Renforcer la dynamique<br>
><br>
> Les menaces de sécurité côté, il ya une analyse de rentabilisation<br>
> croissante pour IPv6 qui devient plus difficile de balayer sous le<br>
> tapis. Les banques et les courtiers en ligne font déjà face au défi de<br>
> perdre la communication avec les clients internationaux dont les<br>
> réseaux ne supportent plus l'IPv4.<br>
><br>
> Des entreprises comme Telefonica et T-Mobile IPv6 sont embrassant dans<br>
> une grande manière, surtout pour leurs bases européennes. Et le<br>
> gouvernement américain, qui n'a cessé de migrer vers l'IPv6, réclame à<br>
> grands cris pour les prestataires et fournisseurs à fournir des<br>
> produits plus IPv6 et des services.<br>
><br>
> «Vous ne voulez jamais être dans une position où vous ne pouvez pas<br>
> interagir avec vos clients», affirme Keith Stewart, directeur des<br>
> produits Brocade Communications Systems livraison Applications.<br>
> Néanmoins, le partage de l'opinion la plus répandue parmi les<br>
> fournisseurs de réseau, Stewart voit une migration progressive vers IPv6.<br>
><br>
> "Une mise à niveau de gros à travers l'Internet IPv6 n'est ni pratique<br>
> ni efficace», dit Stewart. «Les clients ont besoin d'une approche<br>
> équilibrée et pratique." Il note que les fournisseurs de services, qui<br>
> consomment adresses plus vite que n'importe qui d'autre, sont en<br>
> première ligne pour les mises à niveau IPv6, suivie par les hébergeurs<br>
> de contenu (Google et Facebook), et enfin les utilisateurs finaux,<br>
> dont la maison routeurs sont encore 99%, basé sur IPV4.<br>
><br>
> Lorsque Brocade nécessaire pour passer à l'IPv6, il a fallu les<br>
> équilibreurs de charge existants et tourné sur la traduction IPv6 pour<br>
> les services au public, la préservation de la connectivité IPv4 sur le<br>
> réseau interne. "La pile du public est le plus important. Choisissez<br>
> un petit projet où vous pouvez faire une analyse de rentabilisation<br>
> pour communiquer avec les clients IPv6. Lors de la construction hors<br>
> de votre prochaine série de services, la demande que ce double pile<br>
> capable ou traduction capables d'anciens IPv4 architectures . Cela<br>
> vous permet de bâtir une entreprise orientée ROI que vos équipes acquérir<br>
une compétence avec IPv6.<br>
> Toute transition devrait être conçu pour être transparent pour<br>
> l'utilisateur final », dit Stewart.<br>
><br>
> Juniper Networks rapporte que jusqu'à présent, la majorité de ses<br>
> clients demandant des services IPv6 sont des secteurs de l'éducation<br>
> et du gouvernement, plus précisément laboratoires de recherche<br>
> universitaires et les unités gouvernementales qui cherchent à se<br>
> conformer aux mandats fédéraux IPv6.<br>
><br>
> Juniper prévoit une activité accrue d'IPv6 pour 2012, notamment chez<br>
> les fournisseurs de services. «IPv4 épuisement des adresses devient un<br>
> problème important pour nos clients du monde entier», explique Alain<br>
> Durand, directeur du génie logiciel, plate-forme et la Division des<br>
> systèmes CTO du groupe. Même ainsi, Durand s'attend à ce que la<br>
> plupart des déploiements<br>
> IPv6 seront plus petits projets mis en œuvre avec le protocole IPv6<br>
> comme un «add-on» (dual-stack) pour IPv4 existante services au public.<br>
> «Pour faire face à la pénurie croissante d'adresses IPv4, les clients<br>
> ont toujours la possibilité d'ajouter une autre couche de NAT", explique<br>
Durand.<br>
><br>
> Bien qu'il n'y ait aucun moyen de prédire avec certitude combien de<br>
> temps exactement il faudra attendre toutes les adresses IPv4 sont<br>
> épuisés, les statistiques quotidiennes compilées par Geoff Huston,<br>
> chief scientist chez APNIC, sont fréquemment citées comme une source<br>
> fiable. Modèle de Huston, qui est basé sur les sources de données<br>
> publiques tirées de données publiées par l'IANA et les Registres<br>
> Internet Régionaux, prédit l'épuisement complet de tous les autres<br>
> adresses IPv4 non attribuées en 2014.<br>
><br>
> Cependant, il est important de noter que le modèle de Huston ne tient<br>
> pas compte des adresses qui peuvent être détenus par des organisations<br>
> privées pour un usage futur ou de la vente. Par exemple, il ne serait<br>
> pas facteur de plus de 600.000 adresses IPv4 récemment acquis par<br>
> Microsoft en vertu de son acquisition d'actifs faillite de Nortel.<br>
> Bien qu'il soit prudent de supposer que IPv4 suffisante adresses<br>
> seront disponibles à court terme, beaucoup prédisent coûts augmenter à<br>
mesure que diminue l'offre.<br>
><br>
> Sans établir les meilleures pratiques pour l'IPv6, les gestionnaires<br>
> de réseau de nombreux ont été réticents à agir. Mais avec<br>
> l'augmentation des menaces de sécurité et les préoccupations<br>
> concernant la perte de communication avec les clients qui sont déjà<br>
> migrer vers IPv6 uniquement les systèmes, en attendant que d'autres<br>
> vont d'abord et ne rien faire en attendant la position n'est pas la<br>
«position neutre» qu'il n'y paraît.<br>
><br>
> La phase de planification est un bon temps pour établir ou rétablir<br>
> des liens avec un vendeur de réseau de confiance qui peut fournir<br>
> l'architecture et les conseils de sécurité, avec des solutions<br>
> évolutives pour un large éventail d'options de migration.<br>
><br>
> Perschke est co-propriétaire de deux sociétés de services<br>
> informatiques spécialisée dans l'hébergement web, SaaS (nuage) le<br>
> développement d'applications et la modélisation et l'intégration de<br>
> SGBDR. Susan a également la responsabilité exécutive pour la gestion<br>
> des risques et la sécurité du réseau au centre de ses entreprises »de<br>
> données. Elle peut être atteint à <a href="mailto:susan@arcseven.com">susan@arcseven.com</a>.<br>
><br>
> Avec nos meilleures salutations<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> AfrICANN mailing list<br>
> <a href="mailto:AfrICANN@afrinic.net">AfrICANN@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/africann" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/africann</a><br>
<br>
- --<br>
Nacer Adamou Saïdou<br>
LPC-1 Certified Engineer<br>
Wave: <a href="mailto:nacerix@waveinabox.net">nacerix@waveinabox.net</a><br>
Blog: <a href="http://nacerix.blogspot.com" target="_blank">http://nacerix.blogspot.com</a><br>
Twitter: nacerix<br>
Identi.ca: nacerix<br>
<a href="http://paper.li/nacerix" target="_blank">http://paper.li/nacerix</a><br>
<a href="http://netvibes.net/nacerix" target="_blank">http://netvibes.net/nacerix</a><br>
<a href="https://launchpad.net/~adamou-nacer" target="_blank">https://launchpad.net/~adamou-nacer</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
iQEcBAEBAgAGBQJO3MeyAAoJELZpU0pKyeBuHE8IAJfRdSej3XkX4C95bQhaT+kC<br>
yF0Ctraxkm6f4NIo6k74+o73UiXXgBZ/NeF1aXBbmte+sRaXWo8km79KS7WZayzt<br>
YDx2X3lEs0uA3IjjWqO1cBYpr5MiEmURsTkyl+szW9q3YnOp/wLPICUBjaMeFbmN<br>
nqrqb8Rs6zJiqm13Wo9FTTqmoZVSttyxVdaiFOPn+TwhOvUeazcjKAh1cFVf+NR2<br>
5btKv7AEQy5zHOAdTWdG0ep6pS7a4PIFqeVSWf4PaG1xB+WH22a3Kh+7SeUowG8W<br>
waOyCAiDcaib9Lj9z7lyDXYTjg8Bbkapv8VuucIYlenRJNgaYHu33tiPFxcnO8w=<br>
=lT9v<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
AfrICANN mailing list<br>
<a href="mailto:AfrICANN@afrinic.net">AfrICANN@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/africann" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/africann</a><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 6 Dec 2011 13:08:08 +0100<br>
From: "ISOC Cameroon Chapter" <<a href="mailto:info@isoc-cameroon.org">info@isoc-cameroon.org</a>><br>
Subject: RE: [AfrICANN-discuss] Hackers target IPv6<br>
To: <<a href="mailto:africann@afrinic.net">africann@afrinic.net</a>><br>
Message-ID: <000601ccb40f$bc653440$352f9cc0$@org><br>
Content-Type: text/plain; charset="windows-1258"<br>
<br>
Merci Jean-Robert pour le lien original!<br>
<br>
Tu avais raison Nacer, l'article en anglais est beaucoup plus<br>
compréhensible. Cette faille de sécurité serait-elle un justificatif du<br>
retard accusé dans le déploiement de l'IPv6?<br>
<br>
Je me suis toujours demandé le pourquoi de cette lenteur dans l'adoption et<br>
le déploiement de ce "nouveau-ancien" protocole qu'est l'IPv6. Il faut noté<br>
qu'IPv6 est prêt et utilisable depuis 1999 quand même!<br>
<br>
L'une des raisons principales de ce retard est sans doute que l'IPv4 est là,<br>
disponible et marche bien! Pourquoi investir dans le nouveau alors que<br>
l'ancien est là disponible et fonctionnel? Et l'être humain est toujours<br>
retissant et sceptique envers le changement. Alors un vrai travail<br>
didactique de conduite du changement s'impose.<br>
<br>
Je profite de ce mail pour vous annoncer que le Projet "IMPACT IPv6" du<br>
Chapitre Cameroun de l'Internet Society qui a été sélectionné par le<br>
programme de subventions à la communauté de l'ISOC (prix de novembre 2011:<br>
<a href="http://www.isoc.org/isoc/chapters/projects/awards.php?phase=14" target="_blank">http://www.isoc.org/isoc/chapters/projects/awards.php?phase=14</a> ) vise à<br>
accompagner la conduite du changement vers l'IPv6 au niveau du Cameroun. Je<br>
vous en dirais plus dès que le projets sera effectivement lancé.<br>
Cordialement,<br>
<br>
Victor Ndonnang<br>
SG<br>
ISOC Cameroon Chapter<br>
<br>
-----Message d'origine-----<br>
De : <a href="mailto:africann-bounces@afrinic.net">africann-bounces@afrinic.net</a> [mailto:<a href="mailto:africann-bounces@afrinic.net">africann-bounces@afrinic.net</a>] De<br>
la part de Jean-Robert Hountomey<br>
Envoyé : lundi 5 décembre 2011 15:10<br>
À : <a href="mailto:africann@afrinic.net">africann@afrinic.net</a><br>
Objet : RE: [AfrICANN-discuss] Hackers target IPv6<br>
<br>
<a href="http://www.networkworld.com/news/2011/112811-hackers-ipv6-253408.html" target="_blank">http://www.networkworld.com/news/2011/112811-hackers-ipv6-253408.html</a><br>
<br>
-----Message d'origine-----<br>
De : <a href="mailto:africann-bounces@afrinic.net">africann-bounces@afrinic.net</a> [mailto:<a href="mailto:africann-bounces@afrinic.net">africann-bounces@afrinic.net</a>] De<br>
la part de Nacer Adamou Saidou<br>
Envoyé : Monday, December 05, 2011 7:32 AM<br>
À : <a href="mailto:africann@afrinic.net">africann@afrinic.net</a><br>
Objet : Re: [AfrICANN-discuss] Hackers target IPv6<br>
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Bonjour,<br>
ce message est franchement utile, mais je pense qu'il s'agit du résultat<br>
d'une traduction automatique et le français qui en résulte est vraiment<br>
difficile à déchiffrer.<br>
Est ce possible d'avoir le lien original de l'article ou carrément la<br>
version en anglais?<br>
Amicalement<br>
<br>
Le 05/12/2011 13:48, Joseph Mandjolo a écrit :<br>
> Hackers target IPv6<br>
><br>
> Les entreprises ont besoin d'être conscient de la vulnérabilité cachée<br>
> IPv6<br>
><br>
> Par Susan Perschke, Network World<br>
> 28 novembre 2011 06:10 HE<br>
><br>
> Si votre stratégie IPv6 est de retarder la mise en œuvre aussi<br>
> longtemps que vous le pouvez, vous devez toujours répondre aux<br>
> préoccupations de sécurité IPv6 dès maintenant.<br>
><br>
> Si vous envisagez de déployer l'IPv6 dans une configuration dual-stack<br>
> avec IPv4, vous n'êtes toujours pas décroché quand il s'agit de<br>
> sécurité. Et si vous pensez que vous pouvez simplement désactiver<br>
> l'IPv6, cela ne va pas voler non plus.<br>
><br>
> La plus grande menace imminente de sécurité réside dans le fait que<br>
> les réseaux d'entreprise ont déjà des tonnes d'appareils compatibles<br>
> IPv6, y compris tous les appareils fonctionnant sous Windows Vista ou<br>
> Windows 7, Mac OS / X, tous les périphériques sous Linux et BSD.<br>
><br>
> Et contrairement à son prédécesseur, le protocole DHCP pour IPv4, IPv6<br>
> sans état ne nécessite pas de configuration manuelle. Cette<br>
> auto-configuration sans fonction, activée par défaut dans la plupart<br>
> des systèmes d'exploitation, signifie que «IPv6 appareils sont<br>
> simplement en attente d'un annonce de routeur simple de s'identifier<br>
> sur le réseau», explique Eric Vyncke, Distinguished Engineer chez<br>
> Cisco Systems Systèmes et co -auteur du livre «La sécurité IPv6."<br>
><br>
> Il avertit que «IPv4 uniquement les routeurs et les commutateurs ne<br>
> reconnaissent pas ou répondre aux annonces dispositif d'IPv6, mais un<br>
> routeur IPv6 voyous pouvaient envoyer et d'interpréter ce trafic."<br>
><br>
> L'auto-configuration permet à tout appareil compatible IPv6 pour<br>
> communiquer avec d'autres périphériques réseau et les services IPv6<br>
> sur le même LAN. Pour ce faire, l'appareil annonce sa présence et se<br>
> trouve via<br>
> l'IPv6 Neighbor Discovery Protocol (NPD).<br>
><br>
> Mais elle n'était pas maîtrisée, NPD peut être un peu trop de bon<br>
> voisinage, éventuellement exposer les dispositifs d'attaquants<br>
> désireux de glaner des informations sur ce qui se passe à l'intérieur<br>
> du réseau, ou même en tenant l'appareil lui-même pour être repris et<br>
> transformé en un "zombie".<br>
><br>
> Vyncke affirme que la menace est réelle. "Nous avons observé dans le<br>
> monde entier que les robots sont d'accroître leur utilisation de<br>
> l'IPv6 comme un canal caché pour communiquer avec leurs botmaster».<br>
> Parmi ses nombreux déguisements, IPv6 logiciels malveillants peuvent<br>
> prendre la forme d'une charge utile malveillante encapsulé dans un ou<br>
> plusieurs messages IPv4. Sans mesures de sécurité IPv6 spécifiques<br>
> telles que l'inspection approfondie des paquets, ce type de charge<br>
> utile peut passer à travers le périmètre<br>
> IPv4 et défenses DMZ inaperçue.<br>
><br>
> ENVOYER (Secure Neighbor Discovery) est la solution IETF pour Layer-2<br>
> menaces telles que IPv6 voyous RA et l'usurpation du NPD, qui<br>
> équivalent à<br>
> IPv4 menaces appelé DHCP voyous et de l'ARP spoofing. Certains<br>
> fournisseurs OS soutien envoient, tandis que d'autres, notamment<br>
> Microsoft et Apple, n'en ont pas.<br>
><br>
> Cisco et l'IETF est en train de mettre en œuvre les mécanismes de<br>
> sécurité de même pour IPv6 qui sont actuellement utilisés pour<br>
> protéger contre ces menaces IPv4.<br>
><br>
> L'IETF a un. Groupe de travail SAVI (validation d'adresse source) et<br>
> Cisco met en œuvre un plan en trois phases visant à moderniser son IOS<br>
> qui a débuté en 2010 et seront entièrement mises en œuvre par quelque<br>
> part en 2012, selon le type de commutateur<br>
><br>
> Vyncke note que certains des risques les plus communs de sécurité IPv6<br>
> sont accidentellement créé par une mauvaise configuration de<br>
> l'utilisateur final périphérique sur le réseau, et que la<br>
> configuration appropriée et de mesures de sécurité IPv6 permettrait<br>
d'éliminer nombre de ces risques.<br>
><br>
> "La réponse à ce type de problème est de déployer l'IPv6 natif, et de<br>
> protéger le trafic IPv6 au même niveau et contre les mêmes types de<br>
> menaces que vous avez déjà de défendre en IPv4», explique Vyncke.<br>
><br>
> Le mythe IPSec<br>
><br>
> Il ya une perception commune que l'IPv6 est nativement plus sécurisé<br>
> que IPv4, car en charge IPSec est obligatoire dans IPv6. «C'est un<br>
> mythe qui a besoin d'être démystifié», dit Vyncke.<br>
><br>
> Il souligne que, outre les difficultés pratiques liées à la mise en<br>
> œuvre à grande échelle du protocole IPSec, le contenu de IPSec<br>
> encapsulé le trafic devient invisible pour périphériques (routeurs /<br>
> commutateurs / firewalls), interférant ainsi avec leurs fonctions de<br>
sécurité importantes.<br>
><br>
> Pour cette raison, Vyncke, qui est également un membre actif de l'IETF<br>
> et l'auteur de la RFC 3585, rapporte qu'un groupe de travail IETF<br>
> envisage une modification qui ferait en charge IPSec «recommandé»<br>
> plutôt que «nécessaire» dans les implémentations d'IPv6.<br>
><br>
> En ce qui concerne IPv6 invalidante, Vyncke dit que c'est une mauvaise<br>
> idée pour deux raisons. One, Microsoft a déclaré que la désactivation<br>
> de l'IPv6 sur Windows 2008 constitue une configuration non prise en<br>
> charge. Et Vyncke dit essayer de désactiver l'IPv6 est une<br>
> tête-de-sable-stratégie qui retarde l'inévitable et pourrait faire de<br>
> la sécurité pire parce que les périphériques compatibles IPv6 vont<br>
> être apparaître sur le réseau qu'il le veuille ou non.<br>
><br>
> Renforcer la dynamique<br>
><br>
> Les menaces de sécurité côté, il ya une analyse de rentabilisation<br>
> croissante pour IPv6 qui devient plus difficile de balayer sous le<br>
> tapis. Les banques et les courtiers en ligne font déjà face au défi de<br>
> perdre la communication avec les clients internationaux dont les<br>
> réseaux ne supportent plus l'IPv4.<br>
><br>
> Des entreprises comme Telefonica et T-Mobile IPv6 sont embrassant dans<br>
> une grande manière, surtout pour leurs bases européennes. Et le<br>
> gouvernement américain, qui n'a cessé de migrer vers l'IPv6, réclame à<br>
> grands cris pour les prestataires et fournisseurs à fournir des<br>
> produits plus IPv6 et des services.<br>
><br>
> «Vous ne voulez jamais être dans une position où vous ne pouvez pas<br>
> interagir avec vos clients», affirme Keith Stewart, directeur des<br>
> produits Brocade Communications Systems livraison Applications.<br>
> Néanmoins, le partage de l'opinion la plus répandue parmi les<br>
> fournisseurs de réseau, Stewart voit une migration progressive vers IPv6.<br>
><br>
> "Une mise à niveau de gros à travers l'Internet IPv6 n'est ni pratique<br>
> ni efficace», dit Stewart. «Les clients ont besoin d'une approche<br>
> équilibrée et pratique." Il note que les fournisseurs de services, qui<br>
> consomment adresses plus vite que n'importe qui d'autre, sont en<br>
> première ligne pour les mises à niveau IPv6, suivie par les hébergeurs<br>
> de contenu (Google et Facebook), et enfin les utilisateurs finaux,<br>
> dont la maison routeurs sont encore 99%, basé sur IPV4.<br>
><br>
> Lorsque Brocade nécessaire pour passer à l'IPv6, il a fallu les<br>
> équilibreurs de charge existants et tourné sur la traduction IPv6 pour<br>
> les services au public, la préservation de la connectivité IPv4 sur le<br>
> réseau interne. "La pile du public est le plus important. Choisissez<br>
> un petit projet où vous pouvez faire une analyse de rentabilisation<br>
> pour communiquer avec les clients IPv6. Lors de la construction hors<br>
> de votre prochaine série de services, la demande que ce double pile<br>
> capable ou traduction capables d'anciens IPv4 architectures . Cela<br>
> vous permet de bâtir une entreprise orientée ROI que vos équipes acquérir<br>
une compétence avec IPv6.<br>
> Toute transition devrait être conçu pour être transparent pour<br>
> l'utilisateur final », dit Stewart.<br>
><br>
> Juniper Networks rapporte que jusqu'à présent, la majorité de ses<br>
> clients demandant des services IPv6 sont des secteurs de l'éducation<br>
> et du gouvernement, plus précisément laboratoires de recherche<br>
> universitaires et les unités gouvernementales qui cherchent à se<br>
> conformer aux mandats fédéraux IPv6.<br>
><br>
> Juniper prévoit une activité accrue d'IPv6 pour 2012, notamment chez<br>
> les fournisseurs de services. «IPv4 épuisement des adresses devient un<br>
> problème important pour nos clients du monde entier», explique Alain<br>
> Durand, directeur du génie logiciel, plate-forme et la Division des<br>
> systèmes CTO du groupe. Même ainsi, Durand s'attend à ce que la<br>
> plupart des déploiements<br>
> IPv6 seront plus petits projets mis en œuvre avec le protocole IPv6<br>
> comme un «add-on» (dual-stack) pour IPv4 existante services au public.<br>
> «Pour faire face à la pénurie croissante d'adresses IPv4, les clients<br>
> ont toujours la possibilité d'ajouter une autre couche de NAT", explique<br>
Durand.<br>
><br>
> Bien qu'il n'y ait aucun moyen de prédire avec certitude combien de<br>
> temps exactement il faudra attendre toutes les adresses IPv4 sont<br>
> épuisés, les statistiques quotidiennes compilées par Geoff Huston,<br>
> chief scientist chez APNIC, sont fréquemment citées comme une source<br>
> fiable. Modèle de Huston, qui est basé sur les sources de données<br>
> publiques tirées de données publiées par l'IANA et les Registres<br>
> Internet Régionaux, prédit l'épuisement complet de tous les autres<br>
> adresses IPv4 non attribuées en 2014.<br>
><br>
> Cependant, il est important de noter que le modèle de Huston ne tient<br>
> pas compte des adresses qui peuvent être détenus par des organisations<br>
> privées pour un usage futur ou de la vente. Par exemple, il ne serait<br>
> pas facteur de plus de 600.000 adresses IPv4 récemment acquis par<br>
> Microsoft en vertu de son acquisition d'actifs faillite de Nortel.<br>
> Bien qu'il soit prudent de supposer que IPv4 suffisante adresses<br>
> seront disponibles à court terme, beaucoup prédisent coûts augmenter à<br>
mesure que diminue l'offre.<br>
><br>
> Sans établir les meilleures pratiques pour l'IPv6, les gestionnaires<br>
> de réseau de nombreux ont été réticents à agir. Mais avec<br>
> l'augmentation des menaces de sécurité et les préoccupations<br>
> concernant la perte de communication avec les clients qui sont déjà<br>
> migrer vers IPv6 uniquement les systèmes, en attendant que d'autres<br>
> vont d'abord et ne rien faire en attendant la position n'est pas la<br>
«position neutre» qu'il n'y paraît.<br>
><br>
> La phase de planification est un bon temps pour établir ou rétablir<br>
> des liens avec un vendeur de réseau de confiance qui peut fournir<br>
> l'architecture et les conseils de sécurité, avec des solutions<br>
> évolutives pour un large éventail d'options de migration.<br>
><br>
> Perschke est co-propriétaire de deux sociétés de services<br>
> informatiques spécialisée dans l'hébergement web, SaaS (nuage) le<br>
> développement d'applications et la modélisation et l'intégration de<br>
> SGBDR. Susan a également la responsabilité exécutive pour la gestion<br>
> des risques et la sécurité du réseau au centre de ses entreprises »de<br>
> données. Elle peut être atteint à <a href="mailto:susan@arcseven.com">susan@arcseven.com</a>.<br>
><br>
> Avec nos meilleures salutations<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> AfrICANN mailing list<br>
> <a href="mailto:AfrICANN@afrinic.net">AfrICANN@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo.cgi/africann" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/africann</a><br>
<br>
- --<br>
Nacer Adamou Saïdou<br>
LPC-1 Certified Engineer<br>
Wave: <a href="mailto:nacerix@waveinabox.net">nacerix@waveinabox.net</a><br>
Blog: <a href="http://nacerix.blogspot.com" target="_blank">http://nacerix.blogspot.com</a><br>
Twitter: nacerix<br>
Identi.ca: nacerix<br>
<a href="http://paper.li/nacerix" target="_blank">http://paper.li/nacerix</a><br>
<a href="http://netvibes.net/nacerix" target="_blank">http://netvibes.net/nacerix</a><br>
<a href="https://launchpad.net/~adamou-nacer" target="_blank">https://launchpad.net/~adamou-nacer</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a><br>
<br>
iQEcBAEBAgAGBQJO3MeyAAoJELZpU0pKyeBuHE8IAJfRdSej3XkX4C95bQhaT+kC<br>
yF0Ctraxkm6f4NIo6k74+o73UiXXgBZ/NeF1aXBbmte+sRaXWo8km79KS7WZayzt<br>
YDx2X3lEs0uA3IjjWqO1cBYpr5MiEmURsTkyl+szW9q3YnOp/wLPICUBjaMeFbmN<br>
nqrqb8Rs6zJiqm13Wo9FTTqmoZVSttyxVdaiFOPn+TwhOvUeazcjKAh1cFVf+NR2<br>
5btKv7AEQy5zHOAdTWdG0ep6pS7a4PIFqeVSWf4PaG1xB+WH22a3Kh+7SeUowG8W<br>
waOyCAiDcaib9Lj9z7lyDXYTjg8Bbkapv8VuucIYlenRJNgaYHu33tiPFxcnO8w=<br>
=lT9v<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
AfrICANN mailing list<br>
<a href="mailto:AfrICANN@afrinic.net">AfrICANN@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/africann" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/africann</a><br>
<br>
<br>
_______________________________________________<br>
AfrICANN mailing list<br>
<a href="mailto:AfrICANN@afrinic.net">AfrICANN@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/africann" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/africann</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
AfrICANN mailing list<br>
<a href="mailto:AfrICANN@afrinic.net">AfrICANN@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/africann" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/africann</a><br>
<br>
<br>
End of AfrICANN Digest, Vol 58, Issue 6<br>
***************************************<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
AfrICANN mailing list<br>
<a href="mailto:AfrICANN@afrinic.net">AfrICANN@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo.cgi/africann" target="_blank">https://lists.afrinic.net/mailman/listinfo.cgi/africann</a><br>
<br>
<br>
End of AfrICANN Digest, Vol 58, Issue 7<br>
***************************************<br>
</blockquote></div><br><br clear="all"><br>-- <br><i><b><span style="color: rgb(0, 0, 153);">Joseph MANDJOLO MUSH</span></b></i><br><i style="color: rgb(0, 153, 0);"><b>Chef de Service Qualités des Services<br>Assistant Technique et Maintenance <br>
projet gestion nom de domaine .CD</b></i><br><i style="color: rgb(204, 0, 0);"><b>SCPT/DRC</b></i><br><i><span style="color: rgb(204, 51, 204);">Mobile: +243 9 98 42 91 25</span><br style="color: rgb(204, 51, 204);"><span style="color: rgb(204, 51, 204);"> +243 89 80 86 263</span><br style="color: rgb(204, 51, 204);">
<span style="color: rgb(204, 51, 204);">B.P. 1130 Kinshasa 1</span><br>e-mail: <a href="mailto:josemandjolo@ocpt.cd" target="_blank">josemandjolo@ocpt.cd</a><br> <a href="mailto:josemandjolo@hotmail.com" target="_blank">josemandjolo@hotmail.com</a></i><br>
<br>