[sdnog] ipsec

[Patrick Okui]

Hi Netro,

On 23 Jan 2017, at 21:30 EAT, netro elsh wrote:

> greating
>
> i wanna ask the difference between ipsec over GRE and GRE over ipsec 
> and when i have to use ipsec over GRE


The first question is what is GRE and what is IPSEC and their 
differences.

- IPSEC is a set of protocols that encrypt and authenticate IP 
communications between two end points on the internet. If these 
endpoints are routers then you have a typical VPN setup. The hosts 
behind each can use the encrypted link for their packets.

- GRE is a Cisco authored simple tunnelling protocol that can 
encapsulate any IP packet with a separate IP and GRE header to be sent 
over the Internet then decapsulated by the receiver to reveal the 
original IP header.

Two main differences:

- The data inside GRE tunnels is not encrypted. Someone with tcpdump or 
wireshark between source and destination can see the original IP header 
and the rest of the data in the packet whereas with IPSEC you can’t 
see the contents of the packets. Depending on the IPSEC mode at best 
you’ll see the IP header, but you can’t change it without IPSEC 
noticing.

- Because IPSEC works end-to-end (a bit like say SSL in HTTPS) for the 
crypto part, it can not carry multicast traffic for example, whereas GRE 
can.

Now. With a GRE tunnel up between two routers, you theoretically could 
create an IPSEC session between two hosts on either side of the tunnel. 
This would not secure the tunnel; just the communication between said 
hosts and would not require extra configuration on the routers that form 
the GRE tunnel, just on the hosts on either side (which can also be 
routers ….).

However, if you are trying to secure the GRE tunnel itself on the 
routers that are the end points and you add IPSEC to it, there’s no 
GRE over IPSEC or IPSEC over GRE per se. The two protocols remain 
playing the same role.

The only difference is in the IPSEC mode you pick. IPSEC can run in a 
“tunnel mode” (the default) or “transport mode”.

- In tunnel mode, everything is encrypted, headers and all and as such 
it can traverse say a NAT device and a new IP header (with source and 
destination) is added to the packet. This for example allows for NAT 
traversal.

- In transport mode, IPSec only encrypts the payload. The original IP 
header which has source/destination data (in this case the GRE header) 
is left untouched and only the contents are encrypted. IPSEC has 
optional authentication of the packet to detect if the entire (layer 3 
or IP) packet changed between source and destination. If this is used 
(and if you’re using IPSEC it’s strongly recommended that you do 
this) then if this GRE packet traverses a NAT device, IPSEC on the other 
side will reject the packet as having been tampered with. There are 
standards to solve this use case but I haven’t checked if you can 
apply them to this use case.

So, with GRE, to recap, you can use the IPSEC tunnel mode (the GRE 
header is also encrypted) or transport mode (the GRE payload only is 
encrypted).

Encrypting the entire packet means it uses extra bytes for tunnel mode 
(for each packet) and less for transport mode. We’re talking about 20 
bytes per IPv4 packet difference.

If you’re using a link in the tens of kilobits per second range of 
speed for this (e.g a 64 kbps link or smaller telecoms TDM link), then 
the 20 bytes on each packet adds up. If your link is in the megabits per 
second then you’re likely not to notice the “savings”. In either 
case, you wouldn’t see much CPU difference.

So, your main practical differences are whether the original header can 
be seen and the 20 bytes difference in added headers. This is due to the 
way IPSEC works but not because you are layering IPSEC and GRE 
differently.

Hope this is clear.

--
patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sdnog.sd/pipermail/sdnog/attachments/20170128/14b2b223/attachment.html>