GET VPN multicast tunnel mode and transport mode

[supercolver]

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

[Marcin Latosiewicz · Accepted solution]

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.