RE: [FRnOG] [TECH] RFC 6441: Time to Remove Filters for Previously Unallocated IPv4 /8s

2011-11-29 Par sujet Michel Py 
> Paul Rolland a écrit:
> Il y a eu/il y a encore des operateurs qui ne font pas bcp de
> controles pour s'assurer de la correspondance "mon client/son
> AS/ses adresses", et pour mettre en place les filtres adequats.

Pour une bonne raison: ça prend du temps donc coûte de l'argent ;-)


> Rémi Bouhl a écrit:
> Je tombe un peu des nues, là. On ne laisse pas n'importe qui causer
> en BGP, faut montrer "patte blanche", être identifiable.. nope?

C'est un peu naïf comme point de vue. Il y a des FAI spécialisés dans 
l'hébergement de spammeurs.

En plus, il y a pas mal de cas légitimes pour annoncer un préfixe (ou 
sous-préfixe) qui sur le papier ne t'appartient pas:

- 2 organisations pas vraiment reliées administrativement mais proches 
géographiquement et qui veulent un "plan B" du genre "si mon upstream tombe tu 
annonces mon préfixe, si ton upstream tombe j'annonce ton préfixe". 

- 2 organisations qui ré-arrangent leurs activités: fusion, séparation, vente 
d'une division, etc. C'est très souvent nécessaire que pendant une période de 
transition, l'une annonce l'un des préfixes de l'autre. Cadeau Bonux: c'est 
souvent une solution temporaire, non-documentée, à grand renfort de routes 
statiques et autres bidouilles innommables, et qui va durer...5 ans :-D

Dans les 2 cas au-dessus, les outils de filtrage automatisés basés sur WHOIS et 
similaire sont parfois une plaie car ils gèrent mal ou pas du tout la situation.

Donc il faut trouver un équilibre entre l'anarchie sans filtrage et la parano 
totale, et ce n'est pas souvent facile.

Pour en revenir aux bogons, il a des gens qui te diront que le remède était 
pire que le mal: tout le monde n'utilisait pas Team CYMRU, et c'est bien connu 
que chaque fois qu'ICANN allouait un /8 à un RIR, les premiers utilisateurs du 
/8 en question devaient passer un temps fou à faire débogonner leur préfixe.

Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RFC 6441: Time to Remove Filters for Previously Unallocated IPv4 /8s

2011-11-29 Par sujet ポール・ロラン 
Bonjour,

On Tue, 29 Nov 2011 16:41:14 +0100
Rémi Bouhl  wrote:

> Bonjour,
> 
> Le 29/11/2011 16:31, Stephane Bortzmeyer a écrit :
> 
> > L'idée était d'empêcher l'usage de ces préfixes IP non alloués. Ils
> > représentaient des cibles tentantes, par exemple pour un spammeur qui
> > voulait des adresses jetables et non traçables : on trouve un bloc non
> > alloué, on l'annonce en BGP (puisqu'il n'est pas alloué, il n'y a pas
> > de risque de collision), on envoie son spam et on arrête l'annonce BGP.
> 
> Je tombe un peu des nues, là. On ne laisse pas n'importe qui causer en 
> BGP, faut montrer "patte blanche", être identifiable.. nope?
> 
> Du coup, comment quelqu'un peut prendre le risque d'usurper des adresses 
> IPv4 qui ne lui ont pas été attribuées, s'en servir pour spammer, puis 
> tout effacer, sans se faire attraper? C'est franchement autre chose que 
> d'infecter une machine.

Tant que tu avais des adresses IP "non-allouees", donc avec personne pour
pleurer si tu les squattes, et des operateurs qui sont d'accord pour
prendre ton argent sans poser de questions, c'est plutot facile :
 - tu achetes un routeur,
 - tu deviens client du-dit operateur,
 - tu montes ta session avec lui, 
 - tu annonces tes adresses.
Il y a eu/il y a encore des operateurs qui ne font pas bcp de controles
pour s'assurer de la correspondance "mon client/son AS/ses adresses", et
pour mettre en place les filtres adequats.

Aujourd'hui, differents types d'operateurs se trouvent :
 - les "je m'en moque" : toujours pas compris, ils acceptent tout et gerent
   ensuite,
 - les "je te demande un papier et je configure en fonction" : la, je ne
   peux pas te garantir les controles qui sont faits en interne, mais
   globalement, tu ne peux pas annoncer si tu n'as pas indique avant,
 - les "je fais de l'autoconf a partir des bases RIRs" : ca necessite
   d'avoir les bons outils, ca impose que tout le monde maintienne les
   bases RIRs, mais ca doit aussi pouvoir se gerer si tu veux faire du
   squat d'IP (certains ont joue a ca via des rachats de societes qui
   avaient des blocs non utilises).
et surement des combinaisons plus ou moins savantes selon les regles en
place et leur respect ;)

Bref, tout n'est pas rose dans le monde de l'Internet... et oui, on peut
arriver a des choses "surprenantes" ;)

Paul

-- 
Paul RollandE-Mail : rol(at)witbe.net
CTO - Witbe.net SA  Tel. +33 (0)1 47 67 77 77
Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99
F-92057 Paris La DefenseRIPE : PR12-RIPE

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un
navigateur "Some people dream of success... while others wake up and work
hard at it" 

"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that 10
or 15 years from now, she will come to me and say 'Daddy, where were you
when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RFC 6441: Time to Remove Filters for Previously Unallocated IPv4 /8s

2011-11-29 Par sujet Cédric Perronnet 
On 29/11/2011 16:41, Rémi Bouhl wrote:
> Bonjour,
>
> Le 29/11/2011 16:31, Stephane Bortzmeyer a écrit :
>
>> Allez hop, une page se tourne, finie la chasse aux bogons IPv4...
>>
>> http://www.bortzmeyer.org/6441.html
>>
>> 
>>
>> Auteur(s) du RFC: L. Vegoda (ICANN)
>
> [...]
>
>> L'idée était d'empêcher l'usage de ces préfixes IP non alloués. Ils
>> représentaient des cibles tentantes, par exemple pour un spammeur qui
>> voulait des adresses jetables et non traçables : on trouve un bloc non
>> alloué, on l'annonce en BGP (puisqu'il n'est pas alloué, il n'y a pas
>> de risque de collision), on envoie son spam et on arrête l'annonce BGP.
>
>
> Je tombe un peu des nues, là. On ne laisse pas n'importe qui causer en
> BGP, faut montrer "patte blanche", être identifiable.. nope?
>
> Du coup, comment quelqu'un peut prendre le risque d'usurper des
> adresses IPv4 qui ne lui ont pas été attribuées, s'en servir pour
> spammer, puis tout effacer, sans se faire attraper? C'est franchement
> autre chose que d'infecter une machine.
>
> Il y a des pays où ils s'en foutent totalement?
>
> Si du monde sur la liste a des retours d'expérience à ce sujet, des
> exemples de cas où c'est arrivé, je suis preneur pour enrichir ma
> culture Internet (et, accessoirement, ça pourrait m'être utile pour un
> projet).
>
> Merci d'avance.
>
> Rémi.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
http://www.bortzmeyer.org/pakistan-pirate-youtube.html


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] RFC 6441: Time to Remove Filters for Previously Unallocated IPv4 /8s

2011-11-29 Par sujet Rémi Bouhl 

Bonjour,

Le 29/11/2011 16:31, Stephane Bortzmeyer a écrit :


Allez hop, une page se tourne, finie la chasse aux bogons IPv4...

http://www.bortzmeyer.org/6441.html



Auteur(s) du RFC: L. Vegoda (ICANN)


[...]


L'idée était d'empêcher l'usage de ces préfixes IP non alloués. Ils
représentaient des cibles tentantes, par exemple pour un spammeur qui
voulait des adresses jetables et non traçables : on trouve un bloc non
alloué, on l'annonce en BGP (puisqu'il n'est pas alloué, il n'y a pas
de risque de collision), on envoie son spam et on arrête l'annonce BGP.



Je tombe un peu des nues, là. On ne laisse pas n'importe qui causer en 
BGP, faut montrer "patte blanche", être identifiable.. nope?


Du coup, comment quelqu'un peut prendre le risque d'usurper des adresses 
IPv4 qui ne lui ont pas été attribuées, s'en servir pour spammer, puis 
tout effacer, sans se faire attraper? C'est franchement autre chose que 
d'infecter une machine.


Il y a des pays où ils s'en foutent totalement?

Si du monde sur la liste a des retours d'expérience à ce sujet, des 
exemples de cas où c'est arrivé, je suis preneur pour enrichir ma 
culture Internet (et, accessoirement, ça pourrait m'être utile pour un 
projet).


Merci d'avance.

Rémi.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] RFC 6441: Time to Remove Filters for Previously Unallocated IPv4 /8s

2011-11-29 Par sujet Stephane Bortzmeyer 
Allez hop, une page se tourne, finie la chasse aux bogons IPv4...

http://www.bortzmeyer.org/6441.html



Auteur(s) du RFC: L. Vegoda (ICANN)





Pour limiter certains risques de sécurité, des opérateurs réseaux 
filtraient en entrée de leur réseau les adresses IP non encore allouées 
(dites "bogons"). Les adresses IPv4 étant désormais totalement épuisées 
, cette 
pratique n'a plus lieu d'être et ce RFC demande donc que ces filtres 
soient démantelés.

L'idée était d'empêcher l'usage de ces préfixes IP non alloués. Ils 
représentaient des cibles tentantes, par exemple pour un spammeur qui 
voulait des adresses jetables et non traçables : on trouve un bloc non 
alloué, on l'annonce en BGP (puisqu'il n'est pas alloué, il n'y a pas 
de risque de collision), on envoie son spam et on arrête l'annonce BGP. 
Pour éviter cela, et d'autres attaques analogues, l'habitude s'est 
prise de filtrer les "bogons", ces préfixes non alloués. Certains 
opérateurs rejetaient les annonces BGP pour ces "bogons", d'autres 
bloquaient sur le pare-feu les paquets ayant une adresse source dans 
ces préfixes non alloués. Ces pratiques étaient largement documentées 
par exemple sur le site de référence sur les bogons 
.

Cette pratique a toujours posé des problèmes, notamment celui de la 
« débogonisation ». Lorsqu'un préfixe qui n'était *pas* alloué le 
devient, il faut toute une gymnastique pour le retirer des filtres 
existants, sachant que beaucoup de ces filtres ne sont que rarement mis 
à jour . 
On voit ainsi des messages sur les listes de diffusion d'opérateurs 
réseaux avertissant de l'arrivée prochaine d'un nouveau préfixe et 
demandant qu'il soit supprimé des filtres. Voici deux exemples de ces 
annonces en 2004  et en 2005 
. Pour permettre aux opérateurs de tester que tout va bien après 
cette suppression, les RIR mettent souvent un "beacon", un amer, dans 
le préfixe, une adresse IP qu'on peut pinguer pour tester, comme le 
recommande le RFC 5943. Tout ce travail faisait donc que la chasse aux 
"bogons" était contestée depuis longtemps 
.

À noter (section 2) que le terme de "bogon" a été défini dans le RFC 
3871, qui recommande leur blocage. Ce même RFC 3871 décrit en détail le 
problème que posent les "bogons" et la raison de leur éradication. Le 
terme de martien, plus flou (il vient du RFC 1208), est appliqué à 
toutes sortes de paquets dont l'adresse source est anormale (dans le 
DNS, il a un autre sens, celui de paquet de réponse à une question qui 
n'a pas été posée).

La section 3 représente le cœur du RFC : elle formule la nouvelle 
règle. Celle-ci, tenant compte de l'épuisement des adresses IPv4 
 est simple : 
tous les préfixes IPv4 sont désormais alloués ou réservés. Il ne faut 
donc filtrer que les réservés. Les autres peuvent désormais tous être 
une source légitime de trafic IP. La chasse aux "bogons" et les 
difficultés de la débogonisation faisant partie du folklore de 
l'Internet depuis très longtemps, c'est donc une page d'histoire qui se 
tourne. (Les adresses IPv6 sont, elles, loin d'être toutes allouées et 
ne sont donc pas concernées.)

La section 4 rappelle que l'autorité pour cette liste de préfixes 
réservés est le RFC 5735, ou son éventuel futur successeur. On y trouve 
par exemple les adresses privées du RFC 1918 ou bien les adresses 
réservées à la documentation du RFC 5737. Les listes de "bogons" qu'on 
trouve sur le réseau, comme celle de TeamCymru 
 sont 
désormais réduites à ce groupe.

À noter que l'assertion « Tous les préfixes sont désormais alloués » ne 
vaut que pour les préfixes de longueur 8 (les « /8 ») distribués aux 
RIR. Certains peuvent filtrer à un niveau plus fin, en distinguant dans 
ces /8 les adresses que les RIR ont affectés de celles qui ne le sont 
pas encore. Comme le rappelle la section 3.2, cette pratique est 
risquée, les affectations par les RIR changeant vite. Le RFC demande 
donc que, si on a de tels filtres, ils soient changés au moins une fois 
par jour.

Pour en apprendre plus sur les "bogons", on peut regarder la bonne 
analyse faite par BGPmon . On 
voit finalementt peu d'annonces BGP de "bogons" (6 seulement en 2011), 
la plupart pour le préfixe 198.18.0.0/15 des mesures de performance 
(RFC 5735). Un bon résumé des "bogons" et de la débogonisation avait 
été fait par Dave Deitrich en 2005 
.


---
Liste de dif