Support de Cours n°1 Introduction Sécurité Multicast

Transcription

Internet Nouvelle Génération
Module de M1 de la Spécialité Réseaux
(Mention Informatique)
2e semestre 2009 - 2010
Université Pierre et Marie Curie
Support de Cours n°1
Introduction
Sécurité
Multicast
Bénédicte LE GRAND
Prométhée SPATHIS
Organisation du module

Internet Nouvelle Génération

20 h de cours
40 h de TDs et TMEs



7 séances de TDs
3 séances de TMEs
Intervenants

Bénédicte Le Grand

Laboratoire CNRS-LIP6

Université Pierre et Marie Curie, laboratoire LIP6
Prométhée Spathis

Université Pierre et Marie Curie, laboratoire LIP6
[email protected]
1
2
Contrôle des connaissances

Lecture d’articles
Examen réparti


40 % et 60 %

Analyse critique d’articles

Conférence renommée

http://conferences.sigcomm.org/sigcomm/2008/program.php
Présentation orale avec transparents





Contexte et problématique
Solution
Commentaire
Travail individuel ou en binôme (recommandé)
10 minutes par personne
3
4
Procédure pour le choix d’article

http://conferences.sigcomm.org/sigcomm/2009/program.php

Choisir 3

Envoyer un mail à [email protected] avec






5
papiers (Attention : papier ≠ session)
Nom (s)
Groupe de TD (lundi après-midi, mercredi matin ou mercredi
après-midi)
1er choix de papier (papier préféré)
2e choix de papier
3e choix de papier
ATTENDRE LE MAIL DE CONFIRMATION SINON
RELANCER
6
1
Prérequis

Objectifs du module
Module ARES



Menaces de sécurité

Nouveaux besoins applicatifs

Évolutions et mécanismes d’adaptation


Intra-domaine
TCP


Adressage, masques, subdivision de réseau…
Routage
g

Croissance de l’Internet

IPv4




Contrôle de congestion


Applications



Introduction
Sécurité
I t d ti
Introduction
Fonctionnalités avancées de TCP
Ingénierie de trafic
Multicast
IPv6
Routage
Outils de simulation
7
8
Plan du module
Programme ING février 2010
Programme des TD/TME
Programme du cours








Introduction - contexte
Sécurité (TD)
Multicast (TD)
Architectures de Qualité de service ((TD et
TME)
Contrôle de trafic (TME)
Extensions de TCP (TME)
Routage BGP (TD)
IPv6 (TD+TME)
1
08/02
Introduction
2
15/02
Sécurité
3
22/02
Fin sécurité - Multicast
1
15/02
TD révisions
2
22/02
TD sécurité
3
01/03
TD Multicast
4
01/03
Fin Multicast
5
08/03
BGP
4
08/03
TDBGP
6
15/03
Préparation TME1
5
15/03
TME 1 - NS
7
29/03
Préparation TME2 + QoS
6
29/03
TD QoS
05/04
FERIE
7
05/04
TME2 – NS (sauf le lundi)
8
12/04
Fin QoS + IPv6
8
12/04
TD IPv6
9
03/05
Fin IPv6
9
03/05
TME IPv6
10
10/05
Révisions
10
10/05
Séance présentations orales
17/05
Récupération TME 2
10
9
Groupes de TD

Références
Mercredi de 13h30 à 18h


Bénédicte Le Grand (+ Pascal Anelli et Guillaume Valadon)
Bâtiment 41 salle 320

Livres


Jeudi de 8h30 à 12h45



Prométhée Spathis (+ Pascal Anelli et Guillaume Valadon)

Vendredi de 13h30 à 18h


Hicham Khalife (+ Pascal Anelli et Guillaume Valadon)

11
Kurose, J. F. et Ross, K. W. (2002). Ed. : Addison Wesley,
Second Edition. Computer Networking – A Top-Down
A
Approach
hF
Featuring
t i the
th Internet
I t
t
Tanenbaum, A. (1997). Ed. : InterEditions, 3e édition.
Réseaux: Architectures, Protocoles, Applications
Pujolle, G : Les Réseaux, Ed. Eyrolles
12
2
Plan du cours
Internet : contexte actuel

Historique

Croissance
Architecture et gouvernance
Principes fondateurs
Services et applications



13
Les débuts de l’Internet…

Cahier des charges initial
« Etat des lieux » (~1965)



14

Environnement hétérogène
Machines capables de communiquer
Pas de connectivité globale




Pourquoi interconnecter ?


Gestion de terminaux
Messagerie
Transfert de fichiers
Structures de réseaux trop disparates


Applications
Contraintes

Communication
Ressources distantes

Sauvegarder l'existant
Extensibilité


interconnecter les réseaux à venir
Diffusion gratuite et large
15
« Esprit » TCP/IP

16
Principes, « Philosophie » de l’Internet
Inter – net : Interconnexion de réseaux

Protocoles hétérogènes


Architecture opérationnelle



Standard de fait

Adressage hétérogène


17
Virtualisation du réseau
Protocole fédérateur
Conversion au niveau réseau
Adressage universel
Procédures de conversion
18
3
Différents types de commutation
Histoire de l'Internet
1961-1972 : premiers principes de la commutation de paquets




1961 : Kleinrock – (théorie
des files d'attente : efficacité
prouvée de la commutation
de paquets)
1964 : Baran – commutation
de paquets dans les réseaux
militaires
1967 : ARPAnet conçu par
l'Advanced Research Projects
Agency(DoD)
1969 : premier noeud
ARPAnet opérationnel

1972 :
 Démonstration publique
d'ARPAnet
 NCP (Network Control
Protocol) premier protocole
hôte-hôte
 Premier programme e-mail
 ARPAnet contient 15
noeuds
19
20
1961-1972 : premiers principes de la commutation de paquets




1961 : Kleinrock – (théorie
des files d'attente : efficacité
prouvée de la commutation
de paquets)
1964 : Baran – commutation
de paquets dans les réseaux
militaires
1967 : ARPAnet conçu par
l'Advanced Research Projects
Agency(DoD)
1969 : premier noeud
ARPAnet opérationnel

1972-1980 : Interconnexion, réseaux nouveaux et propriétaires
1972 :
 Démonstration publique
d'ARPAnet
 NCP (Network Control
Protocol)
otoco ) p
premier
e e p
protocole
otoco e
hôte-hôte
 Premier programme e-mail
 ARPAnet contient 15
noeuds







1970: réseau de satellites
ALOHAnet à Hawaii
1972 : Début des spécifications
de TCP/IP
1973 : la thèse de Metcalfe’s
propose Ethernet
1974 : Cerf and Kahn architecture pour
l'interconnexion de réseaux
Fin des 70’s : architectures
propriétaires : DECnet, SNA,
XNA
Fin des 70’s : paquets
commutés de longueur fixe
(précurseur d'ATM)
1979 : ARPAnet contient 200
noeuds
Principes d'interconnexion de
Cerf and Kahn’s :
 minimalisme, autonomie –
pas de changements
internes requis pour
interconnecter des réseaux
 Modèle de service "au
mieux" (best effort)
 Routeurs sans état
 Contrôle décentralisé
Définition de l'architecture
actuelle de l'Internet
21
22
1980-1990 : nouveaux protocoles, prolifération de réseaux





1980 : Unix BSD 4.1 inclut TCP/IP
1982 : définition du protocole d'e-mail
SMTP
1983 : déploiement de TCP/IP
1983 : ARPANET bascule sous TCP/IP
1983 : ARPANET se sépare en 2 réseaux









1990, 2000’s : commercialisation, Web, nouvelles applications
Nouveaux réseaux nationaux :
Csnet, BITnet, NSFnet, Minitel
100 000 hôtes connectés à
une confédération de réseaux


ARPANET pour la recherche
MILNET pour les communications militaires
1983 : DNS défini pour la traduction
nom/adresse-IP
1985 : la NSF (National Science
Foundation) déploie un réseau fédérateur
grande distance, NFSNET, relié à
ARPANET
1985 : définition du protocole FTP
1988 : contrôle de congestion de TCP
1989 : Naissance du World-Wide Web au
CERN

Début des 90’s : ARPAnet
décommissionné
1991 : NSF lève les restrictions sur
l'utilisation commerciale de NSFnet
(décommissioné, 1995)
Début des 90s : Web
 Hypertexte
 HTML, HTTP : Berners-Lee
 1994 : Mosaic, plus tard Netscape




23
Activité commerciale
1993 : Gestion de la pénurie d'adresses
1994 : Décision IPv6
1996 : Premier déploiement du 6-BONE
Fin des 90’s – 2000’s:

Plus de "killer" applications :
messagerie instantanée,
partage de fichiers par P2P (ex
Napster)

Sécurité des réseaux au
premier plan

Estimation de 50 millions
d'hôtes, plus de 100 millions
d'utilisateurs

Les liens backbone
fonctionnent à plusieurs Gbps
24
4
Plan du cours
Internet aujourd'hui

Historique

Croissance



25
WORLD INTERNET USAGE
AND POPULATION STATISTICS
World Regions
Population
( 2006 Est.)
Population
% of World
915,210,928
Africa
Asia
Europe
14.1 %
Internet
Usage,
Latest Data
%
Population
( Penetration )
2.5 %
22,737,500
TOP 20 COUNTRIES WITH HIGHEST NUMBER OF INTERNET USERS
#
Usage
% of
World
2.2 %
56 4 %
56.4
364 270 713
364,270,713
99%
9.9
35 7 %
35.7
218 7 %
218.7
807,289,020
12.4 %
290,121,957
35.9 %
28.5 %
176.1 %
190,084,161
2.9 %
18,203,500
9.6 %
1.8 %
454.2 %
North America
331,473,276
5.1 %
225,801,428
68.1 %
22.2 %
108.9 %
Oceania / Australia
WORLD TOTAL
553,908,632
8.5 %
33,956,977
0.5 %
6,499,697,060
100.0 %
14.3 %
79,033,597
52.9 %
17,690,762
15.7 %
1,018,057,389
7.8 %
1.8 %
100.0 %
337.4 %
132.2 %
27
182.0 %
Country or Region
Penetration
(% Population)
Internet Users
Latest Data
Population
( 2006 Est. )
Malta
78.1 %
301,000
385,308
ITU - Sept/05
New Zealand
76.3 %
3,200,000
4,195,729
ITU - Sept/05
3
Iceland
75.9 %
225,600
297,072
ITU - Sept/05
4
Sweden
74.9 %
6,800,000
9,076,757
ITU - Oct/05
5
Denmark
69.4 %
3,762,500
5,425,373
6
Hong Kong
69.2 %
4,878,713
7,054,867
Source and Date
of Latest Data
68.1 %
% Users
of World
2
China
111,000,000
1,306,724,067
3
Japan
86,300,000
128,389,000
4
India
50,600,000
1,112,225,812
4.5 %
C.I.Almanac Mar/05
5
Germany
48,722,055
82,515,988
59.0 %
C.I.Almanac Mar./05
4.8 %
6
United Kingdom
37,800,000
60,139,274
62.9 %
ITU Oct/05
3.7 %
7
Korea (South)
33,900,000
50,633,265
67.0 %
eTForecast Dec/05
3.3 %
8
Italy
28,870,000
59,115,261
48.8 %
ITU Sept./05
9
France
26,214,174
61,004,840
43.0 %
Nielsen//NR Dec/05
2.6 %
10
Brazil
25,900,000
184,284,898
14.1 %
eTForcasts Dec/05
2.5 %
11
Russia
23,700,000
143,682,757
16.5 %
eTForcasts Dec/05
2.3 %
12
Canada
21,900,000
32,251,238
67.9 %
eTForcasts Dec/05
13
Indonesia
18,000,000
221,900,701
8.1 %
eTForcasts Dec/05
1.8 %
14
Spain
17,142,198
44,351,186
38.7 %
Nielsen//NR Dec/05
1.7 %
15
Mexico
16,995,400
105,149,952
AMIPCI Nov/05
1.7 %
16
Australia
14,189,544
20,750,052
68.4 %
Nielsen//NR Dec/05
1.4 %
17
Taiwan
13,800,000
22,896,488
60.3 %
C.I.Almanac Mar/05
18
Netherlands
10,806,328
16,386,216
65.9 %
Nielsen//NR June/04
1.1 %
19
Poland
10,600,000
38,115,814
27.8 %
C-I-A Mar./05
1.0 %
Nielsen//NR Dec/05
20.0 %
8.5 %
CNNIC Dec/05
10.9 %
67.2 %
eTForecasts Dec/05
8.5 %
20
Turkey
16.2 %
5.0 %
2.8 %
2.2 %
1.4 %
10,220,000
74,709,412
13.7 %
ITU Sept./05
1.0 %
TOP 20 Countries
810,484,127
4,064,319,458
19.9 %
IWS - Dec.31/05
79.6 %
Rest of the World
207,573,262
2,435,377,602
8.5 %
IWS - Dec.31/05
20.4 %
1,018,057,389
6,499,697,060
15.7 %
IWS - Dec.31/05
Total World – Users
28
100.0 %
TOP 20 COUNTRIES WITH THE HIGHEST NUMBER OF
INTERNET DSL BROADBAND SUBSCRIBERS - 2004 Q4
#
1
Internet
Penetration
299,093,237
Source and Date
of Latest Data
2
Population
( 2006 Est. )
203,824,428
TOP 20 COUNTRIES WITH THE HIGHEST INTERNET PENETRATION RATE
#
Internet Users,
Latest Data
United States
403.7 %
3 667 774 066
3,667,774,066
Country or Region
1
Usage
Growth
20002005
Middle East
Latin America/Caribbean
26
Country or Region
DSL Broadband
Subscribers
Internet Users
Latest Data
Population
( 2005 Est. )
Source and Date
of Usage Data
1
United States
33,900,000
199,861,345
293,271,500
2
China
25,800,000
94,000,000
1,288,307,100
CNNIC - June/04
3
Japan
12,739,564
66,586,234
127,853,600
Nielsen//NR Nov./04
Nielsen//NR Feb./05
4
Korea, (South)
11,900,000
30,670,000
49,131,700
KRNIC - June/04
ITU - Sept/05
5
Germany
5,950,000
46,455,814
82,633,200
Nielsen//NR Oct./04
Nielsen//NR Feb./05
6
France
5,253,000
24,803,250
60,011,200
Nielsen//NR Oct./04
C.I.Almanac - Dec/03
Australia
68.4 %
14,189,544
20,750,052
Nielsen//NR Dec/05
7
Italy
3,680,000
28,610,000
57,987,100
8
United States
68.1 %
203,824,428
299,093,237
Nielsen//NR Dec/05
8
United Kingdom
3,335,000
34,874,469
59,595,900
9
Canada
67.9 %
21,900,000
32,251,238
eTForecasts Dec/05
9
Taiwan
2,900,000
11,602,523
22,689,300
Nielsen//NR June/01
10
Canada
2,568,351
20,450,000
31,846,900
C.I.Almanac - Dec/03
11
Spain
2,227,805
14,095,951
41,895,600
Nielsen//NR Oct./04
12
Brazil
1,633,700
18,660,650
179,383,500
Nielsen//NR Oct./04
13
Netherlands
1,552,000
10,806,328
16,254,900
Nielsen//NR Oct./04
7
10
Norway
67.8 %
3,140,000
4,632,911
C.I.Almanac Mar/05
11
Singapore
67.2 %
2,421,800
3,601,745
ITU - Oct/05
12
Japan
67.2 %
86,300,000
128,389,000
eTForecasts Dec/05
13
Korea, (South)
67.0 %
33,900,000
50,633,265
eTForecasts Dec/05
14
Greenland
66.5 %
38,000
57,185
ITU - Oct/05
15
Switzerland
66.0 %
4,944,438
7,488,533
Nielsen//NR Dec/05
16
Netherlands
65.9 %
10,806,328
16,386,216
Nielsen//NR Jun/04
17
United Kingdom
62.9 %
37,800,000
60,139,274
18
Finland
62.5 %
3,286,000
5,260,970
ITU - Oct/05
29
ITU - Sept/05
Nielsen//NR Oct./04
14
Belgium
983,000
3,769,123
10,402,200
Nielsen//NR Apr./02
15
Australia
910,000
13,410,833
20,275,700
Nielsen//NR Oct./04
16
Hong Kong
774,000
4,878,713
6,727,900
Nielsen//NR Oct./04
17
Sweden
751,000
6,722,564
9,010,700
Nielsen//NR Oct./04
18
Switzerland
717,000
4,585,364
7,433,000
Nielsen//NR Oct./04
19
Israel
600,000
2,000,000
6,867,200
ITU - Apr./02
20
Denmark
DSL - TOP 20 Countries
Rest of the World
Total World - DSL Users
594,000
3,375,850
5,397,600
Nielsen//NR June/02
80,179,987
640,219,011
2,676,975,800
IWS - Jan.20/05
5,120,013
179,712,581
3,713,171,687
IWS - Jan.20/05
85,300,000
819,931,592
6,390,147,487
IWS - Jan.20/05
30
5
Connectivité
Revenus générés par l'Internet
31
Répartition
32
Europe
33
34
T
o
p
o
l
o
g
i
e
http://www.caida.org/tools/measurement/skitter/visualizations.xml
35
36
6
Index de trafic
Commerce électronique
http://www.internettrafficreport.com/main.htm
37
38
DATE
% WORLD
POPULATION
NUMBER OF USERS
INFORMATION
SOURCE
History and Growth of the Internet
Nombre d'hôtes
December, 1995
16 millions
0.4 %
IDC
December, 1996
36 millions
0.9 %
IDC
December, 1997
70 millions
1.7 %
December, 1998
147 millions
3.6 %
C.I. Almanac
December, 1999
248 millions
4.1 %
Nua Ltd.
March, 2000
304 millions
5.0 %
Nua Ltd.
July, 2000
359 millions
5.9 %
Nua Ltd.
December, 2000
451 millions
7.4 %
Nua Ltd.
March, 2001
458 millions
7.6 %
Nua Ltd.
June, 2001
479 millions
7.9 %
Nua Ltd.
August, 2001
513 millions
8.6 %
Nua Ltd.
April, 2002
558 millions
8.6 %
Internet World Stats
July, 2002
569 millions
9.1 %
September, 2002
587 millions
9.4 %
March, 2003
608 millions
9.7 %
September, 2003
677 millions
10.6 %
October, 2003
682 millions
10.7 %
December, 2003
719 millions
11.1 %
February, 2004
745 millions
11.5 %
May, 2004
757 millions
11.7 %
October, 2004
812 millions
12.7 %
December, 2004
817 millions
12.7 %
March, 2005
888 millions
13.9 %
June, 2005
39
IDC
14.6 %
September, 2005
957 millions
14.9 %
November, 2005
972 millions
15.2 %
December, 2005
1,018 millions
15.7 %
Top Ten Parent Companies in
Internet
938 millions
40
The Top Ten Brands in Internet
according to Nielsen NetRatings
according to Nielsen NetRatings
( PARENT COMPANIES OWNING MULTIPLE DOMAINS OR URLs)
#
#
Company or Parent
1
Microsoft
2
Yahoo!
Unique Audience
May 2005
Time per Person
( hh:mm:ss )
107 450 000
107,450,000
2:01:06
97,499,000
3:00:30
3
Time Warner
96,911,000
5:24:41
4
Google
77,327,000
0:41:18
5
United States Government
53,881,000
0:26:34
Company or Parent
Unique Audience
May 2005
Time per Person
( hh:mm:ss )
1
Yahoo!
96,930,000
3:00:53
2
Microsoft
90,822,000
0:42:13
3
MSN
88,631,000
1:43:21
4
Google
75,796,000
0:40:32
5
AOL
71,174,000
6:45:06
6
eBay
50,963,000
2:05:45
6
eBay
53,416,000
2:07:10
7
InterActiveCorp
40,949,000
0:22:31
7
MapQuest
36,580,000
0:12:19
8
Amazon
38,694,000
0:22:12
8
Amazon
34,294,000
0:19:49
9
RealNetworks
32,906,000
0:42:54
9
Real
32,300,000
0:41:13
10
Walt Disney Internet Group
32,332,000
41
0:33:14
10
Weather Channel
28,610,000
42
0:25:59
7
Évolution des terminaux
Problèmes de la croissance



Facteur d'échelle
Évolution permanente de la technologie
Actuellement



Pénurie
Pén
rie d'adresses (->
( > IPv6)
IP 6)
Explosion du nombre de routes (-> BGP)
Explosion du nombre de flots (-> Ingénierie de
trafic)
43
Nombreuses dimensions d’échelle
Plan du cours
Nombre d'hôtes globalement routables
Nombreuses couches liaison
Distance géographique
Nombreuses versions logicielles et technologies
matérielles
Éventail des bandes passantes
Différents besoins applicatifs (QoS, etc) (-> QoS)
Niveaux de confiance / frontières administratives
(-> Sécurité)
Prix du matériel








44

Historique
Croissance




45
Éléments de l'Internet

PC, serveur, etc.


Équipement terminal
Exécute des applications réseau
Système de communication


Organisation de l'Internet
Hôte


46
Ligne téléphonique, satellite, fibre
optique, Ethernet, etc.
router
server
workstation
mobile

Interconnexion de réseaux

local ISP
Paq et IP
Paquet

Unité de transfert de données dans
l'Internet

Routeur : propage les paquets vers la
destination

Protocole



regional ISP
équipement intermédiaire
Contrôle l'émission et la réception des
données
TCP, HTTP, FTP, PPP, IP…


company
network
47
Réseau : système connexe sous la tutelle d'une
autorité administrative
Internet : constellation de différents propriétaires
interconnectés
Pas d'administration centrale ou d'opérateur
unique
48
8
Structure de l'Internet


Ex d’ISP de Tier-1 : Sprint
Réseau backbone de Sprint US
Hiérarchique
Au centre: “tier-1” ISPs
couverture nationale / internationale
Les
fournisseurs
de tier-1
s'intercon-nectent
entre eux
(privé)
Tier 1 ISP
NAP
Less fournisseurs
L
f
iss
s
de tier-1 sont
aussi connectés à
des points d’accès
au réseau public
(NAPs)
Tier 1 ISP
Tier 1 ISP
49
50
Structure de l'Internet : réseau de réseaux
Tier-1
ISP

“Tier-2” ISPs : ISPs plus petits (souvent régionaux)

Connectés à un ou plusieurs tier-1 ISPs, éventuellement à d'autres
tier-2 ISPs
un Tier-2 ISP
paye un tier-1
ISP pour la
connectivité au
reste de
l'Internet
 le tier-2 ISP
est client du
provider
tier-1
Tier-2 ISP
Tier 1 ISP
NAP
Tier 1 ISP
Tier 1 ISP
Tier-2 ISP
Les Tier-2
ISP peuventt
ISPs
aussi être
connectés
entre eux et
interconnecter
un NAP
Tier-2 ISP
Tier-2 ISP
Tier-2 ISP
51
52

“Tier-3” ISPs et ISPs locaux


Un paquet traverse de nombreux réseaux !
Réseau du "dernier saut" (réseau d'"accès"), près des terminaux
local
ISP
Tier 3
ISP
local
ISP
local
ISP
local
ISP
local
ISP
Ti 2 ISP
Tier-2
Les ISPs
Tier 2 ISP
Tier-2
locaux et tier3 ISPs sont
Tier 1 ISP
clients des
NAP
ISPs de
niveaux
supérieurs, qui
Tier 1 ISP
Tier 1 ISP
les connectent
au reste de
Tier-2 ISP
Tier-2 ISP
l'Internet
local
local
local
ISP
ISP
ISP
Tier 3
local
local
ISP
Tier-2
Tier
2 ISP
ISP
ISP
ISP
Tier-2 ISP
Tier 1 ISP
Tier 1 ISP
Tier-2 ISP
local
Tier-2 ISP
local
local
ISP
ISP
ISP
53
local
NAP
Tier 1 ISP
Tier-2 ISP
local
Tier-2 ISP
local
ISP
ISP
54
9
Protocoles de l’Internet

Plan du cours
IETF


Historique
Croissance



Internet Engineering Task Force

55
Superposition à l'existant

Général


56
Réseau numérique à commutation de paquets

Particuliers





Interface commune

IP
Bout en bout
"Libéral" quand on reçoit, "conservateur" quand on
transmet
Implémentation avant standardisation



Cacher la multitude des technologies
réseaux
IP ((Internet Protocol))
applica
tion
transp
ort
netwo
rk
data
link
physic
al
netwo
rk
data
link
physic
al
Un seul service utilisé : savoir
convoyer un paquet d'un point à l'un
de ses voisins
netwo
rk
data
link
physic
al
Plan d'adressage unique et
homogène
Introduction de passerelles (routeurs)
57
Pile de protocoles Internet

Application : supporte les applications réseau


Transport : transfert de données entre 2 hôtes


IP, protocoles de routage
Liaison : transfert de données entre des éléments
de réseaux voisins


TCP, UDP
Réseau : routage des datagrammes d
d'une
une source
vers une destination


FTP, SMTP, HTTP
PPP, Ethernet
Physique : bits "sur le câble"
netwo
rk
netwo
data
rk
link
data
physic
link
netwo
al
physic
rk
al
netwo
data
rk
link
data
physic
link
al
netwophysic
rk
al
data
link
netwophysic
al applica
rk
tion
data
transp
link
ort
physic
netwo
al
rk
data
link
physic
58
al
Modèle en couches

application

Encapsulation
Résolution d'adresse (@IP-@physique)
transport
réseau
source
M application
Ht M transport
Hn Ht M
réseau
Hl Hn Ht M
liaison
liaison
physique
physique
59
destination
application
Ht
transport
Hn Ht
réseau
Hl Hn Ht
liaison
physique
M
message
M
M
M
segment
datagramme
trame
60
10
Principe du bout en bout

Principe du bout en bout
Pas d'intelligence dans le réseau




traitement simple dans le réseau -> haut débit
Réseau généraliste -> évolution de l'utilisation du réseau
Pas de redondance de contrôle
Service réseau





Modes d'acheminement
Datagramme
Circuit virtuel
Mode non connecté et sans garantie
Séparation des fonctions


Contrôle -> hôte
Acheminement -> routeur

Robustesse

Indépendance de fonctionnement

Le fonctionnement du système d'extrémité n'est pas lié
à celui du réseau
61
Bout en bout : avantages

62
Libéral / conservateur
Simplicité


Pas de gestion d'états
Interconnexion hétérogène plus facile

Débit écoulé plus important

Évite les contrôles redondants

Infrastructure indépendante du service

Réaction face à la panne

Fonctionnement du système d'extrémité indépendant du réseau

Utilise la puissance de calcul disponible (hôtes)

L'enrichissement du service dépend de l'application


Garantit une connectivité maximale


Évolution du réseau

On accepte tout, au risque de conduire à un
fonctionnement en mode dégradé
On se restreint aux standards p
pour transmettre
Opposé à l'approche OSI (Open System
Interconnection)

Besoin d'une standardisation poussée
63
Implémentation avant standardisation

64
Plan du cours
Un standard est promulgué après validation
par la preuve de son fonctionnement

Historique
Croissance
Pi i
Principes
ffondateurs
d t





Approche expérimentale
65
66
11
Services du réseau

Applications
Besoins des applications

Impact des applications dans le réseau


Service élastique





Flux discrets
Information asynchrone
Variation du service


Service fluide (stream)



Service réseau fourni à l'application

Flux continus
Notion de "temps"
Besoin statistique en terme de délai et de débit


Débit des données
Type de trafic (débit constant ou rafales)
Cible du trafic (multipoint ou destination unique,
mobile
bil ou fifixe))
Sensibilité au délai
Sensibilité à la perte de paquets
Les applications font la loi !
67
Besoins des applications
68
Les données (texte, images, schémas)

Transfert de fichiers

Application
Transfert de fichier
e-mail
Web
Audio/vidéo Temps réel
Audio/vidéo enregistré
Jeux interactifs
Applis financières
Pertes
Bande passante Sensibilité temp.
pertes
Sans p
Sans pertes
tolérant
tolérant
élastique
q
élastique
élastique
audio: 5Kb-1Mb
video:10Kb-5Mb
tolérant
similaire
tolérant
Quelques kbps
Sans pertes élastique


Non
Non
Non
oui, 100’s msec
oui, quelques secs
oui, 100’s msec
Oui et non
Très sensible à la perte d ’information

Des retransmissions peuvent être nécessaires
La taille maximale de chaque bloc transmis doit être
bornée : notion de paquets
Transactionnel

Délai de réponse admissible dépendant de la
sensibilité des usagers : 3 secondes est
couramment admis comme la valeur limite
69
Tranfert de fichiers fiable




70
Connexion distante (remote login)
Sensible à la perte de paquets
Insensible au délai relatif au temps d'aller
retour
Point à point ou multipoint
Point-à-point
Par rafales


Sensible à la perte de paquets
Sensible au délai




71
Sujet à des contraintes d'interaction
Peut tolérer jusqu
jusqu'à
à plusieurs centaines de
millisecondes
Par rafales
Point-à-point
72
12
Audio




Relativement faible bande passante


La voix

Échantillons numérisés, paquétisés

Sensible à la variation du délai
Tolérante aux p
pertes
Possibilité de multipoint, sessions de longue
durée

Numérisation de la voix : codage MIC (PCM)
Voix = signal analogique
Numérisation = échantillonnage + quantification + codage


S
Spectre
t transmis
t
i : 4Khz
4Kh

Quantifiés sur 256 niveaux de quantification

Limite naturelle du nombre d'émetteurs
simultanés
Intérêt de la numérisation : faible taux d’erreur, facilité de
multiplexage



Donc 8000 échantillons/seconde
Codés sur 8 bit
La voix codée MIC génère un flux périodique d ’octets :
1octet/125s
Et donc un débit de 64 Kbit/s
MIC : Modulation par Impulsion Codée
73
74
Codage MIC
La voix
Echantillons

Autres codages
time
Echantillonnage

Suppression des silences

Quantification
Q
tifi ti =>
>
 bruit de quantification

Elimination de la redondance

Echantillons
01001100 01001100 01001100
time
Codage

...


1octet/125s =
64Kbit/s
flux = suite de « talkspurts » et de silences
On arrive à coder la voix à 800bit/s, le résultat est une
voix de mauvaise qualité mais intelligible
La voix GSM est souvent codée à 13Kbit/s
La voix sur Internet est parfois codée à 5.3 Kbit/s
Flux = suite de blocs d’information pouvant être de
longueur variable.
76
75
Qualité de service

La voix est très sensible au délai et à la variation de délai






Vidéo
Délai maximal sans annulation d ’écho : 24ms
Délai maximal avec annulation d ’écho: 300ms
Il y a écho car le signal entrant et sortant sont transmis sur la
même paire torsadée
En codage MIC elle est peu sensible à la perte
d ’information
Elle devient d ’autant plus sensible à la perte qu ’elle est
compressée (que la redondance est éliminée)
Le destinataire doit récupérer l’horloge de la source pour
récupérer le signal original
77






Bande passante élevée
Vidéo compressée, par rafales
La tolérance aux pertes dépend de la
compression
La tolérance au délai dépend de l'interactivité
Possibilité de multipoint
Grand nombre de sources simultanées
78
13
Vidéo : Qualité de service

La vidéo
Moins sensible que la voix à la variation de
délai


Par exemple, des images peuvent éventuellement
être répétées




Plus sensible que la voix aux pertes de
paquets

Vidéo : signal analogique, suite périodique d’images
avec impression de continuité
Numérisation = échantillonnage + quantification +
compression + codage
Echantillonnage :
vidéo VHS : 25 images/s,

Taille d’une vidéo VHS : x*y*n*25 bit/s

Par exemple, la perte d ’une information de
contrôle pour le décodeur peut avoir des
conséquences importantes




Image de taille (x,y)
n bits / pixel
25 images par seconde
vidéo faiblement animée : jusqu ’à quelques images par
seconde
Quantification, compression (spatiale +temporelle)
79
Applications "perturbatrices"
(Killer Apps)
Web

Trafic transactionnel





Requêtes courtes, réponses potentiellement
longues


Peu sensible à la perte de de paquets (!)
Sensible au délai

80


Interactivité humaine

Point-à-point (le multipoint est asynchrone)


81
Applications qui perturbent le commerce classique
Difficiles à prédire
Le Web peut être vu comme l'une des premières, et
peu l'ont vu venir
Napster est un autre exemple
Gnutella, Kazaa, edonkey, BitTorrent
Messagerie instantanée (icq, messenger)
VoIP (skype)
Quelles seront les prochaines ?
82
Statistiques de téléchargement de Skype
Skype
Skype est le leader sur le marché de la voix sur
IP (VoIP)
* Plus de 24 millions d’utilisateurs
d utilisateurs enregistrés
* SkypeOut : plus de 735 000 utilisateurs dans le
monde
83
84
14
Stats des utilisateurs Skype par mois
Nouvelles fonctions : les 3 M

Mobilité (-> UE MOB)
Nomadisme : changement de connectivité de l'hôte
Micro-mobilité : déplacement de l'hôte dans un réseau
cellulaire



Multimédia
Support des flots continus


Multi-destination (communication de groupe)
Information émise une seule fois et reçue par chaque
membre du groupe (-> Multicast)

85
Multimédia
86
Exemples de services


Définition de flux multimédia

Ensemble de flux liés par des contraintes de
synchronisation






Synchronisation des lèvres
Insertion d’images et graphiques


Au respect des contraintes temporelles individuelles,
s ’ajoutent les contraintes temporelles multimédia



Le transfert de fichiers peut hériter les contraintes
temporelles des flux synchrones



Remarque : les applications multimédia sont
souvent multiparties



Vidéo-téléphonie
Vidéoconférence
Télé-enseignement
Télé-médecine
Travail en groupe
Calcul distribué
Jeux distribués dans un environnement de réalité virtuelle
(télé-cyberspace)
Vidéosurveillance
Liés à la géolocalisation
Navigation
Peer-to-peer (P2P)
Commerce électronique
Besoin de mécanismes de multicast
87
Classification des services


téléphonie
De messagerie


Points abordés :
Conversationnels


E-mail, messagerie unifiée

Transactionnels


Contexte actuel de l’Internet : résumé
Interactifs


Achat en ligne


De distribution

Sans contrôle de la part des destinataires

Avec contrôle de la part des destinataires



88
Principes de l'Internet
Historique et croissance
Applications
Structure de l'Internet et des ISPs
Couches et modèle de service
Radio, Télévision
Vidéo à la demande
Filtrage de news
89
90
15
Croissance et évolution des services
Programme ING février 2010
Programme des TD/TME
Programme du cours

Adaptation du réseau







Sécurité
Outils de simulation de réseau
Ingénierie de trafic
Architectures de QoS
Multicast
IPv6
Routage inter-domaine
1
08/02
Introduction
2
15/02
Sécurité
3
22/02
Fin sécurité - Multicast
4
01/03
Fin Multicast
5
08/03
6
7
1
15/02
TD révisions
2
22/02
TD sécurité
3
01/03
TD Multicast
BGP
4
08/03
TDBGP
15/03
Préparation TME1
5
15/03
TME 1 - NS
29/03
Préparation TME2 + QoS
6
29/03
TD QoS
05/04
FERIE
7
05/04
TME2 – NS (sauf le lundi)
8
12/04
Fin QoS + IPv6
8
12/04
TD IPv6
9
03/05
Fin IPv6
9
03/05
TME IPv6
10
10/05
Révisions
10
10/05
Séance présentations orales
17/05
Récupération TME 2
92
91
16
Sécurité des réseaux
Sécurité
Objectifs
 Comprendre les
principes de la sécurité
des réseaux




Plan
Amis et ennemis : Alice, Bob, Trudy


Firewalls
Attaques et parades
sécurité
é ité d
dans lles
couches




Application
Transport
Réseau
Liaison
manière sûre"
Trudy (intrus) peut intercepter, effacer et ajouter
g
des messages
Alice
canal
Émetteur
sécurisé
Messages de
données et de
contrôle
Récepteur
sécurisé
Confidentialité : seuls l'émetteur et le récepteur visé
doivent pouvoir comprendre le contenu du message
 L'émetteur chiffre le message
 Le récepteur déchiffre message
Authentification : ll'émetteur
émetteur et le récepteur veulent
confirmer l'identité de leur correspondant
Intégrité du message : l'émetteur et le récepteur
veulent s'assurer que le message n'a pas été altéré
(durant le transit, ou après) sans que cela n'ait été
détecté
Accès et disponibilité : les services doivent être
accessibles et disponibles pour les utilisateurs
Qui pourraient être Bob et Alice?
 Bien connus dans le monde de la sécurité !
 Bob, Alice (amants !) veulent communiquer "de
données

Qu'est-ce que la sécurité des réseaux ?
1 Qu'est-ce que la sécurité ?
2 Principes de cryptographie - confidentialité
3 Authentification
4 Intégrité
5 Distribution de clés et certification
6 Contrôle d'accès : firewalls
7 Attaques and parades
8 Sécurité dans plusieurs couches

Cryptographie et ses
nombreux usages en
dehors de la
confidentialité
Authentification
Intégrité des messages
Distribution des clés
 sécurité en pratique
Bob
data
 … des êtres humains !
 Des serveurs ou browsers Web pour des




transactions électroniques (ex : achats en
ligne)
Client/serveur de banque en ligne
Serveurs DNS
Routeurs échangeant des mises à jour de
tables de routage
...
Trudy
1
Il y a des méchants !
Plan
Q : Que peut faire un "méchant" ?
R : Beaucoup de choses!
Écoute : interception de messages
 Insertion active de messages dans la connection
 Imitation : falsification (spoof) de l'adresse source
d
dans
lle paquett ((ou ttoutt autre
t champ
h
du
d paquet)
t)
 Détournement : “prise de contrôle” de la connexion
en cours en écartant l'émetteur ou le récepteur et
en prenant sa place
 Déni de service : empêcher le service d'être utilisé
par les autres (ex : en surchargeant les
ressources)

Vocabulaire de cryptographie
Clé de
K chiffrement
A
d'Alice
Texte en clair
Algorithme
de chiffrement
Texte chiffré
3 Authentification
4 Intégrité
6 contrôle d'accès : firewalls
Cryptographie à clé symétrique
K
Chiffrement par substitution
Clé de
déchiffrement

B de Bob
Substitution monoalphabétique : substituer une lettre par une
autre
Texte brut:
Algorithme
Texte en clair
De déchiffrement
abcdefghijklmnopqrstuvwxyz
T t chiffré:mnbvcxzasdfghjklpoiuytrewq
Texte
hiff é
b
df hjkl i t
Ex : Texte en clair : bob. i love you. alice
Texte chiffré : nkn. s gktc wky. mgsbc
Cryptographie à clé symétrique : clés identiques pour
l'émetteur et le récepteur
Cryptographie à clé publique : clé de chiffrement
publique, clé de déchiffrement secrète (privée)
Cryptographie à clé symétrique : DES
Cryptographie à clé symétrique
KA-B
KA-B
Message en Algorithme msg chiffré Algorithme de
déchiffrement
clair m de chiffrement
K (m)
A-B
B
Avec quelle difficulté peut-on casser un tel chiffrement ?
 Manière brutale ?
 autre ?
Message en
clair
m=K
A-B
( ))
( KA-B(m)
Cryptographie à clé symétrique : Bob et Alice partagent
une même clé (connue) : K A-B
 Ex : la clé consiste à connaître le mode de substitution dans
un chiffrement par subtitution monoalphabétique
 Comment Bob et Alice se mettent-ils d'accord sur la valeur de
DES: Data Encryption Standard
 Standard de chiffrement américain [NIST 1993]
 Clé symétrique sur 56 bits, input plaintext 64 bits
 À quel point le DES est-il sûr ?
Challenge du DES : phrase (“Strong cryptography makes
the world a safer place”) chiffrée avec une clé de 56 bits
déchiffrée en 4 mois (de manière brutale)
 Pas d'approche de déchiffrage "backdoor" connue
 Rendre le DES plus sûr :
 Utilier 3 clés successivement (3-DES) sur chaque donnée
 Utiliser le chaînage par bloc

la clé ?
2
AES : Advanced Encryption Standard
Crypto à clé
symétrique : DES
 Standard NIST à clé symétrique récent (Nov.
Algo du DES
2001), remplaçant le DES
Traite les données par blocs de 128 bits
Clés de 128
128, 192
192, ou 256 bits
Le déchiffrement brutal (essai de toutes les
clés) prenant 1 sec avec le DES prend 149
trillions d'annés pour AES
Permutation initiale
16 boucles identiques
d lla ffonction
de
ti
application, utilisant
chacune 48 bits
différents de la clé
Permutation finale



Cryptographie à clé publique
Cryptographie à clé publique
Crypto à clé symétrique
 Nécessite le partage
d'une clé entre
l'émetteur et le
récepteur
 Q: comment se mettre
d'accord sur la clé au
départ (surtout s'ils ne
se sont jamais
rencontrés) ?
Crypto à clé publique
 Approche radicalement
différente [DiffieHellman76, RSA78]
 LL'émetteur
émetteur et le
récepteur ne partagent
pas de clé secrète
 clé de chiffrement
publique connue de tous
 la clé de déchiffrement
privée n'est connue que
du récepteur
Algorithmes de chiffrement par clé
publique
Besoins :
1
Besoin de K +( ) et de K -( ) telles que
.
-
B
+
B
B
.
B
K ((K ((m))
)) = m
+
2 À partir de la clé publique KB , il
devrait être impossible de
calculer la clé privée K B
RSA : algorithme de Rivest, Shamir, Adelson
+ Clé publique
B de Bob
K
K
Message en
Algorithme
Msg chiffré
+
clair m
de chiffrement
K (m)
B
- Clé privée de
B Bob
Algorithme de Message en
déchiffrement
clair
-
+
m = K B(K (m))
B
RSA : choix des clés
1. Choisir deux grands nombres premiers p, q.
(ex 1024 bits chacun)
2. calculer n = pq, z = (p-1)(q-1)
3. choisir e (avec e<n) n
3
n'ayant
ayant aucun facteur commun
avec z. (e et z sont premiers entre eux).
4. choisir d tel que ed-1 soit divisible par z.
(ed mod z = 1 ).
5. La clé publique est (n,e). La clé privée est (n,d).
+
KB
-
KB
3
RSA : chiffrement, déchiffrement
0. soient (n,e) et (n,d) calculés comme précédemment
1. Pour chiffrer le caractère m, calculer
e
c = m e mod n (cad le reste de la division de m par n
2. Pour déchiffrer le caractère c, calculer
m = c d mod n (cad le reste de la division de c d par n)
Exemple RSA :
Bob choisit p=5, q=7. alors n=35, z=24.
e=5 (e et z premiers entre eux).
d=29 (ed-1 divisible par z).
letter
m
me
l
12
1524832
Chiffrement
c
Déchiffrement 17
m = (m e mod n) d mod n
c = me mod
d n
d
c
481968572106750915091411825223071697
c
RSA : pourquoi ?
m = (m e mod n) d mod n
résultat intéressant de la théorie des nombres : If
p,q premiers et y
y mod (p-1)(q-1)
mod n
n = pq, then: x mod n = x
e
((m mod n)) d mod n = m edmod n
= m
ed mod (p-1)(q-1)
mod n
(using number theory result above)
1
= m mod n
(since we chose ed to be divisible by
(p-1)(q-1) with remainder 1 )
17
m = cd mod n letter
12
l
RSA : autre propriété importante
La propriété suivante sera très utile plus tard:
-
+
B
B
+
B
B
K (K (m)) = m = K (K (m))
Utiliser la clé
publique, PUIS
la clé privée
Utiliser la clé
privée, PUIS la
clé publique
Le résultat est le même !
= m
Plan
3 Authentification
4 Intégrité
Authentification
But : Bob veut qu'Alice lui “prouve” son identité
Protocole ap1.0: Alice dit “Je suis Alice”
“Je suis Alice”
Scénario d'échec ?
4
Authentification
Authentification : autre tentative
But : Bob veut qu'Alice lui “prouve” son identité
Protocole ap2.0 : Alice dit “Je suis Alice” dans un paquet IP
contenant son adresse IP source
Protocole ap1.0: Alice dit “Je suis Alice”
Dans un réseau,
Bob ne peut pas "voir”
Alice, alors Trudy dit
“Je suis Alice” simplement qu'elle est
Alice
Protocole ap2.0 : Alice dit “Je suis Alice” dans un paquet IP
contenant son adresse IP source
Alice’s
“Je suis Alice”
IP address
Protocole ap3.0 : Alice dit “Je suis Alice” et envoie son mot
de passe secret pour le prouver.
Ali ’
Alice’s
l ’
Alice’s
“Je suis Alice”
IP addr password
Alice’s
“Je suis Alice”
IP address
Trudy peut créer
un paquet en
usurpant
(“spoofing”)
l'adresse d'Alice
Authentification: autre tentative
de passe secret pour le prouver.
Ali ’
Alice’s
l ’
Alice’s
“Je suis Alice”
IP addr password
Alice’s
IP addr
OK
Attaque par rejeu :
Trudy enregistre le
paquet d'Alice et le
renvoie plus tard à Bob
Alice’s
IP addr
OK
Authentification : encore un autre essai
de passe secret chiffré pour le prouver.
d
l ’ encrypted
Alice’s
"Je suis Alice”
IP addr password
Alice’s
IP addr
OK
Alice’s
Alice’s
“Je suis Alice”
IP addr password
5
de passe secret chiffré pour le prouver.
d
l ’ encryppted
Alice’s
“Je suis Alice”
IP addr password
Alice’s
IP addr
L'enregistrement et le
rejeu fonctionnent
encore !
OK
But : éviter l'attaque du rejeu
Nonce: nombre (R) utilisé seulement-une-fois
ap4.0: pour prouver qu'Alice est “en live”, Bob envoie à
Alice nonce, R. Alice
doit renvoyer R,
R chiffré avec la clé secrète
“Je suis Alice”
R
KA-B(R)
Alice’s encrypted
“Je suis Alice”
IP addr password
Échecs, inconvénients ?
ap4.0 nécessite le partage d'une clé symétrique
 Peut-on authentifier en utilisant des techniques de
clé publique ?
ap5.0: utiliser nonce, crypto à clé publique
“Je
Je su
suiss Al
Alice”
ce
+
-
K A (R)
“envoie-moi ta clé publique”
+
KA
Alice est en live,
et seule Alice
connaît la clé pour
chiffer nonce,
donc ça doit être
Alice!
ap5.0 : trou de sécurité
Authentification : ap5.0
R
Attaque d'une personne au milieu : Trudy se fait
passer pour Alice (vis-à-vis de Bob) et pour Bob
(vis-à-vis d'Alice)
I am Alice
R
Bob calcule
-
KA(KA (R)) = R
ap5.0 : trou de sécurité
Attaque d'une personne au milieu : Trudy se fait
passer pour Alice (vis-à-vis de Bob) et pour Bob
(vis-à-vis d'Alice)
Difficile à détecter :
 Bob reçoit tout ce qu'Alice envoie et vice versa.
le problème est que Trudy reçoit également tous les
messages !
K (R)
A
Send me your public key
K
Send me your public key
Et sait que seule Alice
peut avoir la clé qui a
chiffré R telle que
+ K (K (R)) = R
A A
I am Alice
R
K (R)
T
K
- +
m = K (K (m))
A A
+
K (m)
A
+
A
Trudy gets
- +
m = K (K (m))
T Alice
sends T
m to
+
T
+
K (m)
T
encrypted with
Alice’s public key
Plan
3 Authentification
4 Intégrité
6
Signatures numériques
Signatures numériques
Technique cryptographique analogue aux
signatures manuscrites.
 L'émetteur (Bob) signe le document de manière

numérique et établit qu
qu'ilil est le
créateur/propriétaire du document.
Vérifiable, non falsifiable: le récepteur (Alice)
peut prouver à quelqu'un que Bob et personne
d'autre (y compris Alice) a signé ce document
Signature numérique simple pour le
message m :
 Bob signe m en chiffrant avec sa clé privée KB- ,
-
créant le message "signé" KB(m)
K B Bob’s private
Bob’s message, m
Public key
encryption
algorithm
Oh, how I have missed
you. I think of you all the
time! …(blah blah blah)
Bob
 Supposons qu'Alice reçoit le msg m et la signature
-
numérique KB(m)
 Alice vérifie que m a été signé par Bob en appliquant la clé
-
+
-
publique de Bob KB à KB(m) et vérifie que KB(KB(m) ) = m.
-
 Si KB+(KB(m) ) = m, la personne qui a signé m a forcément
utilisé la clé privée de Bob.
Alice vérifie ainsi que :
 Bob a signé m.
 Personne d'autre n'a signé m.
 Bob a signé m et pas m’.
Non-répudiation:
 Alice peut emporter m et la signature K- B(m) à un
procès et prouver que Bob a signé m.
Internet checksum : fonction cryptographique de
hachage "pauvre"
Le Internet checksum possède des propriétés de fonction de
hachage :
 Produit un message condensé de longueur fixe du message
(somme sur 16-bits)
 many-to-one
Mais avec un message avec une valeur de hachage donnée
donnée, il est
facile de trouver un autre message avec la même valeur de
hachage :
message
I O U 1
0 0 . 9
9 B O B
Bob’s message,
m, signed
(encrypted) with
his private key
Messages condensés (message digests)
Signatures numériques (suite)
+
-
K B(m)
key
Dear Alice
ASCII format
49 4F 55 39
30 30 2E 31
39 42 D2 42
ASCII format
49 4F 55 31
30 30 2E 39
39 42 D2 42
message
I O U 9
0 0 . 1
9 B O B
B2 C1 D2 AC
B2 C1 D2 AC
différents messages
Mais checksums identiques!
Le chiffrement par clé publique de
longs messages est très onéreux
"computationnellement"
large
message
m
H: Hash
Function
H(m)
Propriétés de la fonction de
But : "empreinte
empreinte digitale
digitale" de
hachage:
longueur fixe et facile à calculer
 many-to-1
 Appliquer une fonction de
 Produit des messages condensés
hachage H à m, recevoir un
de taille fixe ("empreinte digitale")
message condensé de longueur
 Étant donné un message
fixe, H(m).
condensé x, il est
computationnellement impossible
de trouver m tel que x = H(m)
Signature numérique = message digest signé
Bob envoie un message
signé numériquement :
large
message
m
H: Hash
function
Bob s
Bob’s
private
key
+
-
KB
Alice vérifie la signature et
l'intégrité du message signé
sumériquement :
encrypted
msg digest
H(m)
digital
signature
(encrypt)
encrypted
msg digest
KB(H(m))
KB(H(m))
large
message
Bob’s
m
H: Hash
function
public
key
+
KB
digital
signature
(decrypt)
H(m)
H(m)
equal
?
7
Algorithmes de fonctions de hachage
 Fonction de hachage MD5 largement utilisée (RFC

1321)
 Calcule un message digest de 128 bits en 4
étapes.
 Il est difficile,
difficile à partir d'une
d une chaîne aléatoire de
128 bits, de construire un msg m dont l hash
MD5 est égal à x.
SHA-1 est également utilisé.
 Standard américain [NIST, FIPS PUB 180-1]
 Message condensé de 160 bits
Intermédiaires de confiance
publique de Bob (à partir
d'un site Web, d'un e-mail,
d'une disquette),
q
), comment
sait-elle que c'est la clé
publique de Bob, et pas
celle de Trudy ?
Solution :
 Centre de distribution de clé de
confiance (KDC) agissant
comme un intermédiaire entre
les entités
3 Authentification
4 Intégrité
Key Distribution Center (KDC)
Problème des clés
Problème des clés
symétriques
publiques :
 Comment 2 entités établissent-  Quand Alice obtient la clé
elles une clé secrète partagée
à travers un réseau ?
Plan
 Alice et Bob doivent partager une clé symétrique.
 KDC : le serveur partage une clé secrète différente

avec chaque utilisateur enregistré (nombreux
utilisateurs)
Alice et Bob possèdent leur propre clé symétrique
KA-KDC KB-KDC , pour communiquer avec le KDC.
KDC
Solution :
 Autorité de certification de
KA-KDC KP-KDC
KX-KDC
KB-KDC
KP-KDC
KY-KDC
confiance (CA)
KB-KDC
KA-KDC
Key Distribution Center (KDC)
Autorités de certification
Q : Comment le KDC permet-il à Bob et Alice de
déterminer une clé secrète symétrique partagée pour
communiquer l'un avec l'autre ?
KDC
generates
R1
KA-KDC(A,B)
Alice
knows
R1
KA-KDC(R1, KB-KDC(A,R1) )
KB-KDC(A,R1)
KZ-KDC
Bob knows to
use R1 to
communicate
with Alice
Alice et Bob communiquent : utilisation de R1
comme clé de session pour le chiffrement
symétrique partagé
 Certification authority (CA) : relie une clé publique
à une entité particulière E.
 E (personne, routeur) enregistre sa clé publique
auprès du CA.



E fournit une “preuve d'identité” au CA
Le CA crée un lien certifié entre e et sa clé publique
Le certificat contenant la clé publique de E est signé
numériquement par le CA – le CA dit “ceci est la clé
publique de E”
Bob’s
public
key
Bob’s
identifying
information
+
KB
digital
signature
(encrypt)
CA
private
key
K CA
+
KB
certificate for
Bob’s public key,
signed by CA
8
Un certificat contient :
Autorités de certification
 Quand Alice veut la clé publique de Bob :


Elle obtient le certificat de Bob (par Bob ou
autre).
Elle applique la clé publique du CA au
certificat de Bob et obtient la clé publique de
Bob.
+
KB
digital
signature
(decrypt)
CA
public
key
 Un numéro de série (unique pour chaque émetteur)
 info sur le propriétaire du certificat, y compris
l'algorithme et la valeur de la clé elle-même
 info sur

Bob’s
public
+
key
KB

+
K CA
Plan
3 Authentification
4 Intégrité
Firewalls : pourquoi ?
Évite les attaques par déni de service :
 SYN flooding : l'attaquant établit de nombreuses
connexions TCP "bidon", plus de ressources pour les
vraies connexions.
Évite la modification / l'accès illégal aux données internes.
 Ex : ll'attaquant
attaquant remplace la page du CIA par autre chose
Autorise uniquement les accès autorisés à l'intérieur du
réseau (ensembles d'utilisateurs / hôtes authentifiés)
2 types de firewalls :
 Niveau applicatif
 Filtrage de paquets
l'émetteur
du certificat
Dates de
validité
Signature
numérique
de
l'émetteur
Firewalls
firewall
Isole le réseau interne d'une organisation de
l'Internet, en permettant à certains paquets de
passer et en en bloquant d'autres.
Internet
public
réseau
administré
firewall
Filtrage de paquets
ce paquet entrant
doit-il être admis ?
Ce paquet sortant
peut-il sortir ?
 Réseau interne connecté à l'Internet via un routeur
firewall
 Le routeur filtre paquet par paquet, décision de faire
transiter ou de supprimer le paquet selon :




L'adresse IP source, l'adresse IP destination
Les numéros de ports TCP/UDP source et destination
Le type de message ICMP
Les bits TCP SYN et ACK
9
Filtrage de paquets
Gateway aplicative
 Exemple 1 : blocage des datagrammes IP

entrants et sortants avec le champ protocole =
17 et avec le port source ou destination = 23.
 Tous les flux UDP entrants et sortants, ainsi
que les connexions telnet, sont bloqués.
Exemple 2 : Blocage des segments TCP
inbound avec ACK=0.
 Empêche les clients extérieurs de faire des
connexions TCP avec des clients internes,
mais permet aux clients internes de se
connecter à l'extérieur.
Limites des firewalls et des gateways
 Filtre les paquets en fonction
des données applicatives
aussi bien qu'en fonction des
champs IP/TCP/UDP.
 Exemple : permettre à des
utilisateurs internes
autorisés d'effectuer un
telnet à l'extérieur.
host-to-gateway
telnet session
application
gateway
gateway-to-remote
host telnet session
router and filter
1. Nécessite que tous les utilisateurs de telnet passent par
la gateway.
2. Pour des utilisateurs autorisés, la gateway établit une
connexion telnet à l'hôte de destination. La gateway fait
transiter les données entre les 2 connexions.
3. Le filtre du routeur bloque toutes les connexions telnet ne
provenant pas de la gateway.
Plan
 IP spoofing : le routeur ne
peut pas savoir si les
données proviennent
vraiment d'une source
autorisée
 Si plusieurs applications
ont besoin d'un traitement
spécial, chacune a sa
propre gateway
applicative.
 Le logiciel client doit savoir
comment contacter la
gateway.

 Les filtres utilisent souvent
une politique tout ou rien
pour UDP.
 Compromis : degré de
communication avec le
monde extérieur, niveau
d sécurité
de
é ité
 De nombreux sites
hautement protégés
souffrent toujours
d'attaques.
Ex : il doit configurer
l'adresse IP du proxy dans
le browser Web
Menaces de sécurité sur Internet
Mapping :




Avant d'attaquer : trouver quels services sont
implémentés sur le réseau
Utiliser ping pour déterminer quels hôtes ont
des adresses sur le réseau
Scan des ports : essayer d'établir des
connexions TCP avec chaque port (regarder
ce qui se passe)
nmap (http://www.insecure.org/nmap/) mapper
3 Authentification
4 Intégrité
Mapping : parades


Enregistrer le trafic pénétrant dans le réseau
Chercher une activité suspecte (adresses IP,
ports scannés les uns après les autres)
 “network exploration and security auditing”
Parades ?
10
Reniflement de paquets (packet sniffing) :




Packet sniffing : parades
Médium à diffusion
Une machine proche lit tous les paquets qui
passent
peut lire toutes les données en clair (p
p
(par ex les
mots de passe)
Ex : C sniffe les paquets de B


Tous les hôtes d'une organisation utilisent des
logiciels vérifiant périodiquement si l'interface
de l'hôte est en mode promiscuous.
Un hôte p
par segment
g
du médium à diffusion
(switched Ethernet at hub)
C
A
C
A
src:B dest:A
src:B dest:A
payload
IP Spoofing (usurpation d'adresse IP) :


Peut générer des paquets IP directement à partir d'une
application, en mettant n'importe quelle valeur dans le
champ d'adresse IP source
Le récepteur ne peut pas dire si la source est spoofée
Ex : C se fait passer pour B
IP Spoofing : ingress filtering


C
A
B

C
A
SYN
B


Filtrer le flot de paquets (ex : SYN) avant qu'ils
n'atteignent l'hôte : on jette les bons comme
les mauvais
Remonter à la source des flots (probablement
(p
une machine innocente, compromise)
C
A
SYN
SYN
SYN
SYN
SYN
SYN
SYN
B
Parade ?
payload
Deni de service (DOS) : parades
Flot de paquets malicieux générés pour inonder un
récepteur
DOS distribué (DDOS): plusieurs sources
coordonnées pour inonder un récepteur
Ex : C et un hôte distant font une SYN-attack vers A
SYN
src:B dest:A
Déni de Service (DOS) :

C
payload
Parades ?

Les routeurs ne doivent pas transmettre des
paquets sortants avec des adresses source
invalides (ex : adresse source du datagramme pas
dans le réseau du routeur)
Bien, mais ce filtrage ingress ne peut pas être
effectué dans tous les réseaux
A
src:B dest:A
B
B
Parades ?

payload
SYN
B
SYN
SYN
SYN
SYN
11
E-mail sécurisé
Plan
KS
KS
.
KS(m )
• Alice veut fournir une authentification de
l'émetteur et l'intégrité du message.
.
KS( )
-
Internet
+
+
KB(KS )
KB(KS )
+
K
génère une clé privée symétrique aléatoire KS.
chiffre le message avec KS (pour l'efficacité)
chiffre aussi KS avec la clé publique de Bob.
envoie à la fois KS(m) et KB(KS) à Bob.




KS(m )
KB( )
KS
-
KA
.
m
H(( )
-
.
KA( )
.
 utilise sa clé privée pour déchiffrer et retrouver KS
 utilise KS pour déchiffrer KS(m) pour retrouver m
-
-
KA(H(m))
KA(H(m))
+
KB( )
K
B
B
+
-
m
Bob :
Internet
m
• Alice veut fournir le secret, l'authentification de
l'émetteur et l'intégrité du message.
 Procédé de chiffrement d'email
m
.
H( )
-
.
KA( )
-
KA(H(m))
+
symétrique, la crypto à clé
publique, une fonction de
hachage et la signature
numérique.
éi
.
KS( )
+
m
KS
+
.
KB( )
+
Internet, standard de-facto.
 Utilise la crypto à clé
KS
Internet
+
KB(KS )
KB
Alice utilise 3 clés : sa clé privée, la clé publique de
bob et la nouvelle clé symétrique créée
+
.
KA( )
H(m )
compare
.
H( )
H(m )
• Alice signe numériquement le message.
• envoie à la fois le message (en clair) et la signature
numérique.
Pretty good privacy (PGP)
K
KA
m
E-mail sécurisé (suite)
A
-
KB
E-mail sécurisé (suite)
+
+
.
KB( )
Alice :
KS
.
KB(KS )
m
KS
-
+
+
.
KS( )
-
Internet
KB(KS )
+
Alice veut envoyer un email sécurisé m à Bob.
KS( )
KS
KB(.)
+
KB
E-mail sécurisé
m
KS( )
KS(m )
KS(m )
.
m
+
8.1. Email sécurisé
8.2. Sockets sécurisées
8.3. IPsec
8.4. 802.11 WEP

Alice veut envoyer un email sécurisé m à Bob.

1 Qu'est-ce que la sécurité des réseaux ?
3 Authentification
4 Intégrité
6 Contrôle d'accès : firewalls
7 attaques et parades
 Garantit le secret,
l'authentification de l'émetteur,
l'intégrité.
Message signé par PGP :
---BEGIN PGP SIGNED MESSAGE--Hash: SHA1
Bob:My husband is out of town
tonight.Passionately yours,
Alice
---BEGIN PGP SIGNATURE--Version: PGP 5.0
Charset: noconv
yhHJRHhGJGhgg/12EpJ+lo8gE4vB3m
qJhFEvZP9t6n7G6m5Gw2
---END PGP SIGNATURE---
 L'inventeur, Phil Zimmerman, a
été la cible de 3 ans d'enquête
fédérale
12
SSL (suite)
Secure sockets layer (SSL)
 Sécurité de niveau
transport pour toute
application basée sur TCP
utilisant des services SSL.
 Utilisé entre des browsers
Web des serveurs pour le
Web,
commerce électronique
(shttp).
 Services de sécurité :



 Authentification du serveur :
Authentification du
serveur
Chiffrement des données
authentication du client
(optionnel)




Le browser SSL-capable
contient les clés publiques
pour les CAs de confiance.
Le browser demande le
certificat du serveur, fourni
par un CA de confiance.
Le browser utilise la clé
publique du CA pour
extraire la clé publique du
serveur du certificat.
Vérifier le menu de sécurité
de votre browser pour voir
ses CAs de confiance.
IPsec : Sécurité de niveau réseau
 Secret de niveau réseau Networklayer secrecy:
 L'hôte émetteur chiffre les
données dans le datagramme
IP
 Segments TCP et UDP;
messages ICMP et SNMP.
 Authentification de niveau réseau
 L'hôte de destination peut
authentifier l'adresse IP source
 2 protocoles de principe :
 Protocole d'authentication d'entête (authentication header AH)
 Protocole encapsulation
security payload (ESP)
 Pour AH et ESP, handshake
de la source et de la
destination :
 Crée un canal logique de
niveau réseau, appelé
association de sécurité (SA)
 Chaque SA est unidirectionnel.
 Déterminé de manière unique
par :
 Un protocole de sécurité
(AH or ESP)
 Adresse IP source
 Identifiant de connexion sur
32 bits
Protocole ESP

Toutes les données envoyées
dans la socket TCP (par le
client ou par le serveur) sont
chiffrées avec la clé de
session.


Transport Layer
Security (TLS) de
l'IETF.
SSL peut être utilisé
pour des applications
non-Web, ex : IMAP.
L'authentification du
client peut être
effectuée avec des
certificats de client.
Protocole Authentication Header (AH)
 Fournit l'authentification de L'en-tête AH inclut
la source, l'intégrité des
 L'identifiant de connexion
données mais pas de
 Données d'authentification :
confidentialité
message digest signé par la
source et calculé à partir du
l'en-tête IP et le champ de
datagramme IP original.
d
données.
é
 Champ next header : spécifie le
 Champ protocole : 51
type des données (ex : TCP,
UDP, ICMP)
 Les routeurs intermédiaires
traitent les datagrammes
comme d'habitude
 En-tête AH inséré entre
IP header
AH header
data (e.g., TCP, UDP segment)
 Nombreux réseaux IEEE 802.11 disponibles
 Le champ
l'authentification de l'hôte,
l'intégrité des données.
Les données et l'ESP
trailer sont chiffrés.
Le champ next header est
dans l'ESP trailer.

d'authentification
d'ESP est similaire au
champ
d'authentification d'AH
Protocol = 50
authenticated
encrypted
IP header

 SSL : base du
Sécurité dans IEEE 802.11
 Fournit le secret,

Session chiffrée avec SSL :
 Le browser génère une clé de
session symétrique, la chiffre
avec la clé publique du serveur
et envoie la clé chiffrée au
serveur.
 En utilisant la clé privée, le
serveur décriffre la clé de
session.
 Le browser et le serveur
connaissent la clé de session
ESP
ESP
TCP/UDP segment
header
trailer
ESP
authent.
La plupart n'utilisent pas de chiffrement ni
d'authentification
 Facile de faire du packet-sniffing et autres
attaques !
Wired Equivalent Privacy (WEP): authentification
comme dans le protocole ap4.0
 L'hôte demande l'authentification au point d'accès
 Le point d'accès envoir un nonce de 128 bits
 L'hôte chiffre le nonce en utilisant une clé
symétrique partagée
 Le point d'accès déchiffre le nonce et authentifie
l'hôte


13
Sécurité dans IEEE 802.11
 Wired Equivalent Privacy (WEP) : chiffrement des
données
 L'hôte et le point d'accès partagent une clé
symétrique de 40 bits (semi-permanente)
 L
L'hôte
hôte ouvre un vecteur d'initialisation
d initialisation (IV) de 24
bits pour créer une clé de 64 bits
 Le clé de 64 bits est utilisée pour générer un flux
de clés, kiIV
IV
 ki est utilisée pour chiffrer le i-ème octet, di :
ci = di XOR kiIV
 IV et les octets chiffrés, ci sont envoyés dans la
trame
Casser le chiffrement WEP dans 802.11
Trou de sécurité :
 IV sur 24 bits, un IV par trame, -> l'IV peut être réutilisé
 IV transmis en clair -> la réutilisation d'IV peut être détectée
 Attaque :





Trudy
T
d contraint
t i t Alice
Ali à chiffrer
hiff d
du ttexte
t connu d1 d2 d3 d4 …
Trudy voit : ci = di XOR kiIV
Trudy connait ci di, donc peut calculer kiIV
Trudy connait la séquence de chiffrement de clés k1IV k2IV k3IV
…
La prochaine fois que IV sera utilisé, Trudy pourra déchiffrer !
802.11 : chiffrement WEP
IV
(per frame)
KS: 40-bit
secret
symmetric
plaintext
frame data
plus CRC
key sequence generator
( for given KS, IV)
k1IV k2IV k3IV … kNIV kN+1IV… kN+1IV
d1
d2
d3 …
dN
CRC1 … CRC4
c1
c2
c3 …
cN
cN+1 … cN+4
802.11
IV
header
WEP-encrypted data
plus CRC
Figure 7.8-new1:
802.11encryption
WEP protocol
Sender-side
WEP
Sécurité des réseaux (résumé)
Techniques de base…...




cryptographie (symétrique et publique)
authentification
Intégrité des messages
Distribution des clés
…. utilisées dans de nombreux scénarios de
sécurité différents




Email sécurisé
transport sécurisé (SSL)
IP sec
802.11 WEP
Ressources
 Livre
 Computer Networking : A Top Down Approach
Featuring the Internet,
2nd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July 2002.
14
Plan
Multicast
 Introduction
 Le multicast au niveau réseau
 Le multicast au niveau transport
 Perspectives
P
ti
 IP multicast et le monde réel…
Plan
Qu’est-ce que le multicast ?
 Introduction
 moyen efficace de communication 1-vers-N
 multicast vs. unicast et broadcast
Définition
Notion de groupe
 Problématique
Le multicast au niveau réseau
Le multicast au niveau transport
Perspectives
IP Multicast et le monde réel…






Qu'est-ce que le multicast ?
 Communication 1 vers N
 Technologie conservant la bande passante

qui réduit le trafic en délivrant simultanément
un unique flot d'information à plusieurs
récepteurs
Exemples de Multicast

La couche matérielle du réseau supporte
efficacement le transport multicast
 Exemple : Ethernet permet à un paquet d'être reçu par
de nombreux hôtes

Plusieurs protocoles et modèles de service
différents



unicast : une seule source vers une seule destination
multicast : une seule source vers un sous-ensemble de
destinataires
broadcast : une seule source vers toutes les destinations
unicast
(1-vers-1)
multicast
(1-vers-N)
broadcast
(1-vers-tous)
Unicast
 Problème

L'envoi des mêmes
données vers plusieurs
récepteurs en unicast
n'est
n
est pas efficace
émetteur
R
 Exemple

Les sites Web en
vogue deviennent de
sérieux goulots
d'étranglement
 Exemples : IETF multicast IP, ATM Multipoint
1
Des applications pour le multicast
Multicast
 Distribution 1 vers
émetteur
temps réel
interactif
fiabilité
plusieurs efficace
100%
distribution
multimédia
distribution
de documents
R
200 ms
 conférence
 délai de l’ordre
de 100 ms
 tolérance d’un
certain taux de
pertes

2s
flux continus,
temps réel, non
interactifs,
unidirectionnels



20 s temps de réponse
distribution de
logiciels
fiabilité de 100%
peu de
contraintes
temporelles
Pourquoi le multicast ? (1/3)
 distribution utilisant TCP/IP

distribution utilisant un multicast
S
S
R1
D2

R1
R2
D1
R4
R3
D5
D4


D2
D3
résultats

R2
D1

plusieurs copies du même paquet
plusieurs buffers
plusieurs connexions
R4
R3
D5
D4
D3
résultats



une seule copie de chaque paquet
un seul buffer
une seule connexion multicast
Notion de groupe de multicast
 utilise la BP de façon efficace
 prévient la congestion du réseau
 minimise la charge des serveurs
 fournit l’information à davantage
g d’utilisateurs
 Comment identifier les récepteurs d’un paquet Mcast ?


simultanément
touche un nombre quelconque de personnes en
une seule fois
etc.


en unicast : une adresse IP de destination
ici, toutes les adresses de destination ???
 Une abstraction : le groupe de multicast


associe un ensemble d’émetteurs et de récepteurs
p
existe indépendamment des émetteurs et récepteurs
chaque récepteur
reçoit les paquets de
chaque émetteur
émetteurs
groupe de
multicast
récepteurs
2
Introduction au multicast IP
IP Multicast
 Distribution 1 vers plusieurs efficace
 Service


Distribution des données avec un arbre
Les paquets ne traversent les liens du réseau qu'une seule fois
 Adressage indépendant de la localisation

Une adresse IP par groupe multicast
 Modèle de service orienté récepteur




Les applications peuvent s'abonner et quitter les groupes
multicast
les émetteurs ne savent pas qui écoute
Similaire au modèle de la télévision
Diffère du réseau téléphonique, de l'ATM
Tous les émetteurs émettent en même temps
vers le même groupe
 Les récepteurs s'abonnent à n'importe quel
g p
groupe
 Les routeurs trouvent les récepteurs

 Livraison non fiable
 Adresses IP réservées
224.0.0.0 à 239.255.255.255 réservées pour le
multicast
 Adresses statiques pour les services courants (ex
protocole d'annonce de session)

Adresses de multicast IP (1/2)
Adresses de multicast IP (2/2)
 un groupe de multicast : une adresse de classe D
 adressage du groupe
A 0 réseau
B 10
réseau
C 110
D 1110
station

D
...
224.0.0.0 : non utilisée
224.0.0.1 : représente l’ens. des stations du sous-réseau
considéré
il n’y a pas d’adresse pour l’ens. des machines de l’Internet
 des questions...




quand et comment un groupe naît-il et prend-il fin ?
quand et comment l’@groupe est-elle choisie ?
comment de nouvelles stations se joignent-elles à un groupe ?
y-a-t-il des conditions pour l’appartenance à un groupe ?
comment les routeurs interopèrent-ils pour délivrer les paquets ?
 des choix...


données à Mcaster
D
11100000 00000000 00000000 00000000
Multicast : les problèmes

D
adresse
d
multicast
l i
..
.

224.1.2.3
adresse de
destination
à 239.255.255.255 11101111 11111111 11111111 11111111

@ IP source
station
réseau
de 224.0.0.0
en-tête IP
S
S
station
un récepteur doit pouvoir joindre ou quitter un groupe en cours de
transmission
un récepteur doit pouvoir joindre ou quitter un groupe sans le
signaler explicitement aux émetteurs



D
D
les récepteurs s’abonnent
à l’adresse de groupe 224.1.2.3
indirection d’adresse
chaque hôte a sa propre @IP, indépendante de l’@groupe
dissociation des problèmes




découvrir l’ensemble des groupes Mcast courants
exprimer le souhait de recevoir les paquets d’un groupe
découvrir l’ens. des récepteurs d’un groupe
délivrer les données à chaque membre du groupe
Plan
 Introduction
 Perspectives
 IP Multicast et le monde réel…
 des constats....

les hôtes récepteurs sont souvent connectés à des réseaux locaux...
3
Plan
 Introduction
 Le




Composants de l'architecture
IP Multicast
Le p
protocole IGMP
Le multicast sur un LAN
Algorithmes et protocoles de routage multicast
Le MBone
 Perspectives
Le modèle de service du multicast (1/5)
Protocole hôte-routeur
(IGMP)
routeurs
Protocoles de routage multicast
(plusieurs)
 issu des travaux de S. Deering
 caractéristiques de la transmission


hôtes
Modèle de service
modèle de service



multicast IP : transmission d’un paquet IP à un groupe d’hôtes
identifié par une seule adresse de destination
transmission best effort

l’émetteur ne contrôle pas qui joint le groupe
il n’y a pas de contrôle sur qui envoie au groupe
les paquets issus de  sources peuvent être reçus
entrelacés
2 groupes différents peuvent choisir la même @
 caractéristiques du groupe






appartenance dynamique
pas de restriction quant à la localisation et au # de membres
un hôte peut être simultanément membre de plusieurs groupes
un hôte n’a pas besoin de faire partie d’un groupe pour être source
groupe permanent/transitoire
l’opération de Join est receiver-driven
 rôle des routeurs Mcast locaux



 la RFC 1112 spécifie les extensions à apporter à un
hôte IP pour supporter le Mcast

3 niveaux de conformité
 0 : l’hôte ne supporte pas le Mcast
 1 : l’hôte peut émettre à destination d’un groupe
 2 : l’hôte supporte le Mcast en émission et réception

modèle d’implémentation IP d’un hôte
modules de protocoles de
niveau sup.
interface de service IP
module IP
ICMP IGMP
interface de service
LAN
co-résidents ou séparés des routeurs classiques
un routeur local qui reçoit un paquet Mcast d’un de ses
hôtes, avec un TTL>1, le fait suivre vers tous les sousréseaux connectant des membres récepteurs
sur les sous-réseaux destinataires, le routeur local termine
la transmission en Mcastant le paquet en local

les extensions pour l’envoi Mcast
 interface de service IP

utilisation de SendIP

@dest = @ de groupe
le niveau supérieur doit pouvoir spécifier un TTL

 module
d l IP
 si IP-dest est sur le même
ou si IP-dest est une @ de
alors envoyer le paquet en
sinon envoyer le paquet en
 interface de service LAN
 module LAN

module LAN
traduction d’@
(Ethernet)
(ARP)
réseau local
groupe
local à IP-dest
local à GatewayTo (IP-dest)
mécanisme de traduction des @IP Mcast en @MAC Mcast
4

les extensions pour la réception Mcast
 interface de service IP



utilisation de ReceiveIP
ajout de JoinHostGroup (group-address, interface)
ajout de LeaveHostGroup (group-address, interface)
 module IP


maintien
i ti d
de lla liliste
t d
des groupes d
dontt l’hôt
l’hôte estt membre
b pour chacune
h
des interfaces (mise à jour avec les Join et Leave)
intégration de IGMP et adhésion à 224.0.0.1
 interface de service LAN


ajout de JoinLocalGroup (group-address)
ajout de LeaveLocalGroup (group-address)
 module LAN

mécanismes de filtrage par la carte souhaités
Modèle de service d'IP Multicast
(RFC-1112)
 Chaque groupe est identifié par une adresse
IP unique
 Les groupes peuvent être de n'importe
quelle taille
 Les membres d'un groupes peuvent être
localisés n'importe où dans l'Internet
 Les membres d'un groupe peuvent le
rejoindre ou le quitter à leur gré
 Les émetteurs n'ont pas besoin d'être
membres
Modèle de service
Plan
 Appartenance à un groupe non connue
 Introduction
explicitement

 Le
 Analogie :

Le modèle de service
Chaque adresse multicast est comme une
fréquence radio, sur laquelle tout le monde peut
émettre et que chacun peut écouter.



protocole IGMP
p
Le MBone
 Perspectives
IP Multicast
Modèle de service
hôtes
Couches protocolaires concernées
dans un hôte
Upper-Layer Protocol Modules
(IGMP)
IP Service Interface
routeurs
ICMP
IGMP
IP Module
(plusieurs)
Link-Layer Service Interface
Link-Layer Modules
(e.g., Ethernet)
IP to link-layer address
mapping (e.g., ARP)
5
IGMP : Qu’est-ce que c’est ?
 comment un routeur détermine-t-il si son LAN possède
des récepteurs pour un groupe donné ?
 Internet Group Management Protocol

en-tête IP
permet à un hôte d’indiquer à son routeur local qu’il souhaite
joindre un groupe
estt utilisé
tili é sur les
l LAN à diffusion
diff i
...
H
...
R
H
IGMP
H
données
H
R
report (225.5.5.5)
query
(quelqu’un intéressé par un groupe?)
H
H
H
report (224.9.9.9)
IGMP
IGMP Version 2 (1/2)
 risque de congestion
étalement des réponses basé sur des temporisateurs
 envoi de la requête
 RFC 2236 (Nov.97)
 un récepteur informe explicitement son routeur
lorsqu’il quitte un groupe
query

report
H
224.9.9.9
@ destination
H
H
@ IP source
H
IGMP H
R
S2
routage multicast
grande distance
H
routage multicast
grande distance
R
S1
H
R
IGMP
H

 RFC 1112 (Aug.89)
 échange de messages query/report
...

3 types de messages
envoyé par
type de message
membership_query
routeur
général
spécifique routeur
membership_report hôte
hôte
leave_group
H
 armement du tempo
 armement du tempo
 réception de la réponse,  envoi de la réponse
désarmement du tempo

réduction du trafic sur le LAN si aucun membre

délai éventuel (qq s.) avant de recevoir les données
Exemple IGMP (1)

But
s’enquérir des groupes auxquels sont abonnés les hôtes
demander si un groupe donné a des membres sur le LAN
indiquer que l’hôte souhaite joindre ou a joint un groupe
indiquer que l’hôte quitte un groupe donné
étalement des réponses avec 0  tempo MaxRespTime
Exemple IGMP (2)
Membership
Leave Report
Group
1
1
3
3
Network 1
Network 1
2
Network 2
Router
Network 2
Router
2
4
4
 L'hôte 3 rejoint la conférence
 L'hôte 1 commence à émettre des paquets


Pas de message IGMP envoyé
Les paquets restent sur le réseau 1
 Le routeur envoie périodiquement un IGMP
Membership Query

Il envoie un message IGMP Membership Report
 Le routeur commence à faire transiter les paquets
sur le réseau 2
 L'hôte 3 quitte la conférence

Il envoie un message IGMP Leave Group
6
IGMP Version 3
en-tête IP
S1
S2
@ IP source
@ destination
H
R
H
leave_group (225.5.5.5)

données
H
routage multicast
grande distance
H
224.9.9.9
H
 un récepteur peut sélectionner les sources qu’il
souhaite (ne pas) entendre
S1
H
H
report (224.9.9.9)
MaxRespTime
@ IP source
H
R
H
report
(225.5.5.5,
réduction de la latence du Leave
224.9.9.9
H
query
H
H
report
(224.9.9.9,
source=S2)
sourceS3)
Internet Group Management Protocol (IGMP)
Plan
 Protocole pour gérer l'appartenance à un
 Introduction
groupe
Les hôtes IP rapportent leur appartenance à un
groupe multicast aux routeurs voisins
 Messages
g dans IGMPv2 ((RFC 2236))

 Membership Query (provenant des routeurs)
 Membership Report (provenant des hôtes)
 Leave Group (provenant des hôtes)
 Protocole annonce-écoute avec suppression


Le protocole IGMP
 Le


multicast sur un LAN
Le MBone
 Protocole Soft State
 Perspectives
Multicast sur un LAN (1/3)

Les hôtes ne répondent que si aucun hôte n'a
répondu




Ethernet repose sur un support à diffusion
chaque station a une carte réseau avec une @
matérielle spécifique
il existe
i
une adresse
d
d
de diff
diffusion
i
(FF.FF.FF.FF.FF.FF)
 que faire si l’on souhaite joindre uniquement
un sous-ensemble de stations ?


ex : H1 souhaite envoyer un paquet Mcast à H2 et
H4 qui sont sur le même réseau que lui
deux possibilités...
le multicast de réseau utilise le broadcast de liaison
@src
 l’existant (cas d’Ethernet)
@dst
@ de H1 FF.FF.FF.FF.FF.FF
H1
IP
Ethernet

données
H
routage multicast
grande distance
Checksum
Multicast Group Address

en-tête IP
S3
@ destination
H
format du message
type
S2
query
H2
IP
Ethernet
paquet IP multicast
H3
IP
Ethernet
H4
IP
...
Ethernet
le multicast de réseau utilise le multicast de liaison
@ de H1 @ MAC multicast
H1
IP
Ethernet
H2
IP
Ethernet
paquet IP multicast
H3
IP
Ethernet
H4
IP
...
Ethernet
7
Plan
 traduction des adresses IP multicast en @ Ethernet

format des adresses multicast Ethernet
..
.
de 01:00:5e:00:00:00
0000 0001 0000 0000
0101 1110
0000 0000 0000 0000
0000 0000
0101 1110
0111 1111 1111 1111
1111 1111

mécanisme de traduction
1110 xxxx x
23 derniers bits
0000 0001 0000 0000

Le protocole IGMP


Le MBone

à 01:00:5e:7f:ff:ff
0000 0001 0000 0000
 Introduction
0101 1110 0
 on sait Mcaster un paquet IP sur un LAN à diffusion !
IP Multicast

 Perspectives
Qu’appelle-t-on IP multicast ?
 mécanisme utilisé dans l’Internet pour
Modèle de service
hôtes
(IGMP)
routeurs
construire un arbre de routage multicast
efficace et sans boucles
 IGMP + protocole de routage Mcast
(plusieurs)
Routage multicast
Premières techniques de routage
 Objectif : calculer un arbre de liens connectant tous
 Inondation et élagage
les routeurs ayant des hôtes appartenant au groupe
 Le modèle de service multicast rend la localisation
des récepteurs difficile


anonymat
Rejoindre/quitter dynamiquement




 Protocoles de multicast à état des liens

Diffusion des annonces d'appartenance à un groupe de chaque
récepteur à tout le réseau

Calcul des arbres à la demande
État "unwanted" là où il n'y a pas d'émetteur
Exemple : MOSPF
 Options jusqu'alors (pas très efficaces)


Inonder tout le réseau avec les paquets de données, ou
Indiquer aux routeurs tous les groupes et récepteurs
possibles pour qu'ils puissent créer des routes (arbres)
Diffusion des paquets initiaux de chaque source vers tout le
réseau
Les non-membres élaguent
État "unwanted" là où il n'y a pas de récepteur
Exemples : RPM, DVMRP, PIM-DM
 Les routeurs annoncent les groupes pour lesquels ils ont des
récepteurs dans le réseau tout entier


8
Shared (group) vs Source-based Trees
Arbres basés à la source
 Source-based trees
Arbre de plus court chemin séparé pour chaque émetteur




Chaque source est la racine
Approche à vecteurs de distances (RPM, DVMRP, PIM-DM)
Approche à état des liens (MOSPF)
 Shared
Sh d ((group)) ttrees
Arbre unique partagé par tous les membres
Les données transitent sur le même arbre quel que soit l'émetteur





Arbre de coût minimum (MCT)
Arbre contraint
Approche centrée (CBT, PIM-SM)

S1
S2
la racine est le coeur de l’arbre, ou point de RDV
 Spécifier un "lieu de rencontre" où les sources envoient les paquets initiaux
et les récepteurs s'abonnent ; exige un mapping entre l'adresse du groupe
multicast et le point de rendez-vous
Un arbre partagé
Shared v.s. Source-Based trees
 Arbres basés à la source



Arbres de plus court chemin – délai faible, meilleure
distribution de la charge
Plus d'états dans les routeurs (état par source)
Efficace pour du multicast dans un espace à haute densité
RP
 Arbre partagé
S1

S2


Délai plus élevé, concentration du trafic
État par groupe dans les routeurs
Efficace pour du multicast dans un espace peu peuplé
Les algorithmes SPT (1/2)
 Approche inondation / élagage
 but : calculer un arbre

Au départ

 RPF (Reverse Path Forwarding)
RPB (Reverse Path Broadcasting)

TB (Truncated
(T
t dB
Broadcasting)
d
ti )
 RPM (Reverse Path Multicasting)
DVMRP
PIM-DM

ayant la source S pour racine
couvrant tous les récepteurs Di du groupe
tel que la distance entre S et Di soit minimum

 Approche à état des liens

MOSPF
 algorithmes de base


Bellmann-Ford : à vecteurs de distance
Dijkstra : à états des liens
un arbre par émetteur
9
Les algorithmes SPT (2/2)
D1
R2
RPF (1/2)
S
S
R1
R1
R3
D2
R5
D3
R4
R6
D4
R7
R9
R10
D6
R11
D7
D1
R2
 Reverse Path Forwarding (Source-based Routing)
 l’une des premières techniques utilisées
 but : construire un arbre ayant S comme racine et
R3
D2
R5
D3
R4
R6
D4
R7
R9
R10
D6
R11
D7
minimisant dist(S, Di)
 principe : utiliser l’inondation (flooding) avec

R8
D5
R8
un exemple de topologie
D5
mécanisme simple


l’arbre obtenu avec un algorithme
à vecteurs de distance
Exemple de Reverse Path Forwarding
si un paquet est reçu par l’if utilisée par le routeur pour joindre S
alors le paquet est retransmis sur les autres if
sinon le paquet est rejeté

les informations utilisées sont celles du routage unicast
Ri n’a pas à connaître les arbres recouvrants
pas de mécanisme particulier pour arrêter l’inondation
RPF (2/2)
H1
1. Le router R1 vérifie : le paquet
est-il arrivé sur l'interface avec le
plus court chemin vers l'émetteur
? Oui, donc il accepte le paquet,
le duplique et le renvoie sur
toutes les autres interfaces sauf
l'interface qui est le plus court
chemin vers l'émetteur (c'est-àdire l'interface sur laquelle le
paquet est arrivé).
i é)
Sender
2. Le router R2 accepte les
paquets envoyés depuis le
Routeur R1 parce qu'il est le
plus court chemin vers
l'émetteur. Le paquet est
envoyé sur toutes les
interfaces.
R1
H4
F
H5
H10
H16
R3
Drop
R5
R6
H17
R12
F
H1
H4
H5
H6
H7
H8
F
F H12
R9
F H14
H13
F
H15
F
F
R11
F
R10
F
F
F
R2
H24 H25 H26
H17
F
R13
F
H18 H19 H20
F
R6
F
F
R8
F
H3
F
F
F
R12
H2
F
R7
F
H16
F
R3
F
F
H10
H11
R1
F
H9
fournies par IGMP pour déterminer s’il
s il faut ou
non Mcaster un paquet sur un LAN feuille

F
R5
H21 H22 H23
 idée : utiliser les informations d’appartenance
forme d’élagage (pruning) des feuilles
pas de réduction de trafic au cœur du réseau
F
F
R4
Truncated Broadcasting (2/2)
 but : réduire le trafic sur les LAN feuilles

F
H2
H3
F
F
R6
R8
H18 H19 H20
Truncated Broadcasting (1/2)
F
F
F
F
F
R13
F
R7
F
F
R7
F
F
F
R3
F
F
H11
R2
R1
R2
H9
Drop
3. Le routeur R2 jette les
paquets qui proviennent
du Routeur R3 parce
qu'il n'est pas le plus
court chemin vers
l'émetteur. Évite les
R4
cycles.
F
F
H6
R4
H7
H8
R5
F
R9
H14
H15
F
F
F
R11
F
R10
H21 H22 H23
H12
H13
H24 H25 H26
10
DVMRP (1/6)
DVMRP (2/6)
 RFC 1075 (Nov.88), draft Version 3 en cours
 Distance Vector Multicast Routing Protocol
 but : réduire le trafic au cœur du réseau
H1
H4



DVMRP (3/6)
H1
H4
D
D
H3
R6
H11
H16
H17
R8
R12
D
R5
H4
H5
H11
R7
H16
H17
D
R13
D
H18 H19 H20
F
P
H14
H15
H12
R9
H13
F
F
P
P
R10
H24 H25 H26
H4
F
R1
F
F
R3
R2
H13
H11
H16
R8
R12
H18 H19 H20
H6
H7
G
R5
H8
G
H14
R9
H12
H13
H15
F
R13
F
H24 H25 H26
H3
R4
F
R7
F
R10
R6
Greffe
H2
R11
F
H21 H22 H23
R10
H24 H25 H26
DVMRP (6/6)
R6
L’arbre après
la greffe
H2
R3
H3
H6
R4
D
processus périodique d’inondation
d inondation et
D
H14
R9
D
H15
H21 H22 H23
H12
d’élagage pour chaque source
H13
mémorisation des enregistrements prune
D
R11
D
problèmes communs aux protocoles à
vecteurs de distance
H7
H8
R5
D
R8
R12
R5
H21 H22 H23
H1
H17
D
H10
H7
H8
R11
F
H18 H19 H20
H12
H15
R2
H9
R13
F
H9
R9
R1
D
D
P
P
P
F
DVMRP (5/6)
D
H6
P R4
F
F
H10
H14
H21 H22 H23
H1
P
H8
R11
D
H18 H19 H20
F
R8
P
R12
F
F
P
F
H7
D
R13
D
H16
H17
P
F
H5
D
R7
F
H3
F
R6
Inondation et
élagage
H2
R3
P
F
R7
H11
H6
R4
D
H10
F
H10
L’arbre après
élagage
H2
R3
R2
H9
R2
F
P
F
DVMRP (4/6)
R1
D
H5
R1
H9
pruning)
s’il n’a pas de membre sur son LAN, un routeur feuille envoie un
message prune à ses voisins
un routeur feuille peut envoyer un prune sur toutes ses if, sauf
celle correspondant à son SP avec la source (i.e. l’if RPF)
quand un routeur intermédiaire reçoit un prune sur chacune de
ses if, sauf l’if RPF, il remonte le prune en amont
quand un routeur envoie un prune, il mémorise la paire
(Source, Groupe) pour laquelle le prune a été envoyé
F
H5
 principe : inondation et élagage (flooding and

F
F
R10
(Source, Groupe)
H24 H25 H26
11
MOSPF
 Approche inondation / élagage
 RFC 1584 (March 94)
 Multicast Open Shortest Path First

Au départ



RPF (Reverse Path Forwarding)
RPB (Reverse Path Broadcasting)
TB (Truncated Broadcasting)
RPM (Reverse Path Multicasting)
DVMRP
PIM-DM
 Approche à état des liens
 MOSPF
 principe


problème : scalability avec la taille du réseau


Multicast OSPF (MOSPF)
 Ajout à OSPF (Open Shortest-Path First,
protocole de routage intra-domaine à état des
liens)
 Multicast
Multicast-capable
capable routers flag link state
routing advertisements
 Chaque routeur indique les groupes pour
lesquels il y a des membres connectés
directement
État du lien : chaque routeur inonde avec l'annonce de l'état du lien
Multicast : ajout de l'information de membre à l'"état du lien"
Chaque routeur calcule l'arbre multicast pour chaque source active
et construit l'entrée avec la liste des interfaces de sortie
S1
opère dans un AS qui utilise OSPF pour l’unicast
étend OSPF en ajoutant les informations
d’
d’appartenance
aux iinformations
f
i
d’é
d’états d
des liliens quii
sont diffusées par OSPF
mémorisation d’un enregistrement par groupe et par
lien du réseau
un arbre par source
MOSPF (suite)
 Les annonces d'état des liens sont
augmentées par les adresses des groupes
multicast auxquels le membres locaux se
sont abonnés
 L'algorithme de routage à état des liens est
augmenté pour calculer l'arbre de
distribution de plus court chemin entre
n'importe quelle source et n'importe quel
ensemble de destinations
Z a la carte du réseau, incluant les membres au niveau de X et de Y
Z calcule l'arbre de plus court chemin de S1 vers X et Y
Z construit une entrée multicast avec une interface de sortie
W, Q et R construisent chacun une entrée multicast
S1
Z
Z
W
Q
X
X
R
R1
R1
Y
Y
R2
R2
12
L'annonce de l'état des liens avec une nouvelle topologie peut
nécessiter un nouveau calcul de l'arbre et des entrées de la table
L'annonce d'état des liens (T) avec une nouvelle annonce de membre
(R3) peut nécessiter le calcul incrémental et l'addition d'une interface
à la liste des interfaces de sortie (Z)
S1
S1
Z
Z
W
R3
W
Q
T
Q
X
X
R
R1
R
R1
Y
Y
R2
R2
Impact sur le calcul de la route
Arbre partagé
 On ne peut pas pré-calculer tous les arbres
Arbre de coût minimum
multicast par source
 Calcul à la demande qquand le ppremier ppaquet
q
d'une source S vers un groupe G arrive
 Transmission d'un paquet sur les interfaces
sortantes qui correspondent à la portion
locale de l'arbre
Les algorithmes MCT (1/2)
 Arbre contraint
 Approche centrée
Les algorithmes MCT (2/2)
S
 but : minimiser le coût total de l’arbre
 2 familles


R1
les algorithmes Minimum Spanning Tree
 contrainte : l’arbre ne doit aucun nœud qui ne soit pas
membre du groupe
 ex : algorithme de Prim
D1
R2
les algorithmes Minimum Steiner Tree





la contrainte est levée
problème NP-complet
ils supposent de connaître toutes les liaisons du réseau
ils sont monolithiques
ils n’exploitent pas les informations déjà disponibles de
routage unicast
S
R8
D5
R1
R3
D2
R5
D3
R4
R6
D4
R7
R9
R10
D6
R11
D7
l’arbre obtenu avec un algorithme
à vecteurs de distance
rq : dist(S, D6) = 5
D1
R2
D5
R3
D2
R5
D3
R6
D4
R9
R10
R11
D7
D6
l’arbre de Steiner
rq : dist(S, D6) = 7
13
Arbre partagé
Les algorithmes CT
 Arbre de coût minimum
 but : minimiser simultanément la dist(S, Di) et
le coût total de l’arbre
Arbre contraint
 principe
associer à chaque lien 2 métriques (distance/délai
et coût)
rechercher l’arbre à coût minimum tel que dist(S,
Di) 

 Approche centrée

Arbre partagé
CBT (1/3)
 Arbre de coût minimum
 RFC 2189 et 2201 (Sept.97)
 Core Based Tree (Group-shared Tree)
 but : éviter les inconvénients de DVMRP et
 Arbre contraint
MOSPF

Approche centrée

résistance au
a facteur
facte r d’échelle : un
n seul
se l arbre pour
po r le
groupe
efficacité (éviter les inondations) : messages de Join
et de Leave explicites
 principe : construire un arbre partagé,
bidirectionnel, avec un cœur unique
CBT (2/3)

construction de l’arbre
 un routeur local qui a un nouveau membre pour un groupe
envoie un message join-request vers le cœur en unicast
 le cœur ou le premier routeur sur le chemin faisant déjà
partie de l’arbre répond par un join-ack
q routeur ayant
y
vu p
passer le j
join-request
q
marque
q
 chaque
l’if sur laquelle il l’a reçu

maintien de l’arbre
 chaque routeur envoie périodiquement des echo-request
à son routeur amont
 le routeur amont répond par des echo-reply
 si un routeur aval n’obtient pas de réponse au bout de N
essais, il détache son sous-arbre en envoyant un flushtree
CBT (3/3)
 R4

R1
R2
R3
cœur




avantages




S
 R1 envoie un join (G) au cœur
 R2 marque l’if R2-R1 pour faire
suivre ultérieurement les paquets
 R3 marque l’if R3-R2
 le cœur marque l’if cœur-R3
 lorsque R4 rejoint G, son join
s’arrête à R2
 R2 marque l’if R2-R4
 pour envoyer un paquet à G, S l’envoie
en unicast au cœur qui fait suivre
pas d’inondation (vs. DVMRP)
un hôte peut joindre/quitter un groupe sans délai (vs. DVMRP)
un enregistrement par groupe avec les if sortantes (vs. DVMRP)
pas de calcul explicite d’arbre (vs. MOSPF)
inconvénients


problèmes de fiabilité, robustesse et de congestion pour le cœur
l’arbre n’est pas optimal pour toutes les sources
14
PIM (1/3)
PIM (2/3)
 RFC 2362 (June 98)
 Protocol Independent Multicast
 idée : distinction explicite de 2 scénarios de
 le mode épars
distribution
le mode dense



S
D
R4
R1


pas d’acquittement en réponse au join
le join est envoyé périodiquement pour «rafraîchir» l’arbre
 le point de RDV informe une source active qu'elle doit arrêter
d’émettre lorqu’il n’y a plus de routeurs dans l’arbre
 changement de mode possible : de l’arbre partagé vers l’arbre par
source
 les points de RDV émettent périodiquement en aval pour indiquer
leur activité
Plan
R3
R2
les membres sont géographiquement éparpillés
but : un routeur ne doit pas avoir à travailler, à moins de
rejoindre un arbre
principe : approche center-based, similaire à CBT

cœur
• R1 sait que son SP avec S passe par son if R1-R4
• or, R1 reçoit les paquets Mcast sur son if R1-R2
• R1 envoie un join à R4
• R1 envoie ensuite un prune au cœur
• le cœur arrête le transfert Mcast sur cœur-R2
et R2-R1
chemin avec CBT


les membres sont géographiquement concentrés
dans une zone
idée : RPF avec flood-and-prune, similaire à DVMRP
est alors raisonnable
chemin
avec PIM


 sauf :
PIM (3/3)


le changement de mode permet de décharger le cœur
en cas de panne du cœur, les hôtes ayant commuté de
mode continuent de recevoir
PIM ne dit pas comment un routeur détermine le point de
RDV d’un groupe
PIM ne dit pas comment déterminer si un groupe est dense
ou épars
 Introduction




Le protocole IGMP
Le m
multicast
lticast ssurr un
n LAN
 Le
MBone
 Perspectives
Le Mbone (1/3)
Le Mbone (2/3)
 problème
 principe : le tunneling


pour mettre en œuvre le Mcast sur l’Internet, il faut que tous les
routeurs aient des fonctions de Mcast et que les routeurs locaux
supportent IGMP
la plupart des routeurs de l’Internet ne supportent pas le Mcast !!!
 idée


bâtir des sous-réseaux
sous réseaux capables de Mcast à la périphérie de
l’Internet
les interconnecter par des tunnels, les extrémités des tunnels sont
des stations avec mrouted et un support de l’OS pour le Mcast
 Multicast Backbone of the Internet




réseau virtuel de recouvrement, solution transitoire
premier tunnel en 88 entre BBN et Stanford
des milliers de sous-réseaux aujourd’hui
utilisé pour diffuser des sessions IETF ou des conf. IEEE/ACM

encapsulation des paquets Mcast transmis sur le Mbone dans des
paquets IP classiques
 l’extrémité du tunnel réceptrice détecte qu’elle a un paquet IP
encapsulé dans un paquet IP (protocol =4)
 après désencapsulation, elle fait suivre le paquet Mcast


soit en local sur son sous-réseau
sous-réseau, s’il
s il a des hôtes membres
soit au prochain routeur Mcast, après ré-encapsulation
en-tête IP unicast
le paquet Mcast d’origine
@ M1
@ M2
@ M1 224.5.5.5
unicast unicast unicast
encapsulation
M1
désencapsulation
M2
tunnel
R1
données
R2
chemin réel
15
Le Mbone (3/3)
Plan
 trafic


 Introduction
les conférences génèrent typiquement 100-300 kbits/s
(limité à 500 kbit/s)
pas de mécanisme de «police» mais une déontologie de
l’utilisateur
 fiabilité
fi bilité
 applications






 SRM
annuaires de session (sd, sdr)
conférences audio (vat , nevot , rat)
conférences vidéo (nv , ivs , vic , nevit)
tableau blanc (wb)
éditeur de textes (nte)
jeux distribués interactifs (MiMaze)
 RMTP
 Perspectives
Fiabilité
 peut-on étendre l’approche utilisée en unicast (ACK) ?




chaque destination doit envoyer un ACK pour chaque (groupe de)
message(s)
un msg est retransmis jusqu’à réception d’un acquittement de
chaque destinataire
congestion du réseau
implosion de la source
SRM (1/2)
 Scalable Reliable Multicast


 un composant indépendant de l’application : offre les mécanismes pour
demander et récupérer les segments de données manquants
 un composant dépendant de l’application
l application : est responsable du nommage
des segments de façon à ce qu’ils soient identifiés de manière unique
par tout le groupe et de l’ordonnancement
 idée : utiliser des NAK



le contrôle est déplacé de l’émetteur vers les récepteurs
la source émet sans se préoccuper des ACK
les récepteurs détectent les pertes sur «trous» de N° de séquence
 idée : un segment manquant n’est pas forcément
retransmis par la source
 de nombreux protocoles ont été proposés




atomicité : soit 0 soit tous les récepteurs ont reçu le msg
terminaison : le résultat d’une transm. est connu en un temps fini
SRM, RMTP, RAMP, RMP, etc.

SRM (2/2)
RMTP
hyp : D5, D6 et D7 ont
un msg manquant
 un seul membre demande la retransm.
 un seul membre retransmet le msg
manquant
 dimensionnement des Timers
 estimation du RTT pour chaque
paire (Di, Dj)

S3/D3
 envoi des requêtes : slotting +
 difficulté

S2/D2
D4
D5


D7

nouveaux msgs
req. de retransm.
retransmissions

S
notion de hiérarchie
réduire l’implosion à la source
 éd i lles temps d
réduire
de réponse
é
notion de reprise en local
principe

D6
offre une transmission point à multipoint, fiable, avec maintien de
séquence
 idées
S1/D1
 principe
 Request Timer
 envoi des retransmissions
 Repair Timer
sur détection d’une perte, la demande de retransm. est Mcastée
le récepteur le plus proche du demandeur Mcaste la retransmission
 Reliable Multicast Transport Protocol
 but : minimiser le trafic
damping
offre une transmission fiable, sans séquencement, «scalable» (car
receiver-based + reprise en local)
2 composants
les récepteurs sont groupés
dans des régions locales
il y a un DR (Designated
Receiver) par région, chargé
d’agréger les msg de status
DR1
D
DR2
DR4
D
D
D
DR3
D
D
D
D
msg de status
difficulté : construire l’arbre logique
16
Plan
 Introduction
Perspectives au niveau réseau
 adressage et routage à l’intérieur d’un groupe
D1
 Perspectives de recherche
réseau
 niveau transport
 niveau application
D
S
S
R1
R1
R2
D
R3
D
R4
D
 niveau
R5
D
D
D
D
R3
D
D
R4
D
multicast sur un sous-arbre

D2
R2
D2
R5
D
D
D
D1
reachcast
routage multicast dans un réseau mobile
routage multicast avec QoS

Perspectives au niveau transport
Perspectives au niveau application
 contrôle de flux/congestion
 allocation des adresses multicast
 fiabilité assistée par les routeurs
 nommage d’objets partagés
 auto-configuration des membres du groupe
Plan
 Introduction
fiabilité
 SRM
 RMTP
Perspectives


Motivation commerciale
 Problème



Le trafic dans l'Internet croît d'environ 100% par an
La technologie des routeurs s'améliore de 70% par an
Les routeurs suffisamment rapides sont très coûteux
 Les ISPs doivent trouver un moyen
y de réduire le
trafic
 Le multicast pourrait être utilisé pour…



Le Web : distribuer les données depuis des sites en vogue
vers des caches à travers l'Internet
Envoyer des flux multicast audio/vidéo
La distribution de logiciel
17
Problèmes d'ISP
 Le multicast entraîne une haute utilisation du réseau



Une source peut produire une charge totale du réseau élevée
Les applications multicast expérimentales demandent
relativement beaucoup de bade passante : audio et vidéo
Pas de contrôle de flux dans la plupart des applications multicast
 Le multicast casse le modèle de facturation telco/ISP



Actuellement, à la fois l'émetteur et le récepteur payent la BP
Le Multicast permet à l'émetteur d'acheter moins de BP tout en
atteignant autant de récepteurs
La charge sur le réseau de l'ISP n'est pas proportionnelle au
débit de la source
Economie du Multicast
 Un paquet envoyé à plusieurs récepteurs
 émetteur
+ bénéficie de la réduction de la charge du réseau
comparée à l'unicast
+ coût
ût d
de connectivité
ti ité au réseau
é
plus
l faible
f ibl
 Fournisseur de service réseau
- Un paquet envoyé peut causer une charge plus
élevée qu'une charge de paquet unicast
+ réduit le trafic global qui circule sur le réseau
 Récepteur
= même nombre de paquets reçus qu'en unicast
Problèmes du multicast
Solution actuelle de multicast pour les ISPs
 Le multicast n'est pas mûr



protocoles et applications non mûrs
Les outils sont pauvres, difficiles à utiliser, le débuggage est
difficile
Les protocoles de routage laissent beaucoup de questions non
résolues
 Interopérabilité de l'inondation et élagage / abonnement explicite
 Instabilité de routage
 Restriction des émetteurs de données multicast
 Facturation des émetteurs pour distribuer du trafic
multicast

 Le développement multicast s'est focalisé sur les problèmes
académiques, pas sur les problèmes commerciaux


Le multicast casse le modèle de facturation telco/ISP
Le routage ne s'est pas intéressé aux politiques
 PIM, DVMRP, CBT ne s'occupent pas des problèmes de politiques
d'ISP
 BGMP s'en préoccupe un peu, mais il est encore en cours de
développement
Agréments statiques
 Ne pas transmettre du trafic multicast


certains ISP offrent un trafic multicast à leurs utilisateurs
(ex UUNET UUCast)
Les ISP commencent à négocier des accords entre pairs
Bibliographie

[RFC 1112] S. Deering, «Host Extensionsfor IP Multicasting», August 1989.

[RFC 1075] D. Waitzman, S. Deering, C. Partridge, «Distance Vector Multicast Routing Protocol»,
November 1988.
[RFC 1584] J. Moy, «Multicast Extensions to OSPF», March 1994.
[RFC 2189] A. Ballardie, «Core Base Trees (CBT Version 2) Multicast Routing: Protocol
Specification», September 1997.
[RFC 2201] A. Ballardie, «Core Base Trees (CBT Version 2) Multicast Architecture», September
1997.
[RFC 2236] R. Fenner, «Internet Group Management Protocol, Version 2», November 1997.
[RFC 2362] D.
D Estrin,
Estrin D.
D Farinacci,
Farinacci A.
A Helmy,
Helmy D.
D Thaler,
Thaler S.
S Deering,
Deering M.
M Handley,
Handley V
V. Jacobson
Jacobson, C
C.
Liu, P. Sharma, L. Wei, «Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification, June 1998.
C. Diot, W. Dabbous, J. Crowcroft, «Multipoint Communication: A Survey of Protocols, Functions
and Mechanisms», IEEE JSAC, Vol.15, N°3, April 1997.
S. Floyd, V. Jacobson, S. McCanne, C.G. Liu, L. Zhang, «A Reliable Multicast Framework for Lightweight Sessions and Applications Level Framing», Proc. of ACM SIGCOMM’95, October 1995.
S. Paul, K.K. Sabnani, J.C. Lin, S. Bhattacharyya, «Reliable Multicast Transport Protocol (RMTP)»,
IEEE JSAC, Vol.15, N°3, April 1997.
S. Paul, «Multicasting on the Internet and its Applications», Kluwer Academic Publishers, 1998.
http://www.mbone.com










18
Motivation
• Plusieurs applications requièrent des communications de unà-plusieurs (i.e. multicast)
–
–
–
–
–
Video/audio conférences
Vidéo à la demande
Tableau blanc partagé
Enseignement à distance
Dissémination d’informations (quotations boursières, mises à
jour de logicels)
– …
IP Multicast
Prométhée Spathis
Laboratoire CNRS-LIP6
[email protected]
Multicast Advantages
Enhanced efficiency: Controls network traffic and reduces
server and CPU loads
Optimized performance: Eliminates traffic redundancy
Distributed applications: Makes multipoint applications
possible
• For the equivalent amount of multicast traffic
traffic, the
sender needs much less processing power and
bandwidth.
• Multicast packets do not impose as high a rate of
bandwidth utilization as unicast packets, so there is
a greater possibility that they will arrive almost
simultaneously at the receivers.
Passage à l’échelle ((scalability
scalability))
source
• Utilisation de communications point-à-point (i.e. unicast) avec
réplication des données au niveau de la source
˃ Impossible en raison du facteur d’échelle (scalability)
Multicast Disadvantages
Multicast is UDP-based.
• Best-effort delivery
Heavy drops in Voice traffic
Moderate to Heavy drops in Video
•
•
•
•
No congestion avoidance
Duplicate packets may be generated
Out-of-sequence delivery may occur
Efficiency issues in filtering and in security
Routage Multicast (et autres fonctions)
fonctions)
source
• Unicast par réplication des données à la source :
–
–
–
–
Surchage de la source
Copies multiples d’une même donnée en transit sur un même lien
Connaissance à jour de la liste de tous les récepteurs intéressés
…
Routage (calcul des routes) [en sens inverse]
Acheminement des paquets avec réplication éventuelle
Abonnement dynamique : élagage/greffage de branches (pruning/grafting)
Modèle de service et sémantique
Modèle de service
• Notion de groupe ouvert
• Aucune synchronisation entre source et récepteurs
– Un groupe est l’ensemble des récepteurs qui partagent le même
intérêt pour un contenu donné
– Un récepteur qui souhaite appartenir à un groupe doit s’y abonner
explicitement
– Un
U groupe estt identifié
id tifié par une adresse
d
d
de classe
l
D
D, indépendante
i dé
d t
de la localisation des récépteurs abonnés
– Il suffit de connaître l’adresse d’un groupe pour atteindre tous ses
membres, …
– … sans nécessairement être abonné au groupe ou être connu des
autres membres.
– Une source peut commencer à émettre alors que le groupe est
encore vide
– Un récepteur nouveau venu prend le train en marche
• Avantages : passage à l’échelle
– aucune restriction sur le nombre et la localisation des membres
• Inconvénients :
– Aucun moyen de savoir qui écoute ou de bloquer certaines sources
• La composition d’un groupe est dynamique :
– Un récepteur peut se désabonner à sa convenance
Le multicast existait avant l’Internet
• Le multicast est supporté au
niveau 2 (liaison de données)
• Implémenté par Ethernet avant
de l’être au niveau IP
• Etendre ce modèle de comm. à
un réseau à échelle de l’Internet
• Concevoir un service multicast
au niveau IP …
• … en tirant partie des
fonctionnalités multicast déjà
existantes au niveau 2
Le multicast Ethernet : à quoi bon ?
hôtes
• Eviter de perturber les stations non concernées par une trame
˃ en ménageant les ressources de ces stations telles que leurs
capacités de réception (buffers) ou de traitements (CPU)
• Les stations concernées appartiennent à un groupe identifié par
une adresse multicast MAC Ethernet
• Ces stations ont en commun d’être toutes configurées avec
l’adresse multicast MAC Ethernet du groupe
routeurs
˃ une carte réseau est configurée avec autant d’adresses multicast
MAC Ethernet que de groupes auxquels appartient la station …
˃ … en plus de l’adresse MAC Ethernet unicast codé en dur par le
constructeur de cette carte
• Le filtrage au niveau 2 est plus efficace car réalisé par le matériel
alors qu’au niveau 3 logiciellement (consommation de CPU, …)
Le multicast Ethernet : à quoi bon ?
MAC DA
broadcast
unicast
FF:FF:…:FF
AA:BB:…:CC
Format des adresses multicast
Aucune station ne filtre les trames
au niveau 2 : toutes les stations
passent le paquet encapsulé à la
couche 3
• Adresses MAC Ethernet multicast (48 bits)
La station 3 laisse passer le paquet
Les autres stations filtrent la trame
adresse de groupe broadcast et multicast si positionné
multicast
01:00:5A:01:01:01
Seules les stations abonnées
passent le paquet à leur couche 3
• Adresses IP multicast – Classe D (32 bits)
S
01:00:5A:01:01:01
Toujours un seul exemplaire
de la trame envoyé par S
adresse universelle si positionnée ou locale sinon
AA:BB:…:CC
Toutes les stations voient
passer la trame
1 11 0
Identifiant du groupe (sur 28 bits)
en notation décimale pointée : 224.0.0.0 — 239.255.255.255
Utilisation des fctés multicast de niveau 2
Unicast Ethernet
• Implantation et déploiement de IP multicast controversé
• Un paquet IP unicast est encapsulé dans une trame dont
l’adresse MAC de destination est déterminé par ARP
˃ conversion des adresses de couche 3 en adresses MAC …
… au prix d’un broadcast sur le segement
– le principe du "bout en bout" : les partenaires d'une communication
dialoguent depuis chaque extrémité du réseau pour établir et gérer leur
communication.
– peu ou pas de contrôle : potentiellement dangereux
• Déploiement sans effets sur les autres stations du réseau
• Pas de perturbation du trafic existant
couche 2
couche 3
00:08:...:37 10.0.0.1
• Utilisation des fonctionnalités multicast offertes par la couche 2
˃ Mise en correspondance entre adresses Ethernet et adresses IP
multicast
MAC DA
Network
Protocol DA
“envoyer moi
à tous”
“envoyer moi
à tous les
hôtes de ce
sous-réseau”
Broadcast Ethernet
Multicast IP et Broadcast Ethernet
• L’adresse IP de broadcast (255.255.255.255) correspond à
l’adresse Ethernet de broadcast (FF:FF:FF:FF:FF:FF)
• Diffusion d’un paquet IP sur un réseau Ethernet par encapsulation
dans une trame dont l’adresse de destination est l’adresse MAC
FF:FF:FF:FF:FF:FF
˃ mécanisme de résolution d’adresses inutile
• Encapsulation des paquets IP multicastés
˃ Utilisation de l’adresse Ethernet broadcast (FF:FF:FF:FF:FF:FF)
pour le trafic IP Multicast ?
couche 2
couche 2
couche 3
FF:FF:…:FF
254.1.1.1
MAC DA
Protocol DA
couche 3
fffff…f
255.255.255.255
MAC DA
Protocol DA
“envoyer moi
à tous”
Network
“envoyer moi
à tous les
hôtes de ce
sous-réseau”
“Envoyer moi
à tous
Network
“Envoyer moi aux
machines hôtes
de ce groupe”
˃ Solution inefficace car elle affecte toutes les machines du réseau,
y compris celles non abonnées au groupe ! (filtrage logiciel)
Ethernet Multicast ?
Report des abonnements
• Pour multicaster efficacement un paquet IP sur un réseau
Ethernet, il suffirait de l’encapsuler dans une trame dont l’adresse
de destination est une adresse MAC Ethernet multicast
• Mais comment faire correspondre adresses multicast de niveau 3
et de niveau 2 ?
˃ ARP étendu aux adresses IP multicast : non scalable
• Une machine hôte qui s’abonne à un groupe multicast au niveau
IP se met à écouter les trames envoyées sur une adresse MAC
Ethernet multicast construite à partir de l’adresse IP multicast du
groupe
• Le mécanisme de construction des adresses MAC Ethernet
multicast
lti
t estt connu des
d machines
hi
hôtes
hôt émettrices.
é tt i
˃ Les paquets IP multicastés par la source sont encapsulés dans
une trame dont l’adresse MAC Ethernet est construite de la même
manière
reporter les abonnements IP au niveau Ethernet
• Protocole de résolution d’adresses IP Multicast rendu inutile
• Les adresses MAC Ethernet multicast sont déduites localement
aux machines hôtes
Ethernet Multicast ?
Adresses Ethernet MAC multicast
• Pour multicaster efficacement un paquet IP sur un réseau
Ethernet, il suffirait de l’encapsuler dans une trame dont l’adresse
de destination est une adresse MAC Ethernet multicast
• Mais comment faire correspondre adresses multicast de niveau 3
et de niveau 2 ? reporter les abonnements IP au niveau Ethernet
• Utilisation des fonctionnalités multicast de niveau 2 par IP
˃ conversion des adresses IP multicast en adresses MAC Ethernet
couche 2
couche 3
0100.5A01.0101 254.1.1.1
MAC DA
“Envoyer moi aux
stations de ce
groupe”
• Eviter que le résultat de cette conversion ne soit des adresses
j utilisées
MAC Ethernet déjà
˃ réservation d’un bloc d’adresses MAC Ethernet à cet effet
Network
01-00-5e-00-00-00
Protocol DA
Préfixe partagé
long de 25 bits
“Envoyer moi aux
machines hôtes
de ce groupe”
Adresses Ethernet MAC multicast
00000001:00000000:01011110:00000000:00000000:00000000
00000001 00000000 01011110 01111111 11111111 11111111
00000001:00000000:01011110:01111111:11111111:11111111
• Dans ce bloc d’addresses MAC Ethernet, les adresses partagent
les 25 bits de poids fort en commun
• Les 23 bits restants (48 – 25) sont utilisées dans la conversion
des adresses IP en adresses MAC Ethernet multicast
˃ Recopie des 23 bits de poids faible de l’adresse IP multicast
01-00-5e-7F-FF-FF
Conversion des adresses multicast
• Le préfixe des adresses MAC Ethernet multicast est long de 3
octets et vaut : 01-00-5E
• La moitié de ce bloc a été réservée pour la conversion des
adresses IP multicast en adresses MAC Ethernet
˃ Le 25e bit est positionné à ‘0’, soit en binaire :
00000001 00000000 01011110 0XXXXXXX XXXXXXXX XXXXXXXX
00000001.00000000.01011110.0XXXXXXX.XXXXXXXX.XXXXXXXX
• Les 23 bits restants sont copiés depuis l’adresse IP multicast
˃ Une machine hôte qui s’abonne au niveau IP au groupe identifié
par l’adresse 224.10.8.5 …
˃ … se met au niveau 2 à l’écoute des trames envoyées à l’adresse
MAC Ethernet 01-00-5E-0A-08-05 :
˃ les paquets que ces trames encapsulent sont systématiquement
passés à la couche 3
Exemple de conversion IP – MAC Ethernet (1)
Exemple de conversion IP – MAC Ethernet (2)
Adresse IP multicast:
Adresse IP multicast:
11100000.0
1110
0000.00000001.00000001.00000010
0000001.00000001.00000010
11100000.0
1110
0000.00000001.00000001.00000010
0000001.00000001.00000010
11100000.1
1110
0000.10000001.00000001.00000010
0000001.00000001.00000010
5 bits non recopiés
11100001.0
1110
0001.00000001.00000001.00000010
0000001.00000001.00000010
...
11101111.1
1110
1111.10000001.00000001.00000010
0000001.00000001.00000010
Adresse MAC Ethernet :
Adresse MAC Ethernet :
00000001.00000000.01011110.00000001.00000001.00000010
00000001.00000000.01011110.0
0000001.00000001.00000010
00000001.00000000.01011110.00000001.00000001.00000010
00000001.00000000.01011110.0
0000001.00000001.00000010
Le filtrage n’est plus possible au niveau 2 !
Qu’à celà ne tienne : le filtrage sera fait au niveau IP
Chevauchement des adresses IP multicast
converties
224.1.1.1
S
01:00:5E:01:01:01
couche 2
couche 3
0100.5E01.0101 224.1.1.1
MAC DA
Protocol DA
238.129.1.1
01:00:5E:01:01:01
couche 2
couche 3
0100.5E01.0101 238.129.1.1
MAC DA
Protocol DA
• Les 2 machines hôte reçoivent les trafics destinés aux deux
groupes multicast (224.1.1.1 et 238.129.1.1) …
• … en dépit de leur abonnement respectif
˃ filtrage au niveau 3 en dernier ressort
˃ Mais probabilité faible : 1/223
Composants de l’archicture IP Multicast
Conversion non bijective (mais subjective)
bloc de 32 adresses IP Multicast
224.1.1.1
224.129.1.1
225.1.1.1
225.129.1.1
.
.
.
238.1.1.1
238.129.1.1
239.1.1.1
239.129.1.1
Une seule adresse MAC Ethernet
0x0100.5E01.0101
• Le filtrage n’est plus possible au niveau Ethernet
• Qu’à cela ne tienne : le filtrage est réalisé au niveau IP sur la
base des adresses IP de destination des paquets reçus
Internet Group Management Protocol
(IGMP)
• Protocole qui permet aux machines hôtes de rapporter leurs
abonnements en cours au routeur multicast voisin
Modèle de service
IGMP
entre
t hôtes
hôt ett routeurs
t
hosts
routers
Routage intra-domaine
– IGMPv1 [RFC-1112], première version standardisée et déployée à
grande échelle
– IGMPv2 [RFC-2236], réduction du temps nécessaire au routeur pour
prendre connaissance des groupes dans lesquels il n’y
n y a plus aucun
membre
– IGMPv3 [RFC 3376], ajout du filtrage de source
• Permet aux routeurs de maintenir la liste de groupes non vides
• Occupe la même position que ICMP dans la pile TCP/IP
Routage inter-domaine
Fonctionnement de IGMP (1)
• Sur chaque brin, un routeur est élu comme “querier”
• Le querier envoie périodiquement un Membership Query à
tous les systèmes multicast (224.0.0.1), avec un TTL à 1
• Sur réception du Query, les hôtes enclenchent un temporisteur
aléatoire (entre 0 et 10 secondes) pour chaque groupe de
diffusion auxquelles ils sont abonnés
• A l’expiration du temporisateur enclenché pour un groupe G,
une machine hôte renvoie un Membership Report par groupe
G, avec un TTL à 1
• Les autres membres de G qui entendent ce Report, désarme
leur temporisteur
• Les routeurs écoutent tous les Reports, les informations
concernant les groupes qui ne répondent pas expirent
Les messages IGMPv1
IGMP Query
router
IGMP report
router
A
Multicast interested hosts
Other hosts
B
A
A
router
routing update
routing update
30 sec
router
t
•
˃
•
˃
Envoi des Queries périodiquement
prise en cpte de la dynamicité des groupes
Envoi différé aléatoirement des Reports :
réduction du nbre de Reports reçus en réponse à un Query
– en théorie, un seul report par groupe G en réponse à un Query
– le routeur ne cherche pas à connaître la liste des membres de G
router
t
LAN 2
IGMP
report
IGMP
IGMPreport
query
LAN 1
Group
member
LAN 3
Group
member
IGMP query
• Les intervalles entre Queries successifs choisissent entre 60 et 90
secondes
• Une machine hôte qui s’abonne à un groupe
– envoie immédiatement un ou deux Reports non sollicités
– sans attendre que le routeur envoie un Query
Group
member
• Une machine hôte qui souhaite quitter un groupe ?
– désabonnement implicite
IGMP Version 2 améliorations apportées
IGMPv2 Leave et Group
Group--Specific Query
• Procedure d’éléction du routeur querier sur chaque brin
– dans la version 1, à la charge des protocoles de routage
– comparaison de l’adresse des routeurs candidats
router
• Group-Specific Query Message
IGMP Group-specific
Query
IGMP leave
– interrogation sélective des membres d’un groupe en particulier
– et non toutes les systèmes multicast du sous-réseau (224.0.0.1)
A
B
A
A
• Leave-Group Message
– indiquation explicite d’un désabonnement
– réduction du temps nécessaire au routeur pour déterminer les groupes
qui ne contiennent plus aucun membre
– envoyés à tous les routeurs multicast du sous-réseau (224.0.0.2)
– sur réception d’un Leave-Group pour un groupe G, un routeur utilise les
Group-Specific Query pour vérifier s’il reste des membres abonnés à G
IGMPv2 –GroupGroup-Specific
Multicast interested hosts
Other hosts
IGMPv2
•
Group-specific query
•
Leave group
•
Query-interval response time
•
Eléction du routeur Querier
router
router
router
prune (S,G)
router
router
Group
Member
Specific
G query
IGMP Group
Leave G
Group
Member
router
Group
Member
– Les routeurs envoient un Membership Query pour un groupe en
particulier
˃ réduction du traffic
– Une machine hôte quitte explicitement un groupe
˃ réduction du temps nécessaire pour que son abonnement soit effectif
au niveau du routeur
– Le routeur Querier fixe l’intervalle de temps séparant entre Query et
Report
˃ contrôle des rafales de trafic et réduction délai nécessaire à la prise
en compte des désabonnements
– IGMPv2 ne repose plus sur le protocole de routage multicast
IGMP Version 3
Limitations of IP Multicast
• Différence avec la version 2:
– extension de l’interface de service et modification du protocole pour
permettre aux récepteurs de spécifier une liste de machines hôtes
comme sources émettrices autorisées ou interdites
 pour écouter le trafic provenant seulement des sources
appartenant à cette liste
 pour écouter le trafic provenant de toutes les autres les sources à
part celles appartenant à cette liste
• Difficult to support high level functionalities on upper layer
– E.g. congestion control, reliability
– Network and receiver heterogeneities
• Routers need maintain per-group state
• Limited multicast addresses (class D only)
• Compatibilité avec les versions précédentes (1 & 2)
Multicast Today
Multicast Today
• Mbone applications starting in early 1990s
• Mbone applications starting in early 1990s
– Primarily video conferencing, but no longer operational
– Primarily video conferencing, but no longer operational
• Still many challenges to deploying IP multicast
• Still many challenges to deploying IP multicast
– Security vulnerabilities, business models, …
– Security vulnerabilities, business models, …
• Application-layer multicast is more prevalent
• Application-layer multicast is more prevalent
– Tree of servers delivering the content
– Collection of end hosts cooperating to delivery video
– Tree of servers delivering the content
– Collection of end hosts cooperating to delivery video
• Some multicast within individual ASes
• Some multicast within individual ASes
– Financial sector: stock tickers
– Within campuses or broadband networks: TV shows
– Backbone networks: IPTV
– Financial sector: stock tickers
– Within campuses or broadband networks: TV shows
– Backbone networks: IPTV
39
IP Multicast Deployment Issues
End--System Multicast
End
• IP multicast still is not widely deployed
• IP Multicast-capable routers at all levels of the network
– Technical and business challenges
– Should multicast be a network-layer service?
– From backbone to edge routers
• Management and security issues
–
–
–
–
–
40
• ALM: Multicast tree of end hosts
The ease of flooding attacks via multicasting
Unauthorized reception of data from a multicast session
Allocation of same multicast address for 2 sessions
Setting up firewalls while allowing multicasting
…
– Allow end hosts to form their own multicast tree
– Hosts receiving the data help forward to others
• Billing and service charge
– No model to charge for the delivery of packets duplicated
• …
41
42
Advantages of Application
Application--Layer Multicast
• Easy to support high level functionalities
– Make use of end-host resource (e.g. memory, process power) to make a
more sophisticated decision
– Make use of the existing solutions for unicast congestion control and
reliability
• Able to modify the content of data
• Does not need router support
• Unlimited multicast addresses

Support de Cours n°1 Introduction Sécurité Multicast

Transcription

Documents pareils

Soutenance de thèse de Joanna Moulierac

TP Multimédia

Outils et applications multicast

Nouveautés mai 2016 L`art et le chat, de Philippe Geluck. Charles

Vidéo à la demande et Multicast V.1.0

DTV Multicast

la série « alice nevers, le juge est une femme

DISNEYLAND PARIS - PROMO PARC ASTERIX

Licence Informatique et IUP GMI

UDcast exposera au Narrowcast 2002 (Content, Streaming