RE: [FRnOG] Firewall HTTP

2010-12-02 Par sujet Florian Coulmier
NETASQ est aussi une solution capable d'agréger plusieurs liens (routé
ou en point à point), de faire de la QoS et surtout de l'analyse
protocolaire pour des prix très abordables. 

De mémoire le prix du matériel Netasq est assez élevé ou alors les équipements 
les moins sont très bridés en fonctionnalités.
Pour information, on trouve des Fortinet entrées de gamme à 250/300 euros et 
qui sont déjà bien placés en termes de puissance et fonctions. 
Petit point supplémentaire, concernant toujours le coût, ils fonctionnent sur 
une alimentation 12V ce qui fait faire quelques économies de courant sur le 
long terme par rapport à un serveur double alimentation sur lequel on installe 
un Linux/BSD.


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



Re: [FRnOG] Firewall HTTP

2010-12-01 Par sujet guillaume . monnette
Il y a dix ans, on disait qu'il était moins cher d'acheter des tuyaux plus 
gros, que de s’embêter à faire de la QoS. Je ne sais pas si cette maxime est 
toujours vrai aujourd'hui.

Et la QoS inter-opérateurs, on sait faire?




- Mail Original -
De: Rémy Sanchez remy.sanc...@hyperthese.net
À: frnog@FRnOG.org
Envoyé: Jeudi 25 Novembre 2010 20h01:47 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [FRnOG] Firewall HTTP

On 11/25/2010 03:29 PM, Pierre Chapuis wrote:
 On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
 remy.sanc...@hyperthese.net wrote:
 
 Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si
 on résume, la QoS ne sert à rien quand on a assez de bande passante, et
 elle n'est pas assez efficace quand y'a pas assez de bande passante...
 
 Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien
 et est même néfaste.
 
 Je sais que tu ne veux pas en parler mais j'ai été exactement dans le même
 cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la
 taille
 du tuyau, la solution est de compter les paquets et/ou les octets qui
 passent
 dedans pour chaque utilisateur et de faire en sorte que la somme totale ne
 dépasse pas ton débit maximal. Pas besoin de regarder dans les paquets. Ça
 n'est pas de la QoS, c'est du best effort.
 
 Si tu commences à faire de la QoS, tu vas avoir deux profils
 d'utilisateurs :
 les geeks qui vont comprendre ce qui passe et tunneler dedans, et les gens
 normaux qui vont se faire avoir.
 
 En pratique, une simple limite en upload et en download par jour, semaine
 et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou moins
 obligé de regarder dans les paquets IP quand même si tu es relié à un
 réseau
 du type Renater, mais c'est un autre problème...
 

Donc le DiffServ  co c'est une vaste fumisterie ? On s'est amusé à
utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne
fait de QoS ?

Je voudrais pas faire le mec relou qui met du temps à comprendre (même
si à priori cette discussion gonfle tout le monde :/), mais j'ai du mal
à me mettre en tête que tout ça ait été inventé pour rien... C'est quand
même pas des clowns à l'IETF non ?

-- 
Rémy Sanchez

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



Re: [FRnOG] Firewall HTTP

2010-12-01 Par sujet David Ramahefason
Le 1 décembre 2010 13:36,  guillaume.monne...@free.fr a écrit :
 Il y a dix ans, on disait qu'il était moins cher d'acheter des tuyaux plus 
 gros, que de s’embêter à faire de la QoS. Je ne sais pas si cette maxime est 
 toujours vrai aujourd'hui.

 Et la QoS inter-opérateurs, on sait faire?

Si c'est ton réseau que tu utilises via plusieurs opérateurs (VPN) tu
as le CSC (Carrier Supporting Carrier) qui existe mais je ne sais pas
s'il est utilisé le problèmes politiques que ca implique ne sont
sans doute pas neutre :)





 - Mail Original -
 De: Rémy Sanchez remy.sanc...@hyperthese.net
 À: frnog@FRnOG.org
 Envoyé: Jeudi 25 Novembre 2010 20h01:47 GMT +01:00 Amsterdam / Berlin / Berne 
 / Rome / Stockholm / Vienne
 Objet: Re: [FRnOG] Firewall HTTP

 On 11/25/2010 03:29 PM, Pierre Chapuis wrote:
 On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
 remy.sanc...@hyperthese.net wrote:

 Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si
 on résume, la QoS ne sert à rien quand on a assez de bande passante, et
 elle n'est pas assez efficace quand y'a pas assez de bande passante...

 Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien
 et est même néfaste.

 Je sais que tu ne veux pas en parler mais j'ai été exactement dans le même
 cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la
 taille
 du tuyau, la solution est de compter les paquets et/ou les octets qui
 passent
 dedans pour chaque utilisateur et de faire en sorte que la somme totale ne
 dépasse pas ton débit maximal. Pas besoin de regarder dans les paquets. Ça
 n'est pas de la QoS, c'est du best effort.

 Si tu commences à faire de la QoS, tu vas avoir deux profils
 d'utilisateurs :
 les geeks qui vont comprendre ce qui passe et tunneler dedans, et les gens
 normaux qui vont se faire avoir.

 En pratique, une simple limite en upload et en download par jour, semaine
 et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou moins
 obligé de regarder dans les paquets IP quand même si tu es relié à un
 réseau
 du type Renater, mais c'est un autre problème...


 Donc le DiffServ  co c'est une vaste fumisterie ? On s'est amusé à
 utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne
 fait de QoS ?

 Je voudrais pas faire le mec relou qui met du temps à comprendre (même
 si à priori cette discussion gonfle tout le monde :/), mais j'ai du mal
 à me mettre en tête que tout ça ait été inventé pour rien... C'est quand
 même pas des clowns à l'IETF non ?

 --
 Rémy Sanchez

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





-- 
David Ramahefason
r...@netfacile.net
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-12-01 Par sujet Stéphane Le Men

Rémi Bouhl wrote:


Avec une option à cliquer je gère la QoS moi-même pour les barbus.


J'estime cela tres peu probable car le S de QoS, implique une ligne
de facture par service. Je conçois que cela ait de l'interet, mais
pas dans les conditions actuelles des contrats, un seul niveau de
service est à vendre.

Le protocol qui gere ce genre de chose, c'est diameter rfc 3588

Voici un produit, par exemple, qui permet de creer un tel service.
http://www.juniper.net/us/en/local/pdf/datasheets/1000148-en.pdf

Comme le dit la doc, ecrire n'est pas trop difficile. C'est deployer,
administrer et surtout faire évoluer qui l'est.

Ce document fait une présentation simple:

http://www.imsforum.org/files/Public_Documents68/*IMS%20NGN%20White%20Papers_Executive%20Summaries/Billing%20in%20IMS%20Exec.pdf

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



Re: [FRnOG] Firewall HTTP

2010-12-01 Par sujet Sébastien FOUTREL
Hello, j'ai lu avec passion l'ensemble des interventions de ce thread.

Tout d'abord pour répondre a ta question, tu peux le developper le
firewall HTTP mais en fait iptables avec la partie l7 et une base de
signature protocolaire doit pouvoir faire ça. Y a plus qu'a creer un
projet sur sourceforge et commencer a faire une IHM.

Sinon, il existe des produits commerciaux faisant cela tres bien, par
exemple les Fortigate font de l'analyse protocolaire et te permettent
de faire de la prioritisation de flux, du shapping global et/ou per-ip
sur un sous-ensemble du HTTP. ca reconnait pas mal de produit merdeux
qui s'encapsulent dans le HTTP et tu peux meme creer toi-meme des
signatures supplementaires.

Ensuite pour répondre a ton probleme de BP :
Acheter des tuyaux au sens ISP du terme c'est souvent non realisable
(4 mois de GC) et toujours hors de portée du budget surtout si tu n'as
pas le budget d'un petit pays...
Si tu fonctionne deja avec des liaisons grand pubic type machinbox a
30E, tu peux raccorder plusieurs de celle-ci a un Fortigate et faire
ensuite de la repartition automatique ou pas de tes users sur les
differents liens.
Faire de la repartition par protocole aussi.

Ok mon discours fait la part belle a cette marque mais je n'en connais
pas beaucoup qui rivalise a ce niveau de prix, fonctionnalités,
facilité d'emploi.

Pour ceux qui liront, oui c'est absolument pas compliant avec la
neutralité du net mais dans le monde actuel (les bisounours tournent
sur une broche dans la cheminée des chefs d'états) le pragmatisme
l'emporte souvent sur l'idealisme.

My 2 cents sous la neige...

Cordialement

Le 24 novembre 2010 14:51, Rémy Sanchez remy.sanc...@hyperthese.net a écrit :

 Bonjour à tous,

 Les dernières tendances en terme de n'importe quoi consistent à faire passer
 à peu près tout ce qu'on peut par du HTTP, à tel point qu'on a pratiquement
 remplacé le TCP. Après tout, toutes les applications web passent par du
 HTTP, or c'est plutôt vaste : distribution de contenu, messagerie
 instantanée, flux vidéo, traitement de texte, ... Sans oublier toutes les
 applications qui utilisent le HTTP (par exemple MSN) pour faire passer leur
 protocole en environnement restreint, ou carrément les tunnels.

 En bref, le port 80 est toujours ouvert, soit directement, soit à travers un
 proxy. Et c'est la porte ouverte à toutes les fenêtres... En fin de compte,
 serait-il cohérent d'imaginer une application analogue à un firewall, qui au
 lieu de s'en prendre au TCP s'attaque directement au HTTP ?

 Ça y est je vois déjà tous les canons pointés en ma direction pour me
 signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans le genre.
 C'est d'ailleurs pour ça que je demande si l'idée est cohérente ou si c'est
 du grand n'importe quoi. Cependant, je pense à des fonctionnalités qui m'ont
 l'air difficile à configurer dans les outils pré-cités, comme par exemple
 différencier les types de flux pour y assigner des priorités (long poll et
 dérivées, page standard, gros fichier, accélérateur de téléchargements,
 ...), reconnaître les sous protocoles (comme au dessus, MSN), reconnaître
 les tunnels, s'en prendre aussi au HTTPS, ... En bref, pouvoir traiter tout
 ce qui passe par du HTTP comme un flux TCP/IP avec un numéro de protocole et
 un tag pour la QoS.

 Les outils que j'ai rencontré jusque là ne permettent pas de faire ça
 simplement (Squid, pf, iptables pour ceux que j'ai vraiment utilisé), après
 étant relativement novice en réseau j'ai assez peu touché aux autres outils
 et aux appliances proprio, donc mon panorama est restreint. Donc qu'en
 pensez vous, lecteurs avisés de FRnOG ? Un tel outil serait-il utile ? Pour
 qui ? Qu'y verriez vous à l'intérieur ? Est-ce que j'ai complètement fumé la
 moquette ?

 NDLR : l'idée ici est de débattre des fonctionnalités d'un tel produit, non
 de la manière dont on pourrait les implémenter...

 Allez c'est parti pour une après midi à prendre des baffes :)

 --
 Rémy Sanchez
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


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



Re: [FRnOG] Firewall HTTP

2010-11-27 Par sujet Jeremie Le Hen
On Thu, Nov 25, 2010 at 08:01:47PM +0100, Rémy Sanchez wrote:
 Donc le DiffServ  co c'est une vaste fumisterie ? On s'est amusé à
 utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne
 fait de QoS ?

Moi je l'ai utilisé lorsque j'avais encore un ADSL avec un upload à
16 Ko/s.  Un envoi de fichier faisait ramer ma session SSH.  Du coup
j'ai utilisé mon packet filter pour mettre de priorité sur certains flux :
OpenSSH met un ToS différent selon que ce soit de l'interactif ou du
transfert de fichier par exemple.  Le DNS passait en priorité aussi.
Mais c'était pour le réseau chez moi, donc les règles étaient facile à
déterminer et à appliquer :-).  Quand je suis passé chez Free avec un
upload à 128 Ko/s (à l'époque, maintenant c'est limité à 100), je n'ai
plus eu le problème.  Cette modeste expérience prouve pour moi que les
personnes qui disent qu'il te manque de la bande passante ont raison.
Mais d'un autre côté, s'il te manque des moyens pour l'augmenter, ta
question initiale pour catégoriser le traffic HTTP est parfaitement
légitime pour pouvoir faire de la QoS efficacement, puisque les ports
n'ont plus de sens.

Pour le download, avec FreeBSD, tu peux faire du ALTQ.  Ca permet de
faire du Random Early Drop, permettant à TCP d'ajuster sa bande passante
avant « qu'il ne soit trop tard ».  En plus de cela, tu peux configurer
un partage de bande passante équitable entre tes utilisateurs avec la
notion d'emprunt : lorsqu'un utilisateur n'utilise pas toute la bande
passante qui lui est réservée.  Plutôt efficace.

-- 
Jeremie Le Hen

Humans are born free and equal.  But some are more equal than others.
Coluche
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-27 Par sujet Pierre Chapuis


Rémy Sanchez remy.sanc...@hyperthese.net a écrit :
Donc le DiffServ  co c'est une vaste fumisterie ? On s'est amusé à
utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne
fait de QoS ?

Je n'ai jamais trop compris l'intérêt de DiffServ, il a les mêmes inconvénients 
que ToS a priori.

Je vois 3 possibilités :

- c'est l'expéditeur qui choisit la valeur (ie. je veux que mon paquet aille 
lentement...) ;
- c'est un routeur qui le fait en connaissant le contenu du paquet (DPI) mais 
dans ce cas il y a souvent des mécanismes non-IP plus efficaces) ;
- c'est un routeur qui le fait uniquement en fonction de la source (mais comme 
au-dessus).

Si on ne suppose pas que l'utilisateur est un bisounours, où est vraiment 
l'intérêt ?

(Disclaimer : je n'ai pas lu la RFC et je n'y ai jamais touché en vrai...)

-- 
Pierre 'catwell' Chapuis
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-27 Par sujet Sylvain Vallerot



Rémy Sanchez a écrit :

Bon, avant toute chose j'aimerais préciser que dans mon mail de base je
ne parlais absolument pas d'optimiser mon cas particulier, mais bien de
lancer le débat sur l'intérêt de considérer le HTTP comme un protocole
de transport dans les firewalls, par ce que le web change toussa,


Sur ce point ça me rappelle étrangement que la NSA enguirlandait les
français de peur de voir des lois débiles contournées systématiquement
par des tunnels chiffrés. Effectivement plus on pousse les gens à
contourner des mesures restrictives débiles, plus ils le font et plus
on se met soi-même en situation de devoir 1°) gérer une sécurité 
inutile, 2°) passer pour un con qui applique des mesures débiles et

3°) voir le problème ressurgir, mais encore plus complexe qu'avant.

Donc dans la perspective où la restriction vient du fournisseur de
l'accès, l'intérêt du DPI sur HTTP serait nul si on ouvrait tout
simplement les ports normaux pour que les gens utilisent internet
normalement.
C'est vrai dans les entreprises qui voient leurs salariés comme des
ennemis (et qui, le temps de la journée de travail, sont leur FAI),
et c'est vrai en téléphonie mobile chez les opérateurs qui vendent
à leurs clients du pas-internet (naté, filtré, et firewallé).

Il y a aussi, en seconde lecture, dans ta question initiale, le pb
que ce sont les éditeurs de services qui font passer n'importe quoi.
Ben là, on a un problème technique mais la réponse peut effectivement
passer par la priorisation correcte des services. On s'en fout si
des abrutis font passer de la voix dans HTTP, du moment que la vraie
voix est mieux priorisée sur les bons canaux, la voix sur HTTP sera
juste toute pourrie, et ce sera tant pis pour elle.

Donc pourquoi tout simplement laisser les gens utiliser les bons
outils ou les mauvais, et en déduire ce qui marche et ce qui ne
marche pas ?

Pourquoi aller déglinguer les réseaux dans le sens des usages, s'il
sont techniquement mauvais ?



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



Re: [FRnOG] Firewall HTTP

2010-11-27 Par sujet Stéphane Le Men

Michel Py wrote:

un jour ou l'autre quelqu'un avec un 
téléphone 2G 1/2 ou 3G va ouvrir une des pages en question a coté 
d'un de ses potes qui a un téléphone 4G, ça va ramer, et ce n'est 
pas le QOS qui va faire le réseau 3G afficher la page remplie de

merdasse sous HTTP à la vitesse du 4G.


Si je vous dis que la QoS, c'est exactement la même chose que
Wall-Street, pas une imitation, un vrai Wall-Street en vrai, et ce qui
se vend et s'echange en temps reel, se sont ces places dans les files 
d'attente d'acces aux interfaces du réseaux, est-ce que vous ne

changez pas d'avis ?

Vous ne pensez pas qu'avec une QoS, genre Wall-Street, vous ne
trouverez pas client pour acheter vos premieres places dans vos
files d'attente au bon prix ?

Et que pour ceux qui auront acheté ces places, est-ce que cette
merdasse http ne peut pas arriver plus vite sur un 3G, qu'un vulgaire
abonné en queue file d'attente avec son télephone 4G ?

Je reconnais que gerer un Wall Street QoS sur un réseau entier,
avec des millions d'utilisateurs, sur des milliers de destinations,
ce n'est pas le même type d'applications à gérer que BGP ou un IGP.
Il y a des SAN, des machines dans tous les sens, qui observent le
trafic, et agissent le cas échéant pour etre sûre que chaque client,
est _servi_ selon son rang de client. Et qu'il n'abuse pas.

Les opérateurs mobiles gerent déja une application vraiment temps
reel qui maintient le niveau 2 entre le mobile et le reseau et qui 
marche bien. Ce serait dommage pour eux d'en sacrifier le résultat

à une politique archaïque digne d'une épicerie soviétique, puisqu'en
faisant un éffort (certain), ils peuvent s'offrir un Wall-Street.

Le corollaire, c'est que la Quality of Service des uns, est bien la
Quality of Famine des autres, mais, on ne devrait pas en faire
un drame, puisse que dans le monde réel, il a vraiment des gens sur
Terre qui ne mange pas à leur faim, alors de la famine réseau, cela
devrait être tout à fait acceptable.
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-27 Par sujet Rémi Bouhl
Le 27/11/10, Stéphane Le Menle...@neptune.fr a écrit :
 Michel Py wrote:

un jour ou l'autre quelqu'un avec un
téléphone 2G 1/2 ou 3G va ouvrir une des pages en question a coté
d'un de ses potes qui a un téléphone 4G, ça va ramer, et ce n'est
pas le QOS qui va faire le réseau 3G afficher la page remplie de
merdasse sous HTTP à la vitesse du 4G.

 Si je vous dis que la QoS, c'est exactement la même chose que
 Wall-Street, pas une imitation, un vrai Wall-Street en vrai, et ce qui
 se vend et s'echange en temps reel, se sont ces places dans les files
 d'attente d'acces aux interfaces du réseaux, est-ce que vous ne
 changez pas d'avis ?

 Vous ne pensez pas qu'avec une QoS, genre Wall-Street, vous ne
 trouverez pas client pour acheter vos premieres places dans vos
 files d'attente au bon prix ?

L'idée est très bonne. L'opérateur peut parfaitement prendre en compte
la qualité de service demandée par l'utilisateur, même si on n'est pas
dans le monde des bisounours, à condition de facturer cette QoS.

Vous avez 1 Go/mois prioritaire, le reste illimité n'est pas
prioritaire. Vous pouvez acheter des Go prioritaires en supplément.

À l'utilisateur de décider s'il veut que ce soit sa VoIP ou son
torrent qui soit prioritaire, c'est lui qui marque les paquets.

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



RE: [FRnOG] Firewall HTTP

2010-11-27 Par sujet Michel Py
 Stéphane Le Men a écrit:
 Vous ne pensez pas qu'avec une QoS, genre Wall-Street,
 vous ne trouverez pas client pour acheter vos premieres
 places dans vos files d'attente au bon prix ?

Tu n'es pas le premier à y penser; c'est une bonne idée, mais le client n'est 
généralement pas assez sophistiqué pour comprendre QOS. C'est beaucoup plus 
facile de vendre un service en disant moi j'ai 5 mégabits et mon concurrent il 
en a que 2 que de vendre du QOS. N'oublies pas que tu t'adresses à des bœufs 
qui n'y comprennent rien, bas au bidouilleur dans l'âme qui lit la liste du 
FRnOG.

Et puis c'est plus facile à expliquer aux copains, aussi. Moi, j'ai ai une plus 
grosse que toi :-D
Bande passante, bien sûr.

 Et que pour ceux qui auront acheté ces places, est-ce
 que cette merdasse http ne peut pas arriver plus vite
 sur un 3G, qu'un vulgaire abonné en queue file d'attente
 avec son télephone 4G ?

Non. Tu peux faire tout ce que tu veux avec QOS, une page avec des photos 
partout et de la vidéo qui joue sans le son pour les pub, ça marchera toujours 
plus vite avec un plus gros tuyau.


 Je reconnais que gerer un Wall Street QoS sur un
 réseau entier, avec des millions d'utilisateurs, sur
 des milliers de destinations, ce n'est pas le même
 type d'applications à gérer que BGP ou un IGP. Il y
 a des SAN, des machines dans tous les sens, qui
 observent le trafic, et agissent le cas échéant pour
 etre sûre que chaque client, est _servi_ selon son
 rang de client. Et qu'il n'abuse pas.

C'est bien là ou est le problème: c'est une usine à gaz, et c'est un 
investissement. Vu la durée de vie relativement faible des réseaux mobiles (dès 
que 4G commence à décoller tu peux être sûr que tout le monde travaillera déjà 
sur 5G), l'opérateur se trouve plus ou moins dans la position de faire un choix 
entre investir dans une infra qui est déjà sur le départ et investir dans une 
nouvelle infra qui a des tuyaux plus gros. C'est la course à l'armement, ça 
fait marcher le commerce donc ça va continuer. 

C'est un peu la même chose pour FTTH: AMHA, si tu de déploies pas GigE 
aujourd'hui, dans 5 ans tu vas de faire bouffer tout cru par ceux qui le font.

Et pareil pour WiFi: pourquoi se décarcasser à optimiser un 802.11b à 11mbps? 
Si tu as 100 utilisateurs sur 11mpbs ça commence à coincer, vaut mieux 
remplacer par du 802.11g à 54mbps. Ou même du 802.11N, quite à remplacer le 
matos autant mettre une nouvelle antenne pendant que tu es sur site.


 Le corollaire, c'est que la Quality of Service des uns,
 est bien la Quality of Famine des autres, mais, on ne
 devrait pas en faire un drame, puisse que dans le monde
 réel, il a vraiment des gens sur Terre qui ne mange pas
 à leur faim, alors de la famine réseau, cela devrait
 être tout à fait acceptable.

Cette partie n'a jamais été un problème. C'est entièrement une histoire de gros 
sous; tout le monde n'est pas convaincu que QOS ça peut rapporter plus que ça 
ne coûte, à long terme, et l'investissement dans le gros tuyau a moins 
d'incertitudes. Le QOS c'est super quand ton temps n'est pas facturable et que 
tu récupères gratos le Cisco ou le Juniper du bureau (ou que tu l'achètes sur 
eBay pour pas cher).



 Rémi Bouhl a écrit:
 À l'utilisateur de décider s'il veut que ce soit sa VoIP ou son
 torrent qui soit prioritaire, c'est lui qui marque les paquets.

La je trouve que tu rêves un peu, peut-être que certains de tes étudiants vont 
faire ça, mais pas Mme Michu.


 Sylvain Vallerot a écrit:
 [snip]

Très bien écrit, le reste de ta contrib.

 Donc pourquoi tout simplement laisser les gens utiliser
 les bons outils ou les mauvais, et en déduire ce qui
 marche et ce qui ne marche pas ?

Parce que a) la plupart n'y comprennent rien et b) même si ils comprenaient, il 
y a bien des fois ou tu ne peux rien faire. 

Michel.


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



Re: [FRnOG] Firewall HTTP

2010-11-27 Par sujet Rémi Bouhl
Le 27/11/10, Michel Pymic...@arneill-py.sacramento.ca.us a écrit :
 Rémi Bouhl a écrit:
 À l'utilisateur de décider s'il veut que ce soit sa VoIP ou son
 torrent qui soit prioritaire, c'est lui qui marque les paquets.

 La je trouve que tu rêves un peu, peut-être que certains de tes étudiants
 vont faire ça, mais pas Mme Michu.

Sa machinbox va le faire toute seule, et il pourra régler.
Comme tout le bordel que fait une machinbox (NAT, VoIP, TVoIP,
redirection de port..) qu'un geek sait faire tout seul, mais que la
machinbox fait avec des réglages par défaut qui vont à tout le monde
et une interface Web pour le bidouilleur du dimanche.

On marque la priorité sur les quelques protocoles qui nécessitent
vraiment de la vitesse (jeux vidéos, vidéoconférence) et basta. Et tu
vends le tout sous le nom d'offre spécial joueur, un peu comme le
mode patate chez Free, l'instabilité en moins.
Avec une option à cliquer je gère la QoS moi-même pour les barbus.

Non?

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



RE: [FRnOG] Firewall HTTP

2010-11-27 Par sujet Michel Py
 Rémi Bouhl a écrit:
 À l'utilisateur de décider s'il veut que ce soit sa VoIP ou son
 torrent qui soit prioritaire, c'est lui qui marque les paquets.

 La je trouve que tu rêves un peu, peut-être que certains
 de tes étudiants vont faire ça, mais pas Mme Michu.

 Sa machinbox va le faire toute seule, et il pourra régler.
 Comme tout le bordel que fait une machinbox (NAT, VoIP,
 TVoIP, redirection de port..) qu'un geek sait faire tout
 seul, mais que la machinbox fait avec des réglages par
 défaut qui vont à tout le monde et une interface Web pour
 le bidouilleur du dimanche.

Pour en revenir au problème original de Rémy Sanchez, est-ce que la machinbox 
va faire du DPI pour prendre en compte la tendance merdasse encapsulée dans 
http?

Tous les combien il va falloir mettre à jour le firmware de la machinbox pour 
s'adapter aux changements dans ce domaine?

Et tu fais quoi quand tu as 100 étudiants derrière 1 machinbox?


 Et tu vends le tout sous le nom d'offre spécial joueur, un
 peu comme le mode patate chez Free, l'instabilité en moins.

Ah ouai ouai vaut pas gonfler celles de Mr Michu quand il patate à Call of Duty 
Black Ops, si c'est pas fluide et que la voix team est hachée il va appeler le 
support pendant des heures et faire chier tout le monde.


 Avec une option à cliquer je gère la QoS moi-même pour les barbus.

Je préfère avoir l'IP publique sur l'Ethernet et faire ma bidouille moi-même 
avec mon routeur, mais faut pas rêver une machinbox avec voix et télé ça va 
être difficile de touver un FAI qui te laissera bidouiller dedans.

La machinbox c'est l'exemple parfait de pourquoi faire du QOS; je ne dis pas 
qu'il ne faut pas le faire, ce que je dis c'est qu'il ne faut pas y passer plus 
de temps que nécessaire et croire que QOS ça va permettre de passer 4 flux 
1080p sur une machinbox aDSL 1.5 mbit, ou d'y mettre 100 étudiants dessus.

Si tu as un problème de congestion sur l'infra elle-même, affamer certains 
utilisateurs qui ont le plan de base pour donner plus de patate à ceux qui 
payent plus, c'est une arme à double tranchant:
si tu n'es pas le seul FAI dans le coin, à force d'avoir faim tes utilisateurs 
de base risquent d'aller voir ailleurs si on les nourrit pas mieux.

Et on en revient au problème des gros sous: est-ce qu'il vaut mieux investir 
dans la machinbox v3 
avec un gros tuyau, ou investir dans QOS pour la machinbox v2? 
 
Michel.

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



Re: [FRnOG] Firewall HTTP

2010-11-26 Par sujet Antoine Versini

On 11/25/10 20:01, Rémy Sanchez wrote:


Donc le DiffServ  co c'est une vaste fumisterie ? On s'est amusé à
utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne
fait de QoS ?


Cela m'étonnerait fortement. L'utilisation du champs TOS des en-têtes IP 
pour effectuer un marquage DSCP des paquets issus de plate-formes de 
téléphonie/voix sur IP et de diffusion vidéo est un must dans tous les 
réseaux IP d'opérateurs.


Les routeurs et commutateurs utilisent cette information pour assigner 
les paquets dans des files d'attentes prioritaire par rapport au traffic 
best effort (Youtube/Youporn/Faceplook.)


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



Re: [FRnOG] Firewall HTTP

2010-11-26 Par sujet Rémy Sanchez
On 11/26/2010 12:56 PM, e-t172 wrote:
 Mon opinion, qui n'engage que moi, est que tu te trompes de problème.
 Ton problème n'est pas que tes utilisateurs ne peuvent pas faire de la
 VoIP pendant qu'ils ont Rapidshare qui tourne à plein régime. Ton
 problème c'est que tes utilisateurs puissent se marcher sur les pieds,
 c'est-à-dire que quelqu'un qui fait du DDL puisse faire chier son voisin
 qui lui n'a rien demandé et ne demande qu'à faire son entretien
 d'embauche via VoIP.
 
 Autrement dit, tu veux nous parler de différenciation par service, moi
 je veux te parler de différenciation par utilisateur.
 
 Pour moi, la meilleure solution à ton problème consiste à rétablir la «
 justice » (Fair Queuing) entre les utilisateurs. C'est-à-dire quelqu'un
 qui ouvre 1000 téléchargements ne puisse pas mettre tous les autres à
 genoux sous la congestion. Ça devrait même être une règle élémentaire de
 sécurité : un individu qui empêche tous les autres d'utiliser le réseau,
 on appelle ça un Denial of Service, non ?
 
 La solution est simple : au lieu de faire des queues par type de service
 (ToS), tu fais des queues par utilisateur (IP source). C'est possible
 sous Linux avec ESFQ, je ne sais pas pour les autres plateformes.
 
 Avec cette solution, tu as la garantie que la bande passante est
 découpée de manière équitable entre les différents hôtes de ton réseau.
 Imaginons que ton tuyau fait 10 Mbits, et que deux utilisateurs font du
 DDL. Eh bien les deux auront 5 Mbits chacun, même si l'un ouvre 100
 connexions et l'autre 2. Plus intéressant : si quelqu'un fait du DDL et
 qu'un autre veut faire de la VoIP, la VoIP aura toujours priorité par
 rapport au DDL car elle consomme beaucoup moins de bande passante et
 n'atteindra donc jamais le quota. La VoIP passera donc comme sur des
 roulettes, et toute la bande passante nécessaire sera prise sur le
 téléchargement du voisin (qui l'aura bien cherché). Dans tous les cas
 l'utilisation du tuyau est optimale : par exemple le téléchargeur aura 9
 Mbits et la VoIP en aura 1, car elle ne demande pas plus. Par contre, le
 point important ici, c'est que ces 1 Mbits sont *garantis* par le système.
 
 Le principal avantage est qu'il est impossible de tricher :
 l'utilisateur aura beau tenter de tunelliser ou de forger les champs ToS
 de ses paquets IP, ça ne changera strictement rien car tout est basé sur
 son adresse IP, qu'il est impossible de falsifier (enfin, j'espère).
 
 Un problème persiste cependant : si tu es vraiment fauché au niveau de
 la taille de ton tuyau, tu pourrais te retrouver avec 100 téléchargeurs
 sur un tuyau de 1 Mbits, ce qui fait que chaque personne se retrouve
 avec 10 kbits… et là, c'est l'horreur et même la VoIP ne passe plus.
 Comme cela a déjà été dit sur ce fil la vraie solution est d'augmenter
 la taille du tuyau, mais si ce n'est pas une option, je suggèrerais
 d'ajouter un burst qui permettrait à chaque utilisateur de dépasser son
 quota à condition qu'il ne le fasse pas trop longtemps.
 
 Ainsi les téléchargeurs auraient le burst épuisé en permanence car ils
 pompent en continu, mais par contre ceux qui font autre chose auraient
 du burst en réserve et gagneraient donc la priorité sur les
 téléchargeurs, jusqu'à un certain point. Par exemple avec un burst de 50
 Mo, c'est plus que suffisant pour y caser une longue conversation en
 VoIP, qui passera comme sur des roulettes même avec 1 téléchargeurs
 fous à côté. En d'autres termes, le système « punit » automatiquement
 ceux qui pompent en continu sur le tuyau.
 

Bon, avant toute chose j'aimerais préciser que dans mon mail de base je
ne parlais absolument pas d'optimiser mon cas particulier, mais bien de
lancer le débat sur l'intérêt de considérer le HTTP comme un protocole
de transport dans les firewalls, par ce que le web change toussa, et mon
cas particulier de débit trop faible n'était là que pour expliquer d'où
me venait l'idée, que j'ai considérablement élargie depuis. Bref je l'ai
dit assez de fois.

Je suis entièrement d'accord avec le fait qu'il faille limiter la bande
passante par utilisateur et non par connexion ! Et merci beaucoup pour
tes arguments ainsi que tes informations, car c'est bien plus développé
que ce que j'ai trouvé jusqu'à présent, ça va m'aider à avancer :) .

@Rémi: oui nos utilisateurs sont authentifiés, donc on a une IP (enfin
un subnet) par utilisateur.

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


RE: [FRnOG] Firewall HTTP

2010-11-26 Par sujet Michel Py
 Michel Py a écrit :
 un large réseau interne ou tout est permis; en tant que FAI les
 données des clients sont privées, mais en tant qu'opérateur
 d'entreprise (ici) le réseau est le tien, pas besoin de demander
 d'autorisation pour sniffer le trafic des employés.

 Christophe Baegert a écrit:
 En es-tu bien sûr ?

 Gaël Martinez a écrit:
 En general ici aux Etats-Unis (je pense que Michel fait reference
 a ca) quand tu te connectes a un systeme (corporate, gouvernement
 ou autre ) tu recois toujours une banniere (motd) t'informant que
 tu es surveille, et que tu renonces a ton droit de vivre quand tu
 te connectes :)  D'un point de vue audit et legal, cette banniere
 est super important et est strictement regulee et auditee.

Absolument. A noter que la bannière n'est pas ce qui t'enlèves le droit de 
vivre, c'est uniquement pour couper le sifflet aux petits malins qui auraient 
des envies de jouer le moi je n'étais pas au courant pendant un procès. En 
général on te fait aussi signer une addition au contrat de travail qui précise 
ça aussi: le système informatique de l'entreprise appartient à l'entreprise et 
donc par le simple fait de l'utiliser tu reconnais le droit de l'entreprise de 
regarder ce que tu fais. C'est totalement gonflant, d'ailleurs: sniffer le 
trafic d'un employé qui surfe au lieu de bosser pour le virer, c'est un 
problème de RH pas d'ingénierie de réseau. Comme si j'avais que ça à faire, 
faut aussi que je change de casquette pour mettre un képi, je m'en serais passé.

Pour les FAI ce n'est pas pareil, ton FAI ne peut pas sniffer tes données ; 
d'après ce que je comprends, les statistiques anonymes sont généralement 
autorisées.


 Michel Py a écrit:
 Non il y a des utilisations valides, mais une chose est
 certaine: ni QOS ni rien d'autre ne vont transformer un
 petit tuyau en un tuyau plus gros. [..]

 Stéphane Le Men a écrit:
 Aussi surprenant que cela puisse être, les opérateurs mobiles
 comptent bien réaliser cette prouesse, de faire grossir les
 petits tuyaux radios, en déployant RHOC (rfc5795 et autres)
 pour la partie voix, et avoir un réseau tout ip. C'est par le
 calcul distribué, et la surveillance de l'activité des
 utilisateurs que les opérateurs mobiles maximiseront
 l'utilisation des ressources du réseau, et donc leur ROI.

Je suis un peu sceptique pour la partie IP, et voici pourquoi: la nature ayant 
horreur du vide, les radios 4G vont provoquer la création de pages web mobile 
pour les gros tuyaux (avec, sans aucun doute, un tas de cochonneries, vidéos et 
autres applets encapsulés dans HTTP); un jour ou l'autre quelqu'un avec un 
téléphone 2G 1/2 ou 3G va ouvrir une des pages en question a coté d'un de ses 
potes qui a un téléphone 4G, ça va ramer, et ce n'est pas le QOS qui va faire 
le réseau 3G afficher la page remplie de merdasse sous HTTP à la vitesse du 4G.


Eh c'est vendredi! Et ici c'est un vendredi spécial: Black Friday. Après 
s'être gavé de dinde hier pour Thanksgiving, le bon américain va faire ses 
courses.

Une télé HD 1080p DLP de 152 cm (60) pour $597 (451 euros):
http://www.frys.com/ShopCartServlet?purchase=6294340
Qui dit mieux!

Michel

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



Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Julien Gormotte

Hé, moi j'ai une solution !

Un serveur, meme un vieux Pentium 75 devrait suffire, 4 Mo de ram, ca 
tournera nickel.

Apres, un squid, un peu de poudre verte, et voilà.

On dit merci qui ?

...

Merci la poudre verte !
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Guillaume Esnault
Bonjour à tous,

Cette discussion me met mal à l'aise.

Ce genre d'outil relève de l'écoute sur le contenu ou le langage
(Layer7). 

C'est comme si nous faisions des écoutes téléphoniques automatiques.
Selon ce qui est dit il serait fait certaines actions.

Certain organismes comme la NSA (Echelon) le pratiquent à grande
échelle.

Ce n'est pas légal et c'est dangereux. (cpdt, il n'y a pas encore de
jurisprudence, il me semble)

Il est certain que chez Digicube nous ne pratiquerons jamais ce genre de
chose. 

Bien à vous,

Guillaume Esnault
Digicube sas


Le jeudi 25 novembre 2010 à 10:29 +0100, Julien Gormotte a écrit :
 Hé, moi j'ai une solution !
 
  Un serveur, meme un vieux Pentium 75 devrait suffire, 4 Mo de ram, ca 
  tournera nickel.
  Apres, un squid, un peu de poudre verte, et voilà.
 
  On dit merci qui ?
 
  ...
 
  Merci la poudre verte !
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 


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



Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet François
J'ai entendu dire (sans retrouver la source écrite) que les écoutes
aléatoires et anonymes étaient autorisées. Et qu'en ce moment les
autorités en usent et abusent.

Pour revenir au sujet, puisque l'on parlait de voip et de skype, je
crois savoir que skype peut utiliser le port 80 mais pas HTTP. et
seulement en cas de filtrage sur d'autres ports.
Bref il faut peut-être éduquer les utilisateurs pour dire que le proxy
n'est là que pour sortir en http. (après on peut effectivement se
poser la question de l'utilité du proxy dans ce cas, mais c'est un
autre débat).

---
François



2010/11/25 Guillaume Esnault gesna...@digicube.fr:
 Bonjour à tous,

 Cette discussion me met mal à l'aise.

 Ce genre d'outil relève de l'écoute sur le contenu ou le langage
 (Layer7).

 C'est comme si nous faisions des écoutes téléphoniques automatiques.
 Selon ce qui est dit il serait fait certaines actions.

 Certain organismes comme la NSA (Echelon) le pratiquent à grande
 échelle.

 Ce n'est pas légal et c'est dangereux. (cpdt, il n'y a pas encore de
 jurisprudence, il me semble)

 Il est certain que chez Digicube nous ne pratiquerons jamais ce genre de
 chose.

 Bien à vous,

 Guillaume Esnault
 Digicube sas


 Le jeudi 25 novembre 2010 à 10:29 +0100, Julien Gormotte a écrit :
 Hé, moi j'ai une solution !

  Un serveur, meme un vieux Pentium 75 devrait suffire, 4 Mo de ram, ca
  tournera nickel.
  Apres, un squid, un peu de poudre verte, et voilà.

  On dit merci qui ?

  ...

  Merci la poudre verte !
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/



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


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



Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Rémi Bouhl
Le 25/11/10, Françoisaifs...@gmail.com a écrit :

 Pour revenir au sujet, puisque l'on parlait de voip et de skype, je
 crois savoir que skype peut utiliser le port 80 mais pas HTTP. et
 seulement en cas de filtrage sur d'autres ports.

Skype est conçu pour contourner à peu près tout ce qui est
contournable, et AMHA il est capable de s'encapsuler de façon à passer
par un proxy HTTP sans problèmes. Ce truc n'est pas fair-play vis à
vis du réseau, c'est un soft vraiment vicieux, et par ce qu'il fait
sur le réseau, et par ce qu'il fait sur le poste où il est installé.

 Bref il faut peut-être éduquer les utilisateurs pour dire que le proxy
 n'est là que pour sortir en http. (après on peut effectivement se
 poser la question de l'utilité du proxy dans ce cas, mais c'est un
 autre débat).

Le proxy sert de cache donc évite de re-télécharger plusieurs fois les
mêmes contenus, tout simplement? Bon, avec le Web 2.0 c'est moins
utile.

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



Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Pierre Chapuis
On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez 
remy.sanc...@hyperthese.net wrote:


Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que 
si
on résume, la QoS ne sert à rien quand on a assez de bande passante, 
et
elle n'est pas assez efficace quand y'a pas assez de bande 
passante...


Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien
et est même néfaste.

Je sais que tu ne veux pas en parler mais j'ai été exactement dans le 
même
cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la 
taille
du tuyau, la solution est de compter les paquets et/ou les octets qui 
passent
dedans pour chaque utilisateur et de faire en sorte que la somme totale 
ne
dépasse pas ton débit maximal. Pas besoin de regarder dans les paquets. 
Ça

n'est pas de la QoS, c'est du best effort.

Si tu commences à faire de la QoS, tu vas avoir deux profils 
d'utilisateurs :
les geeks qui vont comprendre ce qui passe et tunneler dedans, et les 
gens

normaux qui vont se faire avoir.

En pratique, une simple limite en upload et en download par jour, 
semaine

et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou moins
obligé de regarder dans les paquets IP quand même si tu es relié à un 
réseau

du type Renater, mais c'est un autre problème...

--
Pierre 'catwell' Chapuis

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



Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet frederic


Pour ne pas gérer la congestion, on évite la congestion.

Gérer la congestion est une solution onéreuse et complexe.

a+


On Thu, 25 Nov 2010 15:29:34 +0100, Pierre Chapuis 
catw...@archlinux.us wrote:

On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net wrote:

Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce 
que si
on résume, la QoS ne sert à rien quand on a assez de bande passante, 
et
elle n'est pas assez efficace quand y'a pas assez de bande 
passante...


Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à 
rien

et est même néfaste.

Je sais que tu ne veux pas en parler mais j'ai été exactement dans le 
même
cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la 
taille
du tuyau, la solution est de compter les paquets et/ou les octets qui 
passent
dedans pour chaque utilisateur et de faire en sorte que la somme 
totale ne
dépasse pas ton débit maximal. Pas besoin de regarder dans les 
paquets. Ça

n'est pas de la QoS, c'est du best effort.

Si tu commences à faire de la QoS, tu vas avoir deux profils 
d'utilisateurs :
les geeks qui vont comprendre ce qui passe et tunneler dedans, et les 
gens

normaux qui vont se faire avoir.

En pratique, une simple limite en upload et en download par jour, 
semaine
et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou 
moins
obligé de regarder dans les paquets IP quand même si tu es relié à un 
réseau

du type Renater, mais c'est un autre problème...


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



Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Stephane Kanschine
Selon Rémi Bouhl remibo...@gmail.com:

 Le proxy sert de cache donc évite de re-télécharger plusieurs fois
 les mêmes contenus, tout simplement? Bon, avec le Web 2.0 c'est
 moins utile.

On en reparle quand les protocoles de streaming à base de chunk seront
un peu plus répandus :-)

Et sinon, cette discussion hors sujet est bientôt finie ?

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



Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Rémy Sanchez
On 11/25/2010 11:20 AM, Guillaume Esnault wrote:
 Cette discussion me met mal à l'aise.
 
 Ce genre d'outil relève de l'écoute sur le contenu ou le langage
 (Layer7). 
 
 C'est comme si nous faisions des écoutes téléphoniques automatiques.
 Selon ce qui est dit il serait fait certaines actions.
 
 Certain organismes comme la NSA (Echelon) le pratiquent à grande
 échelle.
 
 Ce n'est pas légal et c'est dangereux. (cpdt, il n'y a pas encore de
 jurisprudence, il me semble)
 
 Il est certain que chez Digicube nous ne pratiquerons jamais ce genre de
 chose. 

L'usage d'un proxy tu classes ça comment alors ? Quand tu mets un proxy
pour le cache c'est le même topo, sauf qu'en plus tu gardes les
données... Et quand tu met un proxy pour bloquer les accès à certains
sites, c'est encore pire (même si très franchement ne n'adhère pas du
tout avec cette pratique là).

C'est pas un peu extrême de comparer d'un côté la prioritarisation de
certains flux pour améliorer le service qu'ils rendent et de l'autre
côté Echelon ?...

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Rémy Sanchez
On 11/25/2010 11:52 AM, Rémi Bouhl wrote:
 Le proxy sert de cache donc évite de re-télécharger plusieurs fois les
 mêmes contenus, tout simplement? Bon, avec le Web 2.0 c'est moins
 utile.

Même pas, vu qu'avec le web 2.0 tout le monde va sur les^Wle même site
(ça commence par face et ça finit par book), et qu'en plus tout le monde
regarde le même contenu, et que tout ça est stocké sur un CDN, on se
retrouve avec pas mal de contenu à mettre en cache vu par tout le monde.

-- 
Rémy Sanchez





signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Rémy Sanchez
On 11/25/2010 03:29 PM, Pierre Chapuis wrote:
 On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
 remy.sanc...@hyperthese.net wrote:
 
 Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si
 on résume, la QoS ne sert à rien quand on a assez de bande passante, et
 elle n'est pas assez efficace quand y'a pas assez de bande passante...
 
 Bien résumé. Encore plus court : la QoS sur un réseau IP ne sert à rien
 et est même néfaste.
 
 Je sais que tu ne veux pas en parler mais j'ai été exactement dans le même
 cas que toi avec ta résidence étudiante. Si tu ne peux pas limiter la
 taille
 du tuyau, la solution est de compter les paquets et/ou les octets qui
 passent
 dedans pour chaque utilisateur et de faire en sorte que la somme totale ne
 dépasse pas ton débit maximal. Pas besoin de regarder dans les paquets. Ça
 n'est pas de la QoS, c'est du best effort.
 
 Si tu commences à faire de la QoS, tu vas avoir deux profils
 d'utilisateurs :
 les geeks qui vont comprendre ce qui passe et tunneler dedans, et les gens
 normaux qui vont se faire avoir.
 
 En pratique, une simple limite en upload et en download par jour, semaine
 et/ou mois suffit dans ce genre de contexte. Après, tu es plus ou moins
 obligé de regarder dans les paquets IP quand même si tu es relié à un
 réseau
 du type Renater, mais c'est un autre problème...
 

Donc le DiffServ  co c'est une vaste fumisterie ? On s'est amusé à
utiliser de précieux octets dans les entêtes IP pour rien ? Personne ne
fait de QoS ?

Je voudrais pas faire le mec relou qui met du temps à comprendre (même
si à priori cette discussion gonfle tout le monde :/), mais j'ai du mal
à me mettre en tête que tout ça ait été inventé pour rien... C'est quand
même pas des clowns à l'IETF non ?

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


RE: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Michel Py
 Guillaume Esnault a écrit:
 Cette discussion me met mal à l'aise.

Grandis. C'est une liste de FAI, l'interception et l'analyse des flux, même si 
c'est souvent une Albanerie, ça fait partie du boulot. Et la requête originale, 
même si tout le monde pense plus ou moins que ça ne servirait pas à 
grand-chose, était fondée sur des bonnes intentions.

En plus, nombre de lecteurs opèrent un large réseau interne ou tout est permis; 
en tant que FAI les données des clients sont privées, mais en tant qu'opérateur 
d'entreprise (ici) le réseau est le tien, pas besoin de demander d'autorisation 
pour sniffer le trafic des employés.

 Ce genre d'outil relève de l'écoute sur le contenu ou le
 langage (Layer7). C'est comme si nous faisions des écoutes
 téléphoniques automatiques. Selon ce qui est dit il serait
 fait certaines actions.

Il y a des fois ou c'est nécessaire et où des décisions doivent être prises. 
Par exemple, si j'ai à choisir entre le film de cul de Bob et la série à l'eau 
de rose d'Alice, je choisis Bob :-D


 Rémy Sanchez a écrit:
 Bon et finalement, est-ce que la QoS sert à quelque chose?
 Par ce que si on résume, la QoS ne sert à rien quand on a
 assez de bande passante, et elle n'est pas assez efficace
 quand y'a pas assez de bande passante...

Pas 100% vrai mais néanmoins très souvent vrai. Très, très souvent.


 Pierre Chapuis a écrit:
 Bien résumé. Encore plus court : la QoS sur un réseau IP
 ne sert à rien et est même néfaste.

Je n'irais pas aussi loin que Pierre ceci dit; quand on transporte de la voix 
la QOS est nécessaire, si il y a suffisamment de BP. Contrairement à ce que 
beaucoup de gens pensent, non pas pour préserver la qualité de la voix (ce qui 
peut se faire en réservant la BP) mais pour maximiser la part allouée aux 
données quand la voix n'est pas en service.

 Si tu commences à faire de la QoS, tu vas avoir deux profils
 d'utilisateurs: les geeks qui vont comprendre ce qui passe et
 tunneler dedans, et les gens normaux qui vont se faire avoir.

C'est souvent le cas, en effet. Ceci dit si tu limites une certaine BP par 
utilisateur ce n'est pas la solution non plus: jamais rapide.

 Donc le DiffServ  co c'est une vaste fumisterie ? On s'est
 amusé à utiliser de précieux octets dans les entêtes IP pour 
 rien ? Personne ne fait de QoS ? Je voudrais pas faire le mec
 relou qui met du temps à comprendre (même si à priori cette
 discussion gonfle tout le monde :/), mais j'ai du mal à me
 mettre en tête que tout ça ait été inventé pour rien... 

Non il y a des utilisations valides, mais une chose est certaine: ni QOS ni 
rien d'autre ne vont transformer un petit tuyau en un tuyau plus gros. QOS, 
c'est la cerise sur le gâteau QUAND tu as suffisamment de BP. Quand le tuyau 
n'est pas assez gros, ne rien faire est souvent la meilleure des solutions: 
quoi que tu fasses, ça ne va pas changer le fait que tu as besoin d'un plus 
gros tuyau, donc ce que tu fais c'est déshabiller Pierre pour habiller Paul et 
au bout du compte tu as déplacé le problème mais pas résolu et tu as perdu 
beaucoup de temps et d'énergie pour revenir à la case départ sans toucher les 
$200.


 C'est quand même pas des clowns à l'IETF non ?

Euh non mais il y en a un petit nombre qui devraient arrêter de fumer la 
moquette, ceci dit.


Michel.

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



Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Christophe Baegert
Bonjour,

Le 25/11/2010 23:30, Michel Py a écrit :
 un large réseau interne ou tout est permis; en tant que FAI les données des 
 clients sont privées, mais en tant qu'opérateur d'entreprise (ici) le réseau 
 est le tien, pas besoin de demander d'autorisation pour sniffer le trafic des 
 employés.

En es-tu bien sûr ?

Cordialement,

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



Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Gael
2010/11/25 Christophe Baegert c.baegert-lis...@lixium.fr

 Bonjour,

 Le 25/11/2010 23:30, Michel Py a écrit :
  un large réseau interne ou tout est permis; en tant que FAI les données
 des clients sont privées, mais en tant qu'opérateur d'entreprise (ici) le
 réseau est le tien, pas besoin de demander d'autorisation pour sniffer le
 trafic des employés.

 En es-tu bien sûr ?

 Cordialement,

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


En general ici aux Etats-Unis (je pense que Michel fait reference a ca)
quand tu te connectes a un systeme (corporate, gouvernement ou autre ) tu
recois toujours une banniere (motd) t'informant que tu es surveille, et que
tu renonces a ton droit de vivre quand tu te connectes :)  D'un point de vue
audit et legal, cette banniere est super important et est strictement
regulee et auditee.

Cordialement
-- 
Gaël Martinez


Re: [FRnOG] Firewall HTTP

2010-11-25 Par sujet Mattieu Baptiste
2010/11/25 Rémy Sanchez remy.sanc...@hyperthese.net:

 C'est quand
 même pas des clowns à l'IETF non ?

IPv6 ?

-- 
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Mathias WMN
Bonjour,

Ce que tu cherches, n'est-il pas du filtrage de niv 7 ?
L'idée est de déterminée selon un pattern le flux, de le tagger et
ensuite appliquer les régles que tu souhaites (filtrages, QoS ...).

Cordialement,

Mathias

Le mercredi 24 novembre 2010 à 14:51 +0100, Rémy Sanchez a écrit :
 Bonjour à tous,
 
  Les dernières tendances en terme de n'importe quoi consistent à faire 
  passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on a 
  pratiquement remplacé le TCP. Après tout, toutes les applications web 
  passent par du HTTP, or c'est plutôt vaste : distribution de contenu, 
  messagerie instantanée, flux vidéo, traitement de texte, ... Sans 
  oublier toutes les applications qui utilisent le HTTP (par exemple MSN) 
  pour faire passer leur protocole en environnement restreint, ou 
  carrément les tunnels.
 
  En bref, le port 80 est toujours ouvert, soit directement, soit à 
  travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... En 
  fin de compte, serait-il cohérent d'imaginer une application analogue à 
  un firewall, qui au lieu de s'en prendre au TCP s'attaque directement au 
  HTTP ?
 
  Ça y est je vois déjà tous les canons pointés en ma direction pour me 
  signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans le 
  genre. C'est d'ailleurs pour ça que je demande si l'idée est cohérente 
  ou si c'est du grand n'importe quoi. Cependant, je pense à des 
  fonctionnalités qui m'ont l'air difficile à configurer dans les outils 
  pré-cités, comme par exemple différencier les types de flux pour y 
  assigner des priorités (long poll et dérivées, page standard, gros 
  fichier, accélérateur de téléchargements, ...), reconnaître les sous 
  protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en prendre 
  aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par du 
  HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour la 
  QoS.
 
  Les outils que j'ai rencontré jusque là ne permettent pas de faire ça 
  simplement (Squid, pf, iptables pour ceux que j'ai vraiment utilisé), 
  après étant relativement novice en réseau j'ai assez peu touché aux 
  autres outils et aux appliances proprio, donc mon panorama est 
  restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel 
  outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ? 
  Est-ce que j'ai complètement fumé la moquette ?
 
  NDLR : l'idée ici est de débattre des fonctionnalités d'un tel produit, 
  non de la manière dont on pourrait les implémenter...
 
  Allez c'est parti pour une après midi à prendre des baffes :)
 

-- 
Mathias WOLFF
Directeur Associé
WM Networks

Adresse : 149 Avenue du Maine 75014 PARIS

GSM : 06.79.59.43.32

Opérateur d'opérateurs.


smime.p7s
Description: S/MIME cryptographic signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 14:57:56 +0100, Mathias WMN 
m.wo...@wm-networks.fr wrote:

Bonjour,

Ce que tu cherches, n'est-il pas du filtrage de niv 7 ?
L'idée est de déterminée selon un pattern le flux, de le tagger et
ensuite appliquer les régles que tu souhaites (filtrages, QoS ...).

Cordialement,


Probablement que ça rentre dans cette catégorie, mais ce que je veux 
surtout c'est pouvoir considérer le HTTP comme un protocole de niveau 4. 
Le nombre d'applications web et/ou passant par du HTTP est devenu 
tellement important que je pense qu'on a plutôt intérêt se mettre à la 
vitesse supérieure et considérer ce qui passe dans le HTTP comme des 
protocoles à part entière.


Sinon avec quoi tu ferais ton filtrage de niveau 7 ? Une recherche 
rapide me donne ce genre de résultats : 
http://firewalls.smile.fr/L-offre-open-source-en-matiere-de-filtrage/Filtrage-niveau-7, 
qui préconise l'usage de Squid, ce qui comme je le disais dans le mail 
précédent n'est pas vraiment adapté à ce genre d'usages... (ou alors, 
j'ai raté un épisode :) )


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet guillaume . monnette
Si nous etiames vendreday, j'irions plus loin...


Après la concentration de tous les protocoles au dessus de TCP (ce qui était 
deja une hérésie), puis de HTTP (n'en parlons pas)... Bienvenue vers la 
concentration vers deux fqdn : www.google.com et www.facebook.com

Je remarque en effet, que 
1/ De plus en plus de marketeux rafolent des www.facebook.com/x à la place 
d'un site. C'est pratique, car ça permet de profiler et FB est accessible via 
les pseudos acces web des téléphones mobile.
2/ Et de plus en plus de collègues utilisent les *...@gmail.com car c'est le 
webmail le moins filtré en entreprise...



- Mail Original -
De: Rémy Sanchez remy.sanc...@hyperthese.net
À: frnog@frnog.org
Envoyé: Mercredi 24 Novembre 2010 14h51:56 GMT +01:00 Amsterdam / Berlin / 
Berne / Rome / Stockholm / Vienne
Objet: [FRnOG] Firewall HTTP


 Bonjour à tous,

 Les dernières tendances en terme de n'importe quoi consistent à faire 
 passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on a 
 pratiquement remplacé le TCP. Après tout, toutes les applications web 
 passent par du HTTP, or c'est plutôt vaste : distribution de contenu, 
 messagerie instantanée, flux vidéo, traitement de texte, ... Sans 
 oublier toutes les applications qui utilisent le HTTP (par exemple MSN) 
 pour faire passer leur protocole en environnement restreint, ou 
 carrément les tunnels.

 En bref, le port 80 est toujours ouvert, soit directement, soit à 
 travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... En 
 fin de compte, serait-il cohérent d'imaginer une application analogue à 
 un firewall, qui au lieu de s'en prendre au TCP s'attaque directement au 
 HTTP ?

 Ça y est je vois déjà tous les canons pointés en ma direction pour me 
 signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans le 
 genre. C'est d'ailleurs pour ça que je demande si l'idée est cohérente 
 ou si c'est du grand n'importe quoi. Cependant, je pense à des 
 fonctionnalités qui m'ont l'air difficile à configurer dans les outils 
 pré-cités, comme par exemple différencier les types de flux pour y 
 assigner des priorités (long poll et dérivées, page standard, gros 
 fichier, accélérateur de téléchargements, ...), reconnaître les sous 
 protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en prendre 
 aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par du 
 HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour la 
 QoS.

 Les outils que j'ai rencontré jusque là ne permettent pas de faire ça 
 simplement (Squid, pf, iptables pour ceux que j'ai vraiment utilisé), 
 après étant relativement novice en réseau j'ai assez peu touché aux 
 autres outils et aux appliances proprio, donc mon panorama est 
 restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel 
 outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ? 
 Est-ce que j'ai complètement fumé la moquette ?

 NDLR : l'idée ici est de débattre des fonctionnalités d'un tel produit, 
 non de la manière dont on pourrait les implémenter...

 Allez c'est parti pour une après midi à prendre des baffes :)

-- 
 Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Stephane Le Men



Ce qui me gêne un peu plus c'est que c'est une des briques du grand
firewall Chinois/Iranien/Français (inutile de rayer la mention inutile : 
la Loi LOPSSI nous prépare des choses sympa dans ce domaine...).


Pas besoin d'aller si loin, tous votre trafic http sur mobile passe par un
Firewall http, mais il fire pas la police, juste la facture



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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémi Bouhl
Le 24/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit :

  Après, vu à quel point les numéros de contorsioniste par HTTP se
  démocratisent, laisser le HTTP sans aucun filtrage donne l'impression de
  laisser tous les ports ouvert.

Il y a 10 ans:
Laisser les ports ouverts en sortie sans aucun filtrage me donne
l'impression qu'on pourra me pirater.

Ça donne la situation actuelle dont tu es insatisfait (tout le monde
fait n'importe quoi via HTTP).

Donc tu vas rajouter une couche.

Prépare-toi, dans 10 ans, à devoir lutter contre les accès HTTP qui
font semblant d'être du vrai surf mais en fait si on met un quad-core
pour faire du DPI on se rend compte que c'est du VPN encapsulé dans
des pseudo-pages Web.

Du coup je propose la solution couillue: ouvrir les vannes sur les
autres ports.
Laisser sortir ce qui était encapsulé en HTTP, afin qu'HTTP redevienne
ce qu'il n'aurait pas du cesser d'être.

Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et en
RDP, inutile de faire des tunnels HTTP.

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Raphaël Jacquot
On Wed, 2010-11-24 at 15:55 +0100, Rémi Bouhl wrote:

 Prépare-toi, dans 10 ans, à devoir lutter contre les accès HTTP qui
 font semblant d'être du vrai surf mais en fait si on met un quad-core
 pour faire du DPI on se rend compte que c'est du VPN encapsulé dans
 des pseudo-pages Web.

pas la peine d'attendre 10 ans, au vu des multiples process http-tunnel
qui semblent tourner sur les machines dédiées aux étudiants par ici

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Yves Dubromelle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 24/11/2010 15:47, guillaume.monne...@free.fr a écrit :
 Après la concentration de tous les protocoles au dessus de TCP (ce qui était 
 deja une hérésie)

Sur ce point j'aimerais que tu développe un peu, je ne comprend pas bien.
C'est peut-être dû à mon jeune âge, mais on m'a toujours appris que sur
Internet la couche transport du modèle OSI était fournie par TCP ou UDP
selon les besoins.
Une explication ?

Yves Dubromelle
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAkztKxYACgkQ8IhKGszP0SoGRAD/Qwohzn+tWqisCz6wMDRdiR2c
0DMROC7GZZKAqpMH/YIA/1zaHnEXBd9iJRdTZLXxkewbgpOmi74CDAu9jqzuq79g
=avO1
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Raphaël Jacquot
On Wed, 2010-11-24 at 16:10 +0100, Rémy Sanchez wrote:

  Pour situer mon contexte et l'origine de mon idée : je m'occupe du 
  réseau dans une résidence étudiante, avec un débit très limité par 
  rapport au nombre d'utilisateurs. 

ne faudrait il pas commencer par la ? genre, augmenter le débit
disponible de maniere substantielle, plutot que d'essayer de gerer la
rareté de maniere sous-optimale ?

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet David Ramahefason
 Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau
 dans une résidence étudiante, avec un débit très limité par rapport au
 nombre d'utilisateurs. Et on ne peut pas dire que tout soit bloqué sur le
 réseau, on ouvre les ports à la demande. Seulement, j'aimerais que le débile
 de base qui télécharge 10 trucs en même temps n'empêche pas le type qui a
 entretient d'embauche de faire de la VoIP (le problème n'existe plus au
 fait, on a trouvé des solutions quand même).

 Après en partant de ce constat, on remarque qu'il y a pas mal d'usages
 différent du HTTP, qu'on pourrait regrouper en familles avec des priorités
 différentes. Et il y a aussi des protocoles de tunnel que j'ai pas envie de
 voir passer par ce que je préfère le protocole en direct géré proprement
 plutôt qu'une horreur par HTTP. Bref, le but du jeu est de mieux contrôler
 les priorités pour améliorer le service rendu.

 Ce qui est donc à priori possible avec des trucs commerciaux, mais à mon
 avis ils servent plus à taper bêtement sur les utilisateurs qu'à vraiment
 travailler la qualité de service... Et puis bon, les trucs commerciaux c'est
 pas libre, et le dernier truc que j'ai envie de faire c'est de mettre une
 nœud aussi important de mon réseau sous des verrons (bien que des fois on
 n'ai pas le choix).


Si ton problème est juste d'avoir assez de BP pour tous tout le temps,
et non de savoir exactement ce que font tes usagers,
qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des
règles de Qos/Shaping  qui brident le fou de Download quand
il n'est pas tout seul sur les tuyaux et le laisse faire quand tout le
monde dort ?


-- 
David Ramahefason
r...@netfacile.net
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 16:13:36 +0100, Raphaël Jacquot sxp...@sxpert.org 
wrote:

On Wed, 2010-11-24 at 16:10 +0100, Rémy Sanchez wrote:


 Pour situer mon contexte et l'origine de mon idée : je m'occupe du
 réseau dans une résidence étudiante, avec un débit très limité par
 rapport au nombre d'utilisateurs.


ne faudrait il pas commencer par la ? genre, augmenter le débit
disponible de maniere substantielle, plutot que d'essayer de gerer la
rareté de maniere sous-optimale ?


On accepte les dons mensuels en virement, chèque ou espèce si tu veux 
:)


Plus sérieusement, on fait ce qu'on peut, car on a des ressource 
matérielles et humaines limitées. Mais c'est pas du tout de ça que je 
voulais parler, en fait. L'idée me vient de là, mais dans mon cas précis 
on a pratiquement réglé tous nos problèmes.


Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et 
que peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, 
avec des nouveaux outils plus adaptés que ce qu'on a aujourd'hui.


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Stephane Le Men
Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et que 
peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, avec des 
nouveaux outils plus adaptés que ce qu'on a aujourd'hui.


http://en.wikipedia.org/wiki/Multilayer_switch

Et ça fait aussi avec des linux 



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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Julien Gormotte



On Wed, 24 Nov 2010 15:47:48 +0100 (CET), guillaume.monne...@free.fr 
wrote:

Si nous etiames vendreday, j'irions plus loin...


Après la concentration de tous les protocoles au dessus de TCP (ce
qui était deja une hérésie), puis de HTTP (n'en parlons pas)...
Bienvenue vers la concentration vers deux fqdn : www.google.com et
www.facebook.com

Je remarque en effet, que
1/ De plus en plus de marketeux rafolent des www.facebook.com/x à
la place d'un site. C'est pratique, car ça permet de profiler et FB
est accessible via les pseudos acces web des téléphones mobile.
2/ Et de plus en plus de collègues utilisent les *...@gmail.com car
c'est le webmail le moins filtré en entreprise...


Fort heureusement, mon webmail perso n'est jamais filtré. Quoique, à un 
moment, le mot webmail avait été banni des URL accessibles chez un 
ancien employeur... (oui oui, meme pour aller faire des recherches, ou 
lire des articles sur le sujet...)






- Mail Original -
De: Rémy Sanchez remy.sanc...@hyperthese.net
À: frnog@frnog.org
Envoyé: Mercredi 24 Novembre 2010 14h51:56 GMT +01:00 Amsterdam /
Berlin / Berne / Rome / Stockholm / Vienne
Objet: [FRnOG] Firewall HTTP


 Bonjour à tous,

 Les dernières tendances en terme de n'importe quoi consistent à 
faire
 passer à peu près tout ce qu'on peut par du HTTP, à tel point qu'on 
a
 pratiquement remplacé le TCP. Après tout, toutes les applications 
web
 passent par du HTTP, or c'est plutôt vaste : distribution de 
contenu,

 messagerie instantanée, flux vidéo, traitement de texte, ... Sans
 oublier toutes les applications qui utilisent le HTTP (par exemple 
MSN)

 pour faire passer leur protocole en environnement restreint, ou
 carrément les tunnels.

 En bref, le port 80 est toujours ouvert, soit directement, soit à
 travers un proxy. Et c'est la porte ouverte à toutes les fenêtres... 
En
 fin de compte, serait-il cohérent d'imaginer une application 
analogue à
 un firewall, qui au lieu de s'en prendre au TCP s'attaque 
directement au

 HTTP ?

 Ça y est je vois déjà tous les canons pointés en ma direction pour 
me
 signaler qu'on a déjà des proxys, IDS et tout un tas de trucs dans 
le
 genre. C'est d'ailleurs pour ça que je demande si l'idée est 
cohérente

 ou si c'est du grand n'importe quoi. Cependant, je pense à des
 fonctionnalités qui m'ont l'air difficile à configurer dans les 
outils

 pré-cités, comme par exemple différencier les types de flux pour y
 assigner des priorités (long poll et dérivées, page standard, gros
 fichier, accélérateur de téléchargements, ...), reconnaître les sous
 protocoles (comme au dessus, MSN), reconnaître les tunnels, s'en 
prendre
 aussi au HTTPS, ... En bref, pouvoir traiter tout ce qui passe par 
du
 HTTP comme un flux TCP/IP avec un numéro de protocole et un tag pour 
la

 QoS.

 Les outils que j'ai rencontré jusque là ne permettent pas de faire 
ça
 simplement (Squid, pf, iptables pour ceux que j'ai vraiment 
utilisé),

 après étant relativement novice en réseau j'ai assez peu touché aux
 autres outils et aux appliances proprio, donc mon panorama est
 restreint. Donc qu'en pensez vous, lecteurs avisés de FRnOG ? Un tel
 outil serait-il utile ? Pour qui ? Qu'y verriez vous à l'intérieur ?
 Est-ce que j'ai complètement fumé la moquette ?

 NDLR : l'idée ici est de débattre des fonctionnalités d'un tel 
produit,

 non de la manière dont on pourrait les implémenter...

 Allez c'est parti pour une après midi à prendre des baffes :)


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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Julien Richer
Le 24 novembre 2010 16:10, Rémy Sanchez remy.sanc...@hyperthese.net a
écrit :


 Pour situer mon contexte et l'origine de mon idée : je m'occupe du réseau
 dans une résidence étudiante, avec un débit très limité par rapport au
 nombre d'utilisateurs. Et on ne peut pas dire que tout soit bloqué sur le
 réseau, on ouvre les ports à la demande. Seulement, j'aimerais que le débile
 de base qui télécharge 10 trucs en même temps n'empêche pas le type qui a
 entretient d'embauche de faire de la VoIP (le problème n'existe plus au
 fait, on a trouvé des solutions quand même).


Comment tu prends la décision que
- la conversation en voip est importante (entretien d'embauche ou teamspeak
pendant un WoW ?)
- le download n'est pas important (divX méchant illégale ou dossier
important ?)


Normalement la réponse est donc :
- on fait de la Qos pour répartir au mieux le débit (et donc ne pas
avantager celui qui ouvre 10 flux avec un download manager)
- mais on ne regarde pas ce qu'il fait car 1- il fait ce qu'il veut 2- même
avec de la bonne volonté tu n'arriveras jamais à savoir si c'est vraiment
important ou pas sans te tromper


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémi Bouhl
Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit :

 Si ton problème est juste d'avoir assez de BP pour tous tout le temps,
 et non de savoir exactement ce que font tes usagers,
 qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des
 règles de Qos/Shaping  qui brident le fou de Download quand
 il n'est pas tout seul sur les tuyaux et le laisse faire quand tout le
 monde dort ?


Je plussoie l'idée.
Inutile d'aller chercher au niveau de la couche 7 ce que les gens font
vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce
qui est prioritaire, même en faisant preuve de bon sens). Une
répartition équitable en garantissant un minimum à chaque utilisateur,
et le tour est joué :)

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Raphaël Jacquot
On Wed, 2010-11-24 at 16:59 +0100, Rémi Bouhl wrote:
 Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit :
 
  Si ton problème est juste d'avoir assez de BP pour tous tout le temps,
  et non de savoir exactement ce que font tes usagers,
  qu'ils utilisent HTTP ou non, pourquoi ne pas mettre en place des
  règles de Qos/Shaping  qui brident le fou de Download quand
  il n'est pas tout seul sur les tuyaux et le laisse faire quand tout le
  monde dort ?
 
 
 Je plussoie l'idée.
 Inutile d'aller chercher au niveau de la couche 7 ce que les gens font
 vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce
 qui est prioritaire, même en faisant preuve de bon sens). Une
 répartition équitable en garantissant un minimum à chaque utilisateur,
 et le tour est joué :)

ca et chercher a augmenter la bande passante disponible, ce qui n'est
pas forcément cher...
(par exemple, en évitant d'avoir a se coltiner 5km de ligne de cuivre
pourries)

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 16:57:50 +0100, Julien Richer jul...@ywigo.fr 
wrote:

Le 24 novembre 2010 16:10, Rémy Sanchez  a écrit :

Pour situer mon contexte et l'origine de mon idée : je m'occupe du
réseau dans une résidence étudiante, avec un débit très limité
par rapport au nombre d'utilisateurs. Et on ne peut pas dire que tout
soit bloqué sur le réseau, on ouvre les ports à la demande.
Seulement, j'aimerais que le débile de base qui télécharge 10 trucs
en même temps n'empêche pas le type qui a entretient d'embauche de
faire de la VoIP (le problème n'existe plus au fait, on a trouvé des
solutions quand même).

Comment tu prends la décision que 
- la conversation en voip est importante (entretien d'embauche ou
teamspeak pendant un WoW ?) 
- le download n'est pas important (divX méchant illégale ou dossier
important ?)


Normalement la réponse est donc :
- on fait de la Qos pour répartir au mieux le débit (et donc ne pas
avantager celui qui ouvre 10 flux avec un download manager)
- mais on ne regarde pas ce qu'il fait car 1- il fait ce qu'il veut 
2-

même avec de la bonne volonté tu n'arriveras jamais à savoir si
c'est vraiment important ou pas sans te tromper


Bien sûr qu'on n'écoute pas le contenu des conversations pour juger si 
elles sont importantes. C'était un exemple, pour illustrer un peu... Par 
contre en règle générale on veut que la VoIP aille vite alors que de 
lancer 10 connexions HTTP pour un même fichier c'est carrément pas fair 
play. Et si ça t'intéresse, des retours qu'on a eu, les gens font 
surtout de la VoIP pour WoW, un peu pour téléphoner à leurs parents, et 
de temps en temps pour un entretient d'embauche. Quand aux 
téléchargements c'est très souvent illégal mais on a eu des cas où des 
gens ont eu un service trop lent pour télécharger un fichier qui était 
important pour leur stage.


Mais encore une fois, j'aimerais ne pas parler de ce problème en 
particulier. Plutôt, je viens ici pour savoir si quelqu'un voit une 
utilité ou une cohérence quelconque à un outil capable de comprendre le 
HTTP et les protocoles qui y circulent à l'intérieur, dans le but 
principal de faire de la QoS ? (et pourquoi pas bloquer les tunnels, 
bien que sur ce point je pense que la réponse soit assez claire).


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 16:59:47 +0100, Rémi Bouhl remibo...@gmail.com 
wrote:

Je plussoie l'idée.
Inutile d'aller chercher au niveau de la couche 7 ce que les gens 
font

vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce
qui est prioritaire, même en faisant preuve de bon sens). Une
répartition équitable en garantissant un minimum à chaque 
utilisateur,

et le tour est joué :)


Mes utilisateurs vont être content avec leur 100kbps par personne tiens 
:)


Je ne parle pas de décider que tel ou tel site soit plus important, 
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour 
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon 
maintenant si la VoIP et le gros fichier passent tous les deux par le 
HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ?


C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. 
Je veux pouvoir les distinguer pour avoir une qualité de service 
appropriée. Pas décider que les films de cul de Bob valent plus que les 
séries à l'eau de rose d'Alice.


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



RE: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Michel Py
Rémi Bouhl
 Du coup je propose la solution couillue: ouvrir les vannes sur
 les autres ports. Laisser sortir ce qui était encapsulé en HTTP,
 afin qu'HTTP redevienne ce qu'il n'aurait pas du cesser d'être.
 Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et
 en RDP, inutile de faire des tunnels HTTP.

+1

Chaque fois qu'on rajoute une couche, quelqu'un invente une bidouille pour la 
contourner. A force, pour accéder à sa propre bécane à quelques kilomètres on 
va se retrouver avec une usine à gaz qui consomme la moitié de la bande 
passante en encapsulations successives et envoie le trafic en Suède via le 
Srilanka.

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Yves Dubromelle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 24/11/2010 17:23, Rémy Sanchez a écrit :
 Je ne parle pas de décider que tel ou tel site soit plus important, mais
 on a bien inventé la QoS pour une raison non ? Par exemple, pour que de
 la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon
 maintenant si la VoIP et le gros fichier passent tous les deux par le
 HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ?
 
La vraie question, c'est de savoir pourquoi les utilisateurs de ton
réseau utilisent de la VoIP sur HTTP.
Si effectivement tu considère que la VoIP est importante au point de
vouloir la prioriser par de la QoS, à ce compte là pourquoi ne pas
ouvrir le port qui va bien pour qu'ils l'utilisent ?

Je ne comprend vraiment pas la logique.

 C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. Je
 veux pouvoir les distinguer pour avoir une qualité de service
 appropriée. Pas décider que les films de cul de Bob valent plus que les
 séries à l'eau de rose d'Alice.
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAkztPSoACgkQ8IhKGszP0SozHgD9EnLaxGpOd0le57Blr0bTkWpC
gsgjmLgr58jL9y4i0xIBAI1FHijZcULzsgoTWlKODhF1X//325Q7X5Mqxp+CRdoz
=+JU6
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémi Bouhl
Le 24/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit :

  Je ne parle pas de décider que tel ou tel site soit plus important,
  mais on a bien inventé la QoS pour une raison non ? Par exemple, pour
  que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon
  maintenant si la VoIP et le gros fichier passent tous les deux par le
  HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ?

Pas exactement. Tu garantis à Bob et Alice leurs 100 ko/s. Celui qui
veut faire de la VoIP il coupe ou il ralentit son
FTP/HTTP/Torrent/whatever, ou il fait de la QoS tout seul comme un
grand (y'a des softs pour ça, y compris sous Windows).

Et si ça l'amuse il freine sa VoIP pour échapper à une discussion
chiante avec sa belle mère et il booste son DDL depuis Rapidshare
parce qu'un couillon de son groupe de travail a pensé que c'était une
bonne plateforme pour héberger un dossier sérieux.

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Mehdi AMINI

Salut,

Je ne parle pas de décider que tel ou tel site soit plus important, 
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour 
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. 
Ben ouais la QoS c'est pour ça, mais pas besoin de monter au niveau 7 
pour garantir ça...


Bon maintenant si la VoIP et le gros fichier passent tous les deux par 
le HTTP, tu fais quoi ?


L'erreur est là : pourquoi tes utilisateurs font de la VOIP en HTTP ? 
Parler de Qualité de Service et VOIP over HTTP dans la même phrase c'est 
possible ???
Si l'utilisateur ne veut pas utiliser autre chose que HTTP, tant pis 
pour lui :-)



C'est malheureux mais beaucoup de protocoles convergent vers le HTTP. 
Je veux pouvoir les distinguer pour avoir une qualité de service 
appropriée.


T'as des exemples réels ? Parceque à part la VOIP que t'as ressorti 
plusieurs fois, c'est quoi ces fameux protocoles au dessus d'HTTP qui 
méritent tant d'attention ?



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



RE: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 08:25:14 -0800, Michel Py 
mic...@arneill-py.sacramento.ca.us wrote:

Rémi Bouhl

Du coup je propose la solution couillue: ouvrir les vannes sur
les autres ports. Laisser sortir ce qui était encapsulé en HTTP,
afin qu'HTTP redevienne ce qu'il n'aurait pas du cesser d'être.
Oyez braves utilisateurs, vous pouvez sortir en SSH, en VPN et
en RDP, inutile de faire des tunnels HTTP.


+1

Chaque fois qu'on rajoute une couche, quelqu'un invente une bidouille
pour la contourner. A force, pour accéder à sa propre bécane à
quelques kilomètres on va se retrouver avec une usine à gaz qui
consomme la moitié de la bande passante en encapsulations successives
et envoie le trafic en Suède via le Srilanka.


+1 aussi

J'suis le premier à vouloir faire ce que je veux du réseau. Et le 
premier à faire des tunnels.


J'ai compris que le blocage des tunnels, c'est une mauvaise idée, et en 
fait c'est pas vraiment utile, donc sur ce point là c'est clair.


Mais le fait est que là 95% du flux de données passe par du HTTP, et 
qu'on commence vraiment à avoir des types d'applications variées qui se 
distingues. Comme ce qu'on avait en TCP/UDP avant, mais remonté de 
quelques couches. J'y peux rien si Internet vire au n'importe quoi, mais 
j'ai envie de proposer des solutions pour garder un service de qualité 
:) .


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Simon Morvan

Le 24/11/2010 17:23, Rémy Sanchez a écrit :


Mes utilisateurs vont être content avec leur 100kbps par personne 
tiens :)
S'il utilisent tous le tuyau en même temps, c'est normal. Après c'est 
plus la taille du tuyau, le problème, pas la QoS.


Je ne parle pas de décider que tel ou tel site soit plus important, 
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour 
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. 
Bon maintenant si la VoIP et le gros fichier passent tous les deux par 
le HTTP, tu fais quoi ? Kif kif comme si y'avait pas de QoS ? 
Pourquoi passent-il par HTTP ? La VoIP en UDP/RTP est filtrée sur ton 
réseau ?


--
Simon.


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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Raphaël Jacquot
On Wed, 2010-11-24 at 17:26 +0100, Simon Morvan wrote:
 Le 24/11/2010 17:23, Rémy Sanchez a écrit :
 
  Mes utilisateurs vont être content avec leur 100kbps par personne 
  tiens :)
 S'il utilisent tous le tuyau en même temps, c'est normal. Après c'est 
 plus la taille du tuyau, le problème, pas la QoS.

comme je disais... tuyau trop petit, augmenter tuyau ;)

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Stephen
On Wed, November 24, 2010 16:59, Rémi Bouhl wrote:
 Le 24/11/10, David Ramahefasonr...@netfacile.net a écrit :


 Si ton problÚme est juste d'avoir assez de BP pour tous tout le temps,
  et non de savoir exactement ce que font tes usagers, qu'ils utilisent
 HTTP ou non, pourquoi ne pas mettre en place des
 rÚgles de Qos/Shaping  qui brident le fou de Download quand il n'est pas
 tout seul sur les tuyaux et le laisse faire quand tout le monde dort ?


 Je plussoie l'idée.
 Inutile d'aller chercher au niveau de la couche 7 ce que les gens font
 vraiment (et, à tout prendre, ce n'est pas à l'admin de décider de ce
 qui est prioritaire, même en faisant preuve de bon sens). Une
 répartition équitable en garantissant un minimum à chaque utilisateur,
  et le tour est joué :)

Virgin Media (câble opérateur UK) a un système différent qui me semble pas
trop bête : pendant les périodes de forte activité réseau, la quantité de
données échangée par utilisateur est comptabilisée et si un dépassement de
quota est constaté (upload ou download), le débit est réduit pendant une
durée de 12h. Tu regardes pas le contenu des paquets, tu regardes juste si
l'utilisateur n'abuse pas au détriment des copains...

http://shop.virginmedia.com/help/traffic-management/traffic-management-policy.html


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





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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Raphaël Jacquot
On Wed, 2010-11-24 at 17:35 +0100, Stephen wrote:

 Virgin Media (câble opérateur UK) a un système différent qui me semble pas
 trop bête : pendant les périodes de forte activité réseau, la quantité de
 données échangée par utilisateur est comptabilisée et si un dépassement de
 quota est constaté (upload ou download), le débit est réduit pendant une
 durée de 12h. Tu regardes pas le contenu des paquets, tu regardes juste si
 l'utilisateur n'abuse pas au détriment des copains...

l'art et la maniere d'éviter d'investir... va savoir ou vont les
bénéfices ;)

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez


On Wed, 24 Nov 2010 17:29:37 +0100, Mehdi AMINI joker@gmail.com 
wrote:

Salut,

Je ne parle pas de décider que tel ou tel site soit plus important, 
mais on a bien inventé la QoS pour une raison non ? Par exemple, pour 
que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. 
Ben ouais la QoS c'est pour ça, mais pas besoin de monter au niveau 7 
pour garantir ça...


Bon maintenant si la VoIP et le gros fichier passent tous les deux 
par le HTTP, tu fais quoi ?


L'erreur est là : pourquoi tes utilisateurs font de la VOIP en HTTP ?
Parler de Qualité de Service et VOIP over HTTP dans la même phrase
c'est possible ???
Si l'utilisateur ne veut pas utiliser autre chose que HTTP, tant pis
pour lui :-)


C'est malheureux mais beaucoup de protocoles convergent vers le 
HTTP. Je veux pouvoir les distinguer pour avoir une qualité de service 
appropriée.


T'as des exemples réels ? Parceque à part la VOIP que t'as ressorti
plusieurs fois, c'est quoi ces fameux protocoles au dessus d'HTTP qui
méritent tant d'attention ?


Ok j'avoue la VoIP c'était assez extrême, et y'a pas grand monde qui 
fait ça (voire, personne (sauf Skype ? je sais plus)). De toute façon ça 
serait débile, on leur ouvre toujours les ports de leur TS aux 
utilisateurs :)


Pour moi, y'a plusieurs familles de (plus ou moins) protocoles qui 
émergent :


	* Le bon vieux HTTP standard, avec téléchargement de petits fichiers 
un par un.
	* Le HTTP toujours standard, mais avec du téléchargement de gros 
fichiers avec potentiellement des abus à l'aide d'accélérateurs de 
téléchargements.
	* Les protocoles internes aux applications, avec des micro-requêtes en 
Ajax.

* Les long poll, comet et autres techniques de PUSH HTTP.

En somme, pourquoi l'accès à un traitement de texte en ligne devrait 
être traité avec la même priorité qu'un téléchargement de masse ? Ce 
sont deux services totalement différents, avec des besoins totalement 
différents aussi. De la même manière qu'on va faire passer le SSH avant 
le FTP, la communication évènementielle de la dernière appli à la mode 
devrait passer avant un téléchargement sur megaupload.


Pour répondre en diagonale aux autres messages : oui les utilisateurs 
qui font tout passer en HTTP sont débiles, mais en fait c'est le cas de 
n'importe qui surfant sur le web. C'est largement suboptimal, mais tout 
tend à tourner dans le navigateur.


Et encore une fois je ne dis pas que c'est impossible à gérer avec ce 
qui existe (variante: oui il y a des solutions à mes problèmes, et oui 
je les utilises). Je suggère juste la création d'un outil adapté, qui au 
lieu de demander des heures à concevoir et tuner une config, permettra 
d'avoir une config par défaut qui marche directement, sans avoir à 
détourner les fonctionalités du logiciel. J'veux dire par là, oui on 
peut faire un proxy avec nfqueue, bash, wget, rsync et 2 ou 3 autres, 
mais c'est carrément pas aussi adapté que Squid. Je veux différencier 
les flux HTTP, mais Squid n'est pas adapté pour ça.


--
Rémy Sanchez
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet David Ramahefason
Le 24 novembre 2010 17:15, Rémy Sanchez remy.sanc...@hyperthese.net a écrit :
 Mais encore une fois, j'aimerais ne pas parler de ce problème en
 particulier. Plutôt, je viens ici pour savoir si quelqu'un voit une utilité
 ou une cohérence quelconque à un outil capable de comprendre le HTTP et les
 protocoles qui y circulent à l'intérieur, dans le but principal de faire de
 la QoS ? (et pourquoi pas bloquer les tunnels, bien que sur ce point je
 pense que la réponse soit assez claire).


L'utilité/besoin est sans doute là vue que des produits commerciaux
existent depuis longtemps pour celà: Bluequote / Allott par exemple
(comme dit plus haut).
Après je ne sais pas si c'est la cohérence qu'il faut chercher mais
plutôt des besoins commerciaux et/ou sécuritaires plus que le manque
de BP car comme dit plus haut cette ressource n'est souvent plus un
problème.
Dans une ancienne vie on utilisait ce genre de boites pour facturer
nos clients hébergés en ferme, j'ai aussi travaillé pour un opérateur
sur une archi à base d'allot pour limiter tout ce qui relevait du
traffic P2PCo dès que le trafic n'était pas on-net. Dans les deux cas
il n'a jamais été question de regarder ce qui était échangé.
Le blocage de tel ou tel protocole ensuite relève de ta politique de
sécurité, qui de ce que je comprend diffèrerait dans ce cas de celle
d'un FAI/Opérateur (pour l'instant, quoique :))

-- 
David Ramahefason
r...@netfacile.net
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 16:26:22 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:

  Le constat est que tout passe dans un énorme tuyau qu'est le HTTP et 
  que peut être qu'il faudrait y mettre plus de contrôle à l'intérieur, 
  avec des nouveaux outils plus adaptés que ce qu'on a aujourd'hui.

Pourquoi ?
On a pas encore appris les lecons du controle au nieveaux 3 et 4 ?
Faut imperativement faire les memes erreurs au niveau 7 ?

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

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



RE: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Michel Py
 Radu-Adrian Feurdean a écrit:
 et certains elus moins cons contre cette loi.

A rajouter dans la lettre au Père Noël, définitivement.
Des politiciens moins cons que leurs prédécesseurs!

:-D

Michel.

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 17:23:37 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:

  que de la VoIP passe plus vite qu'un gros fichier qui passe en FTP. Bon 
  maintenant si la VoIP et le gros fichier passent tous les deux par le 

Ca ca marche en entreprise, ou la prioritisation de tel ou tel
protocole/destination/ se fait sur decision venue d'en haut (peu
importe l'impact sur les utilisateurs).
Quand la connectivite est un service offert (contre $$$ ou non), le
contenu des paquets que tu tranpostes n'est plus ton probleme. Ton
boulot dois s'arreter au plus proche du niveau 3.

  Je veux pouvoir les distinguer pour avoir une qualité de service 
  appropriée. Pas décider que les films de cul de Bob valent plus que les 
  séries à l'eau de rose d'Alice.

Mais c'est exactement ce que tu demandes.
Tu veux faire de la qualite de service, fais-la par client.

En effet c'est ca la neutralite

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 17:25:44 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:

  Attention piège : on a un proxy donc c'est uniquement lui que la 
  passerelle va voir. Et limiter le nombre de connexions par IP au niveau 
  du proxy c'est pas possible à cause des long polls précédemment évoqués. 

Tu peux aussi revoir legerement ton architecture.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

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



RE: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 17:33:16 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:

  Mais le fait est que là 95% du flux de données passe par du HTTP, et 
  qu'on commence vraiment à avoir des types d'applications variées qui se 
  distingues. Comme ce qu'on avait en TCP/UDP avant, mais remonté de 
  quelques couches. J'y peux rien si Internet vire au n'importe quoi, mais 
  j'ai envie de proposer des solutions pour garder un service de qualité 

Pour la n-ieme fois, le rappel (en anglais cette fois):

We're network admins. To us, data is just a protocol-overhead.

Oublie tout ce qui depasse le niveau 3 !!!
Tu peux encore faire du QoS nu niveau 3, faut juste revoir ton facon de
voir les choses.

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 07:04 PM, Radu-Adrian Feurdean wrote:
 Pourquoi ?

Pour qu'un service qui a besoin d'une bonne réactivité mais de peu de
débit ne soit pas pénalisé par un service qui se fiche de la réactivité
mais mange du débit à fond ?

 On a pas encore appris les lecons du controle au nieveaux 3 et 4 ?
 Faut imperativement faire les memes erreurs au niveau 7 ?

Pas moi en tout cas, quelles sont-elles ? On m'a toujours vendu la QoS
en disant que c'est trop cool, mais je suis curieux d'entendre des
contre-arguments.

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 07:19 PM, Radu-Adrian Feurdean wrote:
 Tu peux aussi revoir legerement ton architecture.

Tu suggères ?

-- 
Rémy Sanchez
http://hyperthese.net



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 07:26 PM, Radu-Adrian Feurdean wrote:
 Pour la n-ieme fois, le rappel (en anglais cette fois):
 
 We're network admins. To us, data is just a protocol-overhead.
 
 Oublie tout ce qui depasse le niveau 3 !!!
 Tu peux encore faire du QoS nu niveau 3, faut juste revoir ton facon de
 voir les choses.

Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette
les champs à la bonne valeur. À ma connaissance, les navigateurs ne
savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le
commerce ça a l'air d'exister) pour différencier facilement les flux
assez finement.

D'où le problème initial de coder une application capable de faire de la
QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne
valeur).

-- 
Rémy Sanchez





signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Mattieu Baptiste
2010/11/24 Rémy Sanchez remy.sanc...@hyperthese.net:
 Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette
 les champs à la bonne valeur. À ma connaissance, les navigateurs ne
 savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le
 commerce ça a l'air d'exister) pour différencier facilement les flux
 assez finement.

 D'où le problème initial de coder une application capable de faire de la
 QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne
 valeur).

Je me permets de répondre parce que je connais particulièrement bien
la résidence dont tu parles ;)

Tout ce que tu penses être tes problèmes sont des non-problèmes. Par
contre, tu en as un vrai de problème : TU MANQUES DE BANDE PASSANTE.

Tu te plains que tout le monde peut faire ce qu'il veut dans HTTP ?
Ouvre avec modération le trafic que tu souhaites ne plus voir passer
dans du HTTP... euh... mais je crois savoir que c'est déjà ce que tu
fais actuellement...

Tu te plains que tout le monde peut mettre tout ce qu'il veut dans
HTTP donc il faudrait un outil top cool moumoutte pour filtrer (et
faire je ne sais quels calculs magiques dont toi même tu ne sais
expliquer, pour catégoriser les services qui passent dans HTTP) ? Et
tu feras quoi quand un mec utilisera son propre outil non connu par
l'outil top cool moumoutte, pour faire un VPN qui mettra son flux dans
des balises normales HTML, ressemblant à du contenu normal... et que
ce mec pompera l'intégralité de la bande passante...

Tu n'es pas satisfait de squid ? De toute façon votre histoire de
proxy ce n'est que du bullshit. Vous maintenez des stats sur
l'utilisation du cache de votre proxy ? Vous avez des stats réels de
l'utilisation avec/sans proxy à la longue ?
Avec le *profil* de tes utilisateurs, le proxy sera inutile pour
plusieurs raisons :
- Sur facebook/youtube/WTF, les utilisateurs ne consultent que ce qui
les intéressent eux,
- De très nombreux sites ont une politique de cache ultra restrictive,
- HTTPS ?
Le cache... aujourd'hui il est dans le navigateur. Mis à part l'image
du jour google et quelques conneries, le proxy ne sert à rien.

La QoS (celle que tu entends) n'existe pas ? Eh oui... bienvenue dans
le monde réel. Ta QoS tu la fait sur du niveau 3/4. Pour en faire dans
HTTP, voir le cas d'utilisation d'un outil inconnu, top cool
moumoutte, qui fait du VPN.

Je vais encore le répéter, tu as un problème : la bande passante.
Quelles que soient les bidouilles que tu arriveras à trouver, on
reviendra au même problème initiale. Tu veux résoudre tes problèmes :
UPGRADE.

Enfin... comme le disent les autres réponses précédentes, ta tâche
elle s'arrête au niveau 3/4. Au dessus, les utilisateurs font ce
qu'ils veulent (et si ce n'est pas le cas, ils trouveront de toute
façon une manière de faire ce qu'ils veulent). Tu as des abus
réguliers ? Tu souhaites t'en débarrasser ?
1 C'est ton boulot quotidien d'admin.
2 A toi d'éduquer (aussi durement que tu le souhaites) les
utilisateurs pour plus que ça ne se reproduise.
3 Un réseau en pilote automatique, je n'ai pas encore sorti ma boule
de cristal, mais je te mets au défi de le trouver.


-- 
Mattieu Baptiste
/earth is 102% full ... please delete anyone you can.
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Pascal Rullier
Le 24/11/2010 17:47, Raphaël Jacquot a écrit :
 On Wed, 2010-11-24 at 17:35 +0100, Stephen wrote:

   
 Virgin Media (câble opérateur UK) a un système différent qui me semble pas
 trop bête : pendant les périodes de forte activité réseau, la quantité de
 données échangée par utilisateur est comptabilisée et si un dépassement de
 quota est constaté (upload ou download), le débit est réduit pendant une
 durée de 12h. Tu regardes pas le contenu des paquets, tu regardes juste si
 l'utilisateur n'abuse pas au détriment des copains...
 
 l'art et la maniere d'éviter d'investir... va savoir ou vont les
 bénéfices ;)
   

Dans la poche des actionnaires pardi...

Cdt,

-- 
Pascal,


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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Xavier Beaudouin
Salut Rémy,

(...)

Le 24 nov. 2010 à 17:56, Rémy Sanchez a écrit :
 En somme, pourquoi l'accès à un traitement de texte en ligne devrait être 
 traité avec la même priorité qu'un téléchargement de masse ? Ce sont deux 
 services totalement différents, avec des besoins totalement différents aussi. 
 De la même manière qu'on va faire passer le SSH avant le FTP, la 
 communication évènementielle de la dernière appli à la mode devrait passer 
 avant un téléchargement sur megaupload.

Moi pour le téléchargements de masse j'avais réglé (enfin j'avais) le pb 
autrement : répertoire /tmpfs de l'antivirus faisais 50M... tout téléchargement 
 a 50Mo devais passer par les admin... C'étais une règle... pratique... :)

 Pour répondre en diagonale aux autres messages : oui les utilisateurs qui 
 font tout passer en HTTP sont débiles, mais en fait c'est le cas de n'importe 
 qui surfant sur le web. C'est largement suboptimal, mais tout tend à tourner 
 dans le navigateur.

C'est sûr.. Je vais te donner un exemple, dans le cadre de mon taf j'ai un KVM 
IP qui lance un Java... Pas de pb... Sauf que ce truc passe par VNC... 
Evidement bloqué par des gens paranoïaques qui bloquent absolument tout ce qui 
sort y compris icmp (et pan pmtud - dtc, je parle pas non plus de l'IPv6 qui 
ne sera jamais prêt de fonctionner chez eux mais tant pis).
Résultat on avais commencé de faire des trucs avec des bidouilles genre novnc 
par exemple...
On a laissé tomber car il faillais une usine a gaz et un centrale de calcul 
pour couper le protocole VNC en morceaux de HTTP.

Résultat... encore une encapsulation de merde de plus a gérer pour les 
firewall corporate gérés par des gens pour qui TCP/IP se résume au minitel... 
(ok je vais loin, mais..).

 Et encore une fois je ne dis pas que c'est impossible à gérer avec ce qui 
 existe (variante: oui il y a des solutions à mes problèmes, et oui je les 
 utilises). Je suggère juste la création d'un outil adapté, qui au lieu de 
 demander des heures à concevoir et tuner une config, permettra d'avoir une 
 config par défaut qui marche directement, sans avoir à détourner les 
 fonctionalités du logiciel. J'veux dire par là, oui on peut faire un proxy 
 avec nfqueue, bash, wget, rsync et 2 ou 3 autres, mais c'est carrément pas 
 aussi adapté que Squid. Je veux différencier les flux HTTP, mais Squid n'est 
 pas adapté pour ça.

Y a un truc que tu peux faire avec squid c'est différencier les objets courts 
(ajax / traitement de texte / chat [ok je sors]) et les téléchargements 
lourds...
Bon c'est du tweak de conf mais ça se fait.

/Xavier

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 09:05 PM, Mattieu Baptiste wrote:
 2010/11/24 Rémy Sanchez remy.sanc...@hyperthese.net:
 Moi j'veux bien faire du DiffServ, mais à un moment faut qu'on me mette
 les champs à la bonne valeur. À ma connaissance, les navigateurs ne
 savent pas faire ça, et il n'existe pas d'outil (libre, vu que dans le
 commerce ça a l'air d'exister) pour différencier facilement les flux
 assez finement.

 D'où le problème initial de coder une application capable de faire de la
 QoS là dessus (ça peut juste vouloir dire qu'on met le DSCP à la bonne
 valeur).
 
 Je me permets de répondre parce que je connais particulièrement bien
 la résidence dont tu parles ;)
 
 Tout ce que tu penses être tes problèmes sont des non-problèmes. Par
 contre, tu en as un vrai de problème : TU MANQUES DE BANDE PASSANTE.
 
 Tu te plains que tout le monde peut faire ce qu'il veut dans HTTP ?
 Ouvre avec modération le trafic que tu souhaites ne plus voir passer
 dans du HTTP... euh... mais je crois savoir que c'est déjà ce que tu
 fais actuellement...
 
 Tu te plains que tout le monde peut mettre tout ce qu'il veut dans
 HTTP donc il faudrait un outil top cool moumoutte pour filtrer (et
 faire je ne sais quels calculs magiques dont toi même tu ne sais
 expliquer, pour catégoriser les services qui passent dans HTTP) ? Et
 tu feras quoi quand un mec utilisera son propre outil non connu par
 l'outil top cool moumoutte, pour faire un VPN qui mettra son flux dans
 des balises normales HTML, ressemblant à du contenu normal... et que
 ce mec pompera l'intégralité de la bande passante...
 
 Tu n'es pas satisfait de squid ? De toute façon votre histoire de
 proxy ce n'est que du bullshit. Vous maintenez des stats sur
 l'utilisation du cache de votre proxy ? Vous avez des stats réels de
 l'utilisation avec/sans proxy à la longue ?
 Avec le *profil* de tes utilisateurs, le proxy sera inutile pour
 plusieurs raisons :
 - Sur facebook/youtube/WTF, les utilisateurs ne consultent que ce qui
 les intéressent eux,
 - De très nombreux sites ont une politique de cache ultra restrictive,
 - HTTPS ?
 Le cache... aujourd'hui il est dans le navigateur. Mis à part l'image
 du jour google et quelques conneries, le proxy ne sert à rien.
 
 La QoS (celle que tu entends) n'existe pas ? Eh oui... bienvenue dans
 le monde réel. Ta QoS tu la fait sur du niveau 3/4. Pour en faire dans
 HTTP, voir le cas d'utilisation d'un outil inconnu, top cool
 moumoutte, qui fait du VPN.
 
 Je vais encore le répéter, tu as un problème : la bande passante.
 Quelles que soient les bidouilles que tu arriveras à trouver, on
 reviendra au même problème initiale. Tu veux résoudre tes problèmes :
 UPGRADE.
 
 Enfin... comme le disent les autres réponses précédentes, ta tâche
 elle s'arrête au niveau 3/4. Au dessus, les utilisateurs font ce
 qu'ils veulent (et si ce n'est pas le cas, ils trouveront de toute
 façon une manière de faire ce qu'ils veulent). Tu as des abus
 réguliers ? Tu souhaites t'en débarrasser ?
 1 C'est ton boulot quotidien d'admin.
 2 A toi d'éduquer (aussi durement que tu le souhaites) les
 utilisateurs pour plus que ça ne se reproduise.
 3 Un réseau en pilote automatique, je n'ai pas encore sorti ma boule
 de cristal, mais je te mets au défi de le trouver.
 
 

Je voulais justement pas ramener la résidence en question sur le tapis
par ce que je sais très bien que les problèmes viennent de la bande
passante, et tu sais comme moi à quel point on n'a pas de budget. Donc
c'est un peu une impasse. Quand à éduquer les utilisateurs... Déjà ils
lisent pas les papiers/mails qu'on leur donne aussi court soient-ils, et
en plus ils changent tous les ans. M'enfin, c'est pas le problème, ce
troll là on l'a déjà assez souvent pour éviter de le ramener ici.

La question était bel et bien générique, à savoir est-ce qu'un tel
logiciel peut être intéressant dans un nombre suffisant de cas ?  Je me
demande si, étant donné que la quasi exclusivité du trafic est du HTTP,
est-ce que ça a du sens d'essayer de le considérer administrativement
comme un protocole de transport ?

Bon et finalement, est-ce que la QoS sert à quelquechose ? Par ce que si
on résume, la QoS ne sert à rien quand on a assez de bande passante, et
elle n'est pas assez efficace quand y'a pas assez de bande passante...

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 09:53 PM, Xavier Beaudouin wrote:
 Y a un truc que tu peux faire avec squid c'est différencier les objets 
 courts (ajax / traitement de texte / chat [ok je sors]) et les 
 téléchargements lourds...
 Bon c'est du tweak de conf mais ça se fait.

C'est plus où moins là où je veux en venir : c'est des choses qu'on
fait, mais c'est ni évident ni standard.

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Jean-Pierre
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bonjour,

Le 24/11/2010 19:39, Rémy Sanchez a écrit :
 On 11/24/2010 07:04 PM, Radu-Adrian Feurdean wrote:
 Pourquoi ?
 
 Pour qu'un service qui a besoin d'une bonne réactivité mais de peu
 de débit ne soit pas pénalisé par un service qui se fiche de la
 réactivité mais mange du débit à fond ?

Simple : faire une réservation de BP par utilisateur/@IP. Le reste de BP
étant mangée par qui veut/en a besoin.

(Faut peut être mettre les mains dans le cambouis pour y arriver)

 On a pas encore appris les leçons du contrôle au niveaux 3 et 4
 ? Faut impérativement faire les mêmes erreurs au niveau 7 ?
 
 Pas moi en tout cas, quelles sont-elles ?

- - Que c'est aux applications elles même et au système final de faire ce
contrôle de flux
- - Que gérer les contrôles de flux en cœur de réseau provoquait des
effets de bords non désirés (oscillations de trafic sur des liens
identiques, latence inexpliquée,

 On m'a toujours vendu la
 QoS en disant que c'est trop cool, mais je suis curieux d'entendre
 des contre-arguments.

De mon coté, on m'a appris que la QoS c'est trouver une règle pour
dropper/ralentir des paquets suivant une règle définie par l'admin.

Et donc que les marchands de contenus trouvaient ça bien car c'est
leur(s) service qui est mis en valeur (au détriment d'autres services
forcément).

Le souci majeur avec la QoS dans les grands système est la diversité des
utilisateurs. Tous n'ont pas les mêmes besoins. Untel a besoin de ses
résultats de simulation sur le calculateur de la boîte (Big file), tel
autre a besoin de récupérer les tonnes de PDF de ses mails. Un autre
encore va passer ses journées à balancer/récupérer des chaines de mails
avec la dernière blagounette. On peut même envisager une équipe de
développeurs qui publieraient leurs applications en torrent pour limiter
la BP.

Dis autrement, les protocoles ne sont pas représentatif de l'usage, ni
des attentes de l'utilisateur, et encore moins de leurs besoins.

Accessoirement, gérer de la QoS sur des tunnels encapsulés dans du HTTP,
risque de rapidement transformer le réseau en un champ de bataille avec
d'un coté le(s) gens qui veulent filtrer et les utilisateurs qui
*contourneront* le système de filtrage.

(Toute ressemblance avec une loi finissant par I relève du hasard)


Jean-Pierre
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkztiMcACgkQcPNeJG1THnNoMwCglYBRUBjMEfTicRsKjVekP10X
W8sAoJDHDDiXA/l03FRkF/EenicG2mj4
=G5XX
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Radu-Adrian Feurdean

On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
remy.sanc...@hyperthese.net said:

 par ce que je sais très bien que les problèmes viennent de la bande
 passante, et tu sais comme moi à quel point on n'a pas de budget. Donc

T'as un probleme de bande passante, t'as de utilisateurs qui veulent de
la bande passant ?
1. Augmente tes prix
2. Cree des services premium, plus chers, pour ceux qui veulent plus,
qui te permettent de financer ta bande passante

Et enfin, la BP est chere uniquement sur la boucle locale. Des que tu
arrives dans un DC, ca coute presque rien (si jamais t'as encore de
probleme en DC, tu prononce le mot magique Cogent et tout le monde
rentre dans les rangs).

-- 
Radu-Adrian Feurdean
 raf (a) ftml ! net

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 11:05 PM, Radu-Adrian Feurdean wrote:
 
 On Wed, 24 Nov 2010 22:02:08 +0100, Rémy Sanchez
 remy.sanc...@hyperthese.net said:
 
 par ce que je sais très bien que les problèmes viennent de la bande
 passante, et tu sais comme moi à quel point on n'a pas de budget. Donc
 
 T'as un probleme de bande passante, t'as de utilisateurs qui veulent de
 la bande passant ?
 1. Augmente tes prix
 2. Cree des services premium, plus chers, pour ceux qui veulent plus,
 qui te permettent de financer ta bande passante
 
 Et enfin, la BP est chere uniquement sur la boucle locale. Des que tu
 arrives dans un DC, ca coute presque rien (si jamais t'as encore de
 probleme en DC, tu prononce le mot magique Cogent et tout le monde
 rentre dans les rangs).
 

On étudie la liaison IPoAC pour arriver au point de présence de Cogent
le plus proche :)

Y'a pas moyen d'avoir un centime de budget supplémentaire, pour
l'instant on est bien parti pour rester sur le modèle actuel (y compris
la facturation etc). C'est vraiment une petite échelle (~150 étudiants),
donc rien de trop faisable à ce niveau.

Mais s'il vous plaît, est-ce qu'on pourrait arrêter de parler de cette
résidence ? Même si c'est un problème rencontré là bas qui m'a poussé à
me poser la question, le but du jeu n'était pas de trouver un moyen
magique de faire rentrer plus de choses dans le même tuyau. C'était
juste une interrogation générique, que j'ai formulé et re-formulé 1 mail
sur 2, donc je vais éviter de le refaire ici.

En tout cas, merci à tous pour vos réponses :)

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet David Ramahefason
Le 24 novembre 2010 23:19, Rémy Sanchez remy.sanc...@hyperthese.net a écrit :

 Mais s'il vous plaît, est-ce qu'on pourrait arrêter de parler de cette
 résidence ? Même si c'est un problème rencontré là bas qui m'a poussé à
 me poser la question, le but du jeu n'était pas de trouver un moyen
 magique de faire rentrer plus de choses dans le même tuyau. C'était
 juste une interrogation générique, que j'ai formulé et re-formulé 1 mail
 sur 2, donc je vais éviter de le refaire ici.


Je ne te comprend pas trop tu expose un problème précis mais tu ne
veux pas qu'on se focalise dessus.
Tu voulais discuter de quoi exactement ?? Savoir s'il était possible
de faire de la classification de paquets en L7 ??
La réponse est oui, cela existe depuis plus de dix ans (Packeteer /
Allot et sans doute des solutions Open Source).
Sinon tu as a ta disposition tout plein de tricks pour jouer avec la
Qos sur tes équipements et la solution à la Virgin me semble
est la plus intéressante pour toi.

-- 
David Ramahefason
r...@netfacile.net
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/24/2010 11:33 PM, David Ramahefason wrote:
 Je ne te comprend pas trop tu expose un problème précis mais tu ne
 veux pas qu'on se focalise dessus.
 Tu voulais discuter de quoi exactement ?? Savoir s'il était possible
 de faire de la classification de paquets en L7 ??
 La réponse est oui, cela existe depuis plus de dix ans (Packeteer /
 Allot et sans doute des solutions Open Source).
 Sinon tu as a ta disposition tout plein de tricks pour jouer avec la
 Qos sur tes équipements et la solution à la Virgin me semble
 est la plus intéressante pour toi.

Avec mon problème précis, je remarque que le HTTP permet de servir un
nombre varié d'applications en réseau. Et finalement, plus
d'applications passent par le HTTP que par du TCP ou de l'UDP directement.

La question porte donc sur les capacités des logiciels actuels en L7 :
sont-ils capable de différencier les différentes applications et de
prendre en compte leurs spécificités ?

Et par là, je veux dire que de plus en plus le HTTP prends la forme d'un
protocole niveau 4 voire 3, et par conséquent il y a peut être besoin de
le changer la manière dont on le traite.

Par exemple, est-ce que les outils actuels sont conçu pour pouvoir
reconnaître un accélérateur de téléchargement qui prends simultanément
10 morceaux d'un fichier sur megaupload ? De reconnaître long poll et de
lui donner une forte priorité pour baisser la latence ? Le tout avec la
configuration par défaut/peu de configuration ? [*]

Si les outils actuels en sont incapable, est-ce que cela aurait un
intérêt de créer un tel outil ? Les avis sur la QoS semblent partagés,
est-ce que cela est vraiment utile ?

Peut être qu'aujourd'hui le problème n'est pas flagrant, mais on voit de
plus en plus d'applications faire du (quasi) temps réel. On s'éloigne
vraiment loin du principe initial du HTTP... D'où mes interrogations,
pour éviter de se retrouver totalement désarmé dans un monde où le HTTP
écrase les autres protocoles et où l'on se retrouve sans aucune
visibilité sur les types de service.

J'ai enfin réussi à bien expliquer ma question ? J'peux recommencer
sinon j'suis plus à ça près -_-

-- 
Rémy Sanchez


[*] Je sais que le réseau automagique n'existe pas et qu'il faut un
minimum savoir ce que l'on fait. Cependant, dans le cas présent tous les
gens qui mettraient en place ce genre de solutions auraient à peu près
les mêmes problèmes, donc finalement ça ne sert à rien d'écrire la conf
indéfiniment...



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémi Bouhl
Le 25/11/10, Rémy Sanchezremy.sanc...@hyperthese.net a écrit :

 J'ai enfin réussi à bien expliquer ma question ? J'peux recommencer
 sinon j'suis plus à ça près -_-

Tout le monde a compris le problème (plein de gens, font des trucs
très différents en HTTP, pas assez de BP pour tous).

C'est juste que la solution fouiller au niveau 7 n'a pas l'air
d'être la seule réponse, ni même la meilleure.

L'idée plusieurs fois évoquée de partager la BP équitablement (pour
être précis: de garantir un minimum à chaque utilisateur, en toutes
circonstances) est plus simple à mettre en place, plus propre
éthiquement et techniquement, et garantit en toutes circonstances un
équilibre entre les usages.

Pourquoi ne pas l'envisager?

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



Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Rémy Sanchez
On 11/25/2010 12:40 AM, Rémi Bouhl wrote:
 Tout le monde a compris le problème (plein de gens, font des trucs
 très différents en HTTP, pas assez de BP pour tous).

Justement, pas vraiment. C'est une vision plus globale : l'usage des
réseaux change, est-ce qu'il faut pas changer la manière des les
administrer ?

C'est une question de fond, abstraite, générique, pour faire de la
théorie pure et se demander si les choses doivent rester comme ça.

 C'est juste que la solution fouiller au niveau 7 n'a pas l'air
 d'être la seule réponse, ni même la meilleure.
 
 L'idée plusieurs fois évoquée de partager la BP équitablement (pour
 être précis: de garantir un minimum à chaque utilisateur, en toutes
 circonstances) est plus simple à mettre en place, plus propre
 éthiquement et techniquement, et garantit en toutes circonstances un
 équilibre entre les usages.
 
 Pourquoi ne pas l'envisager?

Si bah forcément avec ce qu'on a c'est ce qu'on risque de faire (quoi
qu'on s'en sort bien autrement là). Faut pas croire, on a travaillé les
différentes configs et maintenant on a un service de qualité très
raisonnable tant qu'on cherche pas à voir une vidéo sur youtube.

Mais en fin de compte, si elle était possible, est-ce que l'autre
approche que je propose serait intéressante ? Je ne cherche pas du tout
à la réaliser pour l'instant, je suis à la recherche d'avis purement
théoriques, pour savoir si ça serait une bonne pratique, si ça
apporterait quelque chose, ...

Et au passage si la solution dont je parle existe déjà, ça m'intéresse
aussi.

-- 
Rémy Sanchez



signature.asc
Description: OpenPGP digital signature


Re: [FRnOG] Firewall HTTP

2010-11-24 Par sujet Antoine MUSSO

On 25/11/10 00:04, Rémy Sanchez wrote:
snip

La question porte donc sur les capacités des logiciels actuels en L7 :
sont-ils capable de différencier les différentes applications et de
prendre en compte leurs spécificités ?


  J'ai vu quelques produits capables de différencier les parties 
messageries, photos et chat d'un réseau social bien connu.  Idem pour 
les wikis : différenciations entre consultation et édition.
  Une autre fonction intéressante, était de prioriser les différentes 
requêtes HTTP, en fonction du contenu (js, image, gros paquets / petits 
paquets).


  Est-ce que çà a une utilité ?  Pour ma boîte probablement pas, on 
doit probablement réserver une certaine quantité de bande passante pour 
quelques sites publics très utilisé et pros (genre pagesjaunes).  Les 
flux métiers passent à coté sur des liaisons dédiées.


  Le problème qu'il peut éventuellement se poser, c'est le SSL.  Mais 
là encore, on peut très bien terminer le flux sur un boitier puis 
resigner pour l'utilisateur.  Dans une entreprise, c'est potentiellement 
assez simple puis qu'il y a une charte d'utilisation, on peut même 
envisager des exceptions (consultation à la CPAM, banque ...).


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