09-02-2013 05:18 AM
Hi,
I really don't understand why GET VPN uses a tunnel mode for multicast packets :
Examples for an @multicast = 239.0.0.37 :
1 ) here a GET VPN packet : |239.0.0.37|ESP|239.0.0.37|transport layer|Payload| : This mean, it uses the tunnel mode of IPsec (two IP headers).
2 ) here a packet that i imagine to be better : |239.0.0.37|ESP|transport layer|Payload| : IPsec transport mode, 1 IP header saved = less bytes used.
In both case, IP header can't be secured, cause GET VPN tunneling use the same IP header for multicast (that's why it works so well...)
I dont understand why Cisco uses IPsec tunnel mode model to encapsulate packets instead of transport mode. I can't find a descent answer to this question... Maybe my question isn't pertinent ?
Thanks for your answers.
Regards
Solved! Go to Solution.
09-02-2013 05:57 AM
Pierre,
I'll quote the DIG
It is worth noting that tunnel header preservation seems very similar to IPsec transport mode.
However, the underlying IPsec mode of operation with GET VPN is IPsec tunnel mode. While
IPsec transport mode reuses the original IP header and therefore adds less overhead to an IP
packet (5% for IMIX packets; 1% for 1400-byte packets), IPsec transport mode suffers from
fragmentation and reassembly limitations when used together with Tunnel Header Preservation
and must not be used in GET VPN deployments where encrypted or clear packets might require
fragmentation.
In practice, reassambly concerns and initially odd behaviors with some encryption engines caused the recommendation to be tunnel mode.
That being said, for big packets (where overhead would matter) the overhead is minimal. For small packets (voice) the overhead is big, but the packet size (after encapsulation) should not be a problem.
M.
09-02-2013 05:57 AM
Pierre,
I'll quote the DIG
It is worth noting that tunnel header preservation seems very similar to IPsec transport mode.
However, the underlying IPsec mode of operation with GET VPN is IPsec tunnel mode. While
IPsec transport mode reuses the original IP header and therefore adds less overhead to an IP
packet (5% for IMIX packets; 1% for 1400-byte packets), IPsec transport mode suffers from
fragmentation and reassembly limitations when used together with Tunnel Header Preservation
and must not be used in GET VPN deployments where encrypted or clear packets might require
fragmentation.
In practice, reassambly concerns and initially odd behaviors with some encryption engines caused the recommendation to be tunnel mode.
That being said, for big packets (where overhead would matter) the overhead is minimal. For small packets (voice) the overhead is big, but the packet size (after encapsulation) should not be a problem.
M.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: