Autant Renater porte aussi des services très spécifiques, comme la synchronisation temps-fréquence par wave dédié à plusieurs dizaines de laboratoires partout en France (https://www.renater.fr/reseau/reseaux-de-recherche/refimeve/). Pas sûr qu'un tel partenariat (LPL et SYRTE pour la chaîne laser et la métrologie, Renater pour l'infra fibre) ne soit possible en remplaçant Renater par un opérateur d'infra privé, mais je ne demande qu'a être surpris !

Même avec des opérateurs privés, j'imagine que c'est faisable. Certains opérateurs fibre "long distance" proposent des "alien wavelength" : transporter des longueurs d'onde (couleur, lambda, wavelength) non standard, non allumée par l'opérateur mais par le client, sur le réseau de l'opérateur. L'opérateur s'occupe du transport, de la réamplification, de la surveillance de la puissance optique, et rien d'autre.
Non standard, c'est des signaux différents de Ethernet / Fibre-Channel / OTN.
Vu que les limites de responsabilité client-fournisseur sont différentes, ça nécessite des interactions différentes entre NOC opérateur et NOC client.
J'avais lu un article aux USA sur des téléport (station satellite) redondants qui transportaient entre eux des signaux radiofréquence en analogique sur un lambda optique, en passant par un réseau d'opérateur privé tiers. C'était pour faire de la "diversité d'antenne" en cas de forte précipitations, dans des régions très pluvieuses. Avec commutation en moins d'1 milliseconde. 
Je ne sais pas si ça se fait en France, via des opérateurs nationaux. Techniquement, c'est faisable vu que Renater le fait.

Leon.

Vu que quelqu'un a mentionné HADOPI, une partie de la réponse est peut-être là.

RENATER inclut une forme de contrôle parental / DNS menteur, blocage de ports et autre.

Je pense que c'est pas Renater qui fait ça. C'est de notoriété publique que les blocages par DNS menteurs imposés aux FAI ne sont que rarement appliqués sur les site connectés via renater. Je viens de tester à l'instant sur eduroam à Toulouse, zéro blocage type DNS menteur. Il semblerait quelques trucs soient bloqués sur des ports connus (DNS en UDP ou encore SMTP/port 25) mais ssh ou tor fonctionnent vers l'extérieur sans aucun soucis. De mémoire certains trucs sont bloqués en mode IDS avec rupture de la connexion mais c'est pareil je suis pas bien sur que ça soit renater, je pense que c'est plutôt la DSI de l'établissement qui fait ce qu'elle veut.
Après quand j'étais en résidence étudiante c'était sur le campus et on avait une IP publique direct dans les chambres avec 0 restrictions et connexions entrantes autorisées, à ce moment du début de renater c'était justifié au sens ou c'était des services qui auraient coutés des sommes astronomiques s'ils avaient été sous-traités à des opérateurs privés de l'époque.

Renater en tant que fournisseur d'accès à internet a des obligations de neutralité (enfin depuis que c'est une obligation européenne, cela a moins de 10 ans).

Le filtrage peut être effectué, mais plus bas et uniquement quand l'accès internet n'est pas ouvert au public (destiné à un nombre fermé de personnes).

Pour donner la limite, le Wi-Fi d'un restaurant dans la rue doit être neutre, tandis que le Wi-Fi d'un restaurant d'entreprise n'a pas cette obligation.

Du DPI ?

Cela semble très limite au niveau légalité si c'est fait par le fournisseur d'accès à internet.

Le DPI (Deep packet inspection) est interdit, même pour catégoriser le trafic :

Extrait du rapport Arecp état de l'internet 2020 (page 66) : Le règlement Internet ouvert permet aux FAI d’accéder qu’aux informations contenues dans l’en-tête du parquet IP et dans l’en-tête du protocole de la couche transport (par exemple l’en-tête TCP ou l’en-tête UDP) dont les noms de domaine et URL sont exclus. Par ailleurs, dans une lettre rendue publique, le Comité européen de la protection des données (EDPB) qui a été saisi pour avis, précise que le nom de domaine et l’URL peuvent être qualifiés de données à caractères personnels et à ce titre sont protégées par les dispositions de la directive vie privée et communications électroniques et du règlement général sur la protection des données. Ainsi, les FAI qui utiliseraient le nom de domaine ou les URL à des fins de catégorisation de trafic ou de facturation s’exposeraient non seulement à une violation potentielle du règlement internet ouvert, mais aussi à une possible violation de la protection des données à caractère personnel de leurs clients.

Cette année, en 2021, l'Arcep nous propose de nouveaux schémas explicatif sur TCP/IP, ce qui est neutre ou pas :

Plusieurs principes intrinsèques au fonctionnement d’internet découlent du modèle TCP/IP : le fonctionnement autonome des couches réseaux (layering principle), le principe du « meilleur effort » dans l’acheminement des données (best effort principle), le principe de bout-en-bout (end-to-end principle) ou encore le principe de transparence du réseau (network transparency).
Chaque couche réseau fonctionne de manière autonome : la segmentation des différentes fonctionnalités d’internet implique que les couches réseaux inférieures se concentrent sur l’acheminement des données utiles qui leur sont confiées (adressage et routage de l’information transmise), laissant la responsabilité des autres fonctionnalités (traitement et présentation des données acheminées) à la couche supérieure, dite applicative (cf. schéma synthétique du modèle TCP/IP). Pour éviter que les données transmises ne se perdent lorsqu’elles passent successivement les couches réseaux, chaque couche réseau ajoute des informations essentielles aux données transmises, qui sont regroupées dans un en-tête positionné au début de chaque paquet de données transféré par la couche précédente (cf. schéma synthétique du mécanisme d’encapsulation).




Seules les informations contenues dans l’en-tête destinée à une couche réseau sont utilisées par cette dernière. A titre d’exemple, la couche transport utilise les informations de l’en-tête « transport » pour acheminer les données reçues, mais n’est théoriquement pas en mesure de savoir si les données reçues de la couche applicative sont celles d’un email, d’une vidéo ou d’une page web. Cela implique de facto la circulation des données transmises de manière indifférenciée et de la meilleure manière possible dans les différentes couches traversées, conformément au principe du « meilleur effort ». Selon le principe de « bout-en-bout », seuls les services de la couche applicative, s’assurent de vérifier de l’intégralité et de la conformité des données transmises. Enfin, la segmentation des différentes fonctionnalités d’internet en couches réseaux rend le fonctionnement des couches réseaux inférieures transparent pour les services appartenant à la couche applicative. Ainsi, l’utilisateur final est en théorie libre d’utiliser le terminal ou le système opérateur de son choix, car leur fonctionnement reste indépendant du fonctionnement des couches réseaux inférieures.



L’architecture d’Internet selon le modèle TCP/IP permet une segmentation de ses fonctionnalités et le recours à des conventions communes de fonctionnement que sont les protocoles réseaux. Cette uniformisation offre un cadre homogène au sein duquel les utilisateurs finaux disposent d’une égalité de traitement dans l’accès ou la diffusion par les réseaux de leurs contenus, de leurs services ou de leurs applications. En effet, internet incite les utilisateurs finaux à avoir une participation active dans la création de nouveaux contenus au niveau de la couche applicative, en disposant d’un cadre connu et en leur évitant de prendre en compte le fonctionnement des couches réseaux inférieures (cf. le principe de transparence du réseau). De plus, le recours à des protocoles réseaux, communément admis au sein d’une même couche, réduit les coûts de création d’un nouveau service par l’utilisateur final, favorisant de facto l’innovation. Ainsi, internet reste un environnement moteur de l’innovation.

Là, c'est bien au niveau de RENATER, puisque cela revient vers les universités ensuite. Je ne pense pas qu'il y ait de DPI, mais simplement dans le routage de vérifier quelle adresse IP est demandée. Ce n'est pas une interception des connexions TCP, puisque c'est une vérification a posteriori dans les logs de RENATER. Un peu comme on vérifie dans les logs d'un serveur web, quelles IP se sont connectées.

Il se peut qu'au moment de la première connexion, l'IP concernée n'était pas connue comme celle d'un malware, mais qu'elle ait été identifiée ensuite, d'où le recul nécessaire.

Renater assure aussi le mail Partage.