Newsgroup: it.comp.reti.cisco
Titolo: Voice-over-IP e VPN/3des

Qualcuno ha già sperimentato del Voice-over-IP attraverso una
connessione VPN con 3DES?
Mi trovo in questa situazione: bridge WireLess tra 2 LAN; devo
proteggermi BENE, quindi pensavo di fare VPN tra le 2 LAN sui
router(*), attivare WAP o WPA sulla tratta radio e di crittografare la
VPN. E fin qui tutto OK.
Però devo anche far transitare la voce, che configurerò sui router nel
solito modo già sperimentato (Multilink, CB-WFQ, LLQ, LFI, ecc.).
Il dubbio adesso è: che impatto avrà il trattamento di crittografia
sui pacchetti voce? Ovvero: quanto degraderà la qualità? Riesco a
configurare i router in modo da crittografare solo i dati "non-voce"?
NOTA (*): devo usare dei router perchè ho delle unità che dialogano in
SDLC sulla seriale ...

 configurare i router in modo da crittografare solo i dati "non-voce"?
beh...la qualità è l'unica cosa che non dovrebbe degradare ;-)
Mi spiego meglio...nelle ultime release IOS (diciamo dalla 12.2(11)T) e'
possibile creare dei tunnel IPSec in cui il TOS viene ricopiato nell'header
del pacchetto criptato. Quindi al pachetto criptato puoi applicare i
meccanismi di QoS che citi nella mail (come il CBWFQ).
I problemi nel criptare la voce sono soprattutto di aumento di banda
occupata e di ritardo. La banda soprattutto ne risente parecchio...considera
che i pacchetti voce sono molto piccoli e numerosi, e l'header IPSec e'
decisamente grande. Spannometricamente (!) una chiamata in G.729 puo'
passare da circa 20kbps a 50-60kbps, mentre una in G.711 da 80kbps a
150kbps.
Poi c'e' il ritardo dovuto alla crittografia. Ti consiglio vivamente di
utilizzare un modulo di enc hardware per limitare al massimo il ritardo
introdotto (al max il ritardo per la voce deve essere di circa 150ms).
Infine una soluzione puoì essere quella di non criptare la voce. Questa è la
soluzione piu' semplice, a patto che il traffico voce sia facilmente
distinguibile dal resto del traffico...
Ciao
Marco

 > configurare i router in modo da crittografare solo i dati "non-voce"?
Mi sono dimenticato....dai un'occhiata qui:
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns241/c649/ccmigrati
on_09186a0080146c8e.pdf
o qui:
www.cisco.com/go/v3pn
Ciao
marco

 connessione VPN con 3DES? ................
parti da qui: 
http://cisco.com/go/v3pn
~mm

ciao,
credo che i problemi che incontrerai saranno perlopiù legati alle risorse hw
dei tuoi router, che dovranno cifrare potenzialmente a circa 6 Mbps, cioè il
throughput reale del link radio.
A meno che tu non abbia dei router di fascia molto alta, sarai costretto ad
utilizzare i moduli per l'encryption HW.
Infatti anche implementando il QoS nel modo opportuno, e questo andrà fatto
indipendentemente che tu cifri o no la voce, quando la CPU del router sarà
utilizzata pesantemente i meccanismi di QoS cominceranno a 'zoppicare' e
l'effetto sarà uno spezzettamento della voce.
Ti consiglio cmq di non cifrare il traffico voce, lavorando sulle crypto
acl,  e di implementare un QoS di tipo CBWFQ combinato al LLQ, in questo
caso non dovresti avere problemi a riconoscere il traffico fonia.
Se invece cifri anche la voce ti consiglio le ultime versioni di IOS,
12.2.15T o 12.3, con le funzionalità di 'QoS for VPN', che con il comando
'qos pre-classify' permettono di prioritizzare prima dell'incapsulamento.
Un'altra possibilità sarebbe quella di cifrare con IPsec in modalità
'transporto'.
ciao
Andrea
"Claudio" <claudio...@DeltaDator.it> ha scritto nel messaggio
news:2a599004.0311...@posting.google.com...


 
Grazie delle indicazioni.
In effetti io NON vorrei proprio criptare la voce, sia per i ritardi
aggiuntivi introdotti, sia per l'aumento di banda.
Un'idea sulle ACL da utilizzare e dove applicarle?
Io utilizzo proprio in CBWFQ e LLQ:
--------------------
class-map CL_LOW
  match access-group 130
class-map VOCE
  match access-group 120
class-map CL_HIGH
  match access-group 110
!
policy-map POL_GLOBAL
  class VOCE
    priority 30
  class CL_HIGH
   bandwidth percent 50
  class CL_LOW
   bandwidth percent 8
!
(..)
!
interface Multilink1
 description collegamento 128K con Molina
 bandwidth 128
 ip address 10.127.126.22 255.255.255.252
 ip tcp header-compression iphc-format
 no ip mroute-cache
 service-policy output POL_GLOBAL
 no cdp enable
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave
 multilink-group 1
 ip rtp header-compression iphc-format
!
(...)
!
interface Serial0/1
 description "CDN 64K con Molina di Ledro"
 bandwidth 128
 no ip address
 encapsulation ppp
 no fair-queue
 no cdp enable
 ppp multilink
 multilink-group 1
!
-----------------------
E come cifro con modalita "transport"?
Ri-grazie

ciao Claudio,
la configurazione che hai postato va rivista, infatti non potrai senz'altro
utilizzare il Multilink perche stai lavorando con delle interfacce Ethernet.
Non ti sto a postare una config. completa mi ci vorrebbe un pò troppo tempo,
ma ti riassumo i punti principali:
1) configura la parte VPN IPsec, applicando le 'crypto-map' interfacce
Ethetnet veso i link radio.
Quest'esempio ti potrà aiutare ommettendo la parte NAT:
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_examp
le09186a0080094634.shtml
Nelle crypto acl, metti un 'deny' come prima riga per il traffico voce e
questo dipende da come hai implementato la voce.
Se vuoi cifrare in modalità trasporto, dopo aver impostato i 'crypto ipsec
transport-set' utlizza il comando 'mode transport'.
2) definisci le class-map e le policy-map un pò come nella config che hai
postato tu, io ti consiglio però di utilizzare solo una class-map per il
solo traffico voce e la class-map default in fair-queueing per il resto del
traffico, ecco un esempio:
 class-map match-all voce
  match access-group 130
!
 policy-map uscente
  class voce
   priority xx
  class class-default
   fair-queue
access-list 130 remark TRAFFICO VOCE
access-list 130 permit ip host 'IP voce sorgente' host 'IP VOCE
destinazione'
e finalmente di applicare all'interfacca Ethernet verso il link radio il
comando 'service-policy output uscente'
3) ti consiglio inoltre di valutare le reali prestazioni del link radio,
misurando il throughput effettivo e d'implementare delle funzionalità di
traffic shapping, cioè di limitazione della trasmissione sui router,
altrimenti il QoS potrebbe cmq diventare inefficace.
ciao
Andrea G.
"Claudio" <claudio...@DeltaDator.it> ha scritto nel messaggio
news:2a599004.03112...@posting.google.com...
