Publicado el 8 de Mayo del 2017
670 visualizaciones desde el 8 de Mayo del 2017
312,1 KB
15 paginas
Creado hace 12a (01/04/2013)
SAVI:
Validación
de
direcciones
Marcelo
Bagnulo
Foro
de
seguridad
de
RedIRIS
Abril
2013
Universidad
Carlos
III
de
Madrid
Mo@vación
• Las
mo@vaciones
de
quienes
generan
paquetes
con
direcciones
falsas
son,
en
su
mayoría,
no
muy
puras.
– Ocultar
la
procedencia
de
los
ataques
– Obtener
acceso
restringido
a
ciertas
direcciones
– Hacerse
pasar
por
otro
disposi@vo
• Es
deseable
evitar
la
falsificación
de
direcciones
Técnicas
usadas
• Filtros
de
ingreso
(BCP38)
– Granularidad
a
nivel
de
prefijo
– Puede
u@lizar
información
de
ruteo
– Limitación:
granularidad
a
nivel
de
prefijo
Obje@vos
de
SAVI
• Obje@vo:
validar
direcciones
con
una
granularidad
de
direcciones
individuales
– Aquellos
paquetes
con
direcciones
falsas
de
descartan
– Configuración
automá@ca
de
los
filtros/configuración
• Sólo
el
disposi@vo
que
es
dueño
de
la
dirección
manual
mínima
puede
enviar
paquetes
con
esta
– Pero,
¿cómo
sabemos
quién
es
dueño
de
qué
dirección?
• Depende
fuertemente
del
mecanismo
de
asignación
de
direcciones
usado
Elementos
de
SAVI
• Filtrado
• Creación
de
bindings
Filtrado
SAVI
falsas
son
filtrados
• Idea
básica:
los
paquetes
que
@enen
direcciones
• ¿Cómo
sabemos
que
una
dirección
es
falsa?
• Tabla
de
bindings:
asociaciones
entre
direcciones
y
binding
anchors
– Binding
anchor:
propiedad
verificable
en
el
paquete
• Topología
SAVI:
Más
cerca
esté
el
disposi@vo
SAVI
di_cil
de
falsificar,
e.g.
Puerto
del
switch
del
nodo
final,
mayor
protección.
– Caso
ideal:
SAVI
en
los
switches
Perímetro
de
protección
SAVI
enforcement
perimeter
for
link
1
Router
Filtering
rules
for
external
traffic
SAVI
enforcement
perimeter
for
link
2
SAVI
switch
SAVI
switch
Legacy
switch
SAVI
switch
SAVI
switch
Legacy
switch
Trusted
port
Valida@ng
port
Creación
de
bindings
bindings,
¿cómo
poblamos
la
tabla?
• El
filtrado
asume
la
existencia
de
una
tabla
de
• Los
bindings
asocian
una
dirección
a
un
binding
anchor
que
pertenece
al
dueño
de
la
dirección
• ¿Cómo
saber
quién
es
el
dueño
de
la
dirección?
• Sabores
de
SAVI:
– En
función
de
la
configuración
de
la
misma
– SAVI
FCFS
– SAVI
DHCP
– SAVI
SEND
SAVI
FCFS
• Usado
con
direcciones
IPv6
autoconfiguradas
(SLAAC)
• El
criterio
para
la
propiedad
es
FCFS
• El
disposi@vo
SAVI
inspecciona
los
mensajes
de
ND
para
crear
los
bindings
– DAD
SAVI
FCFS
N
N
B1
creates
temporary
entry
for
A
and
starts
Tenta’ve
State
@mer
Binding
database
A
-‐>
port
#1,
TENTATIVE
…
N
generates
DAD_NS(A)
B 1
f o r w a r d s
D A D _ N S ( A )
t o
o t h e r
t c h e s
s w i
B1
B2
B3
Tenta’ve
State
@mer
associated
with
A
expires,
entry
changes
to
forwarding
state
Binding
database
A
-‐>
port
#1,
VALID
…
B1
B2
B3
SAVI
DHCP
• Se
usa
para
direcciones
IPv4
y
IPv6
configuradas
vía
DHCP
• El
criterio
de
propiedad
es
lo
que
digan
los
mensajes
DHCP
SAVI
DHCP
SAVI
SEND
• Es
válido
para
direcciones
CGAs
• La
propiedad
de
las
direcciones
viene
dada
por
la
propiedad
de
la
clave
privada
• U@liza
el
protocolo
SEND
para
verificar
la
propiedad
de
la
clave
privada
Comentarios
finales
• SAVI
provee
protección
contra
la
falsificación
de
direcciones.
• 3
sabores
de
SAVI
– SAVI
FCFS
– SAVI
DHCP
– SAVI
SEND
Referencias
• E.
Nordmark,
M.
Bagnulo,
E.
Levy-‐Abegnoli.
“FCFS
SAVI:
First-‐Come
First-‐Serve
Source-‐Address
Valida@on
for
Locally
Assigned
IPv6
Addresses”,
IETF
RFC
6620.
May
2012.
• J.
Bi,
J.
Wu,
G.
Yao,
F.
Baker.
“SAVI
Solu@on
for
DHCP”.
• M.
Bagnulo,
A.
Garcia-‐Mar@nez.
SEND-‐based
Source-‐
draq-‐ier-‐savi-‐dhcp-‐11.txt.
December
2011.
Address
Valida@on
Implementa@on.
draq-‐ier-‐savi-‐
send-‐07.
March
2012.
• SAVI:
The
IETF
Standard
in
Address
Valida@on.
Marcelo
Bagnulo,
Alberto
García-‐Martnez.
IEEE
Communica@ons
Magazine,
abril
2013.
Comentarios de: SAVI: Validación de direcciones (0)
No hay comentarios