Transport mode and GRE tunnel

[lephuc007]

Dear Sir/Madam,

I understand that using transport mode does not encrypt the IP header, but only the payload. Is that's why it is recommend to incorporate GRE tunnel with transport mode to enhance security? Can you please explain how. Please see url below.

             For example, DSD recommend to use Control 0495 at http://www.dsd.gov.au/publications/Information_Security_Manual_2012_Controls.pdf.

             Can someone kindly explain why?

[Peter Paluch · Accepted solution]

Hello,

GRE has absolutely no impact on security - it is itself an unprotected tunneling protocol that does not protect the tunneled data in any way. GRE is often combined with IPsec because of two main reasons: it is capable of tunneling any protocol within an IP-based tunnel, and is capably of carrying multicast traffic. IPsec alone supports only unicast IP traffic. Therefore, if different types of traffic are to be carried over an IPsec tunnel, they are first GRE-encapsulated (thereby putting the passenger protocol into a unicast IP header+GRE header) and then protected using IPsec. Note that here, I am talking about a specific sequence of operations: first, GRE, then, IPsec.

The Control 0495 says, in particular: "Agencies choosing to use transport mode should additionally use an IP tunnel for IPsec connections." As you have pointed out, in the transport mode, the IP header of the original packet is retained and is not encrypted. The original header can be "obfuscated" by putting the entire IPsec datagram in an additional GRE tunnel tunnel, assuming that the device performing the GRE tunneling is different from the IPsec endpoints. However, this does not really protect the original header, just makes it a payload of the GRE packet - however, it is not encrypted and deep packet inspection would easily reveal all the details. I therefore assume that the Control 0495 only tries to hide the original IP header from basic router and firewall implementations. Note that here, the sequence of operations is different: first, IPsec, then, GRE.

I would say that the real benefit of Control 0495 is somewhat questionable.

Please feel welcome to ask further!

Best regards,

Peter

[lephuc007]

Dear Peter,

I appreciated your quick response and thank you very much.

What happens when the same scenario above is implemted with DMVPN:

          1. does it change the sequence of operations: first IPSEC, then, GRE: then NBMA ? Is this order correct?

          2. does the GRE packet now becomes the payload of the NBMA packet, therefore it gets encrypted, and a new IP header contains the NBMA src ipaddress and dst ipaddress is added to the front of the GRE packet. Does this scenario now protects the original header?

Thank you kindly Peter

Regards

Phuc Le

[lephuc007]

Dear Peter,

I am not sure because I marked your answer as Correct, does that mean this question is closed.

Apologies, I am new to this tool.

You've gave an awesome answer as it was detailed and informative. So thank you very much

I have another follow up question:

What happens when the same scenario above is implemented with DMVPN:

     1. does it change the sequence of operations: first IPSEC, then, GRE, then NBMA ? Is this order correct?

     1. does the GRE packet now becomes the payload of the NBMA packet, therefore it gets encrypted, and new a IP header contains the NBMA src ipaddress and dst ipaddress is added to the front of the GRE packet. Does this scenario now protects the original header?

Thank you kindly Peter

Regards

Phuc Le

[Peter Paluch · Accepted solution]

Hello Phuc,

You are welcome! Regarding marking the answer as correct: on this forum, there is really no concept of a "closed" thread. Marking the answer as "correct" means that you consider the answer to be a complete solution to your problem, and the thread will be visibly indicated to include a solution (a green tick and a description of "Answered"). However, you can always post new questions to such thread and anyone can further answer the additional questions, and you may mark any number of answers as also being "correct".

What happens when the same scenario above is implemented with DMVPN:

The DMVPN order of operations is first GRE, then IPsec.

does the GRE packet now becomes the payload of the NBMA packet,  therefore it gets encrypted, and new a IP header contains the NBMA src  ipaddress and dst ipaddress is added to the front of the GRE packet.  Does this scenario now protects the original header?

Yes, this would be a correct description. I have seen the DMVPN being implemented typically in IPsec tunnel mode (as opposed  to transport mode). The encapsulation order then looks like this:

1. Original header | Payload - this is the packet as sent by a computer inside a DMVPN site

2. Outer header | GRE | Original header | Payload - this is the packet immediately after GRE encapsulation)

3. Outer header | ESP | Encrypt(Outer header | GRE | Original header | Payload) - this is the IPsec protected packet

Note that there are in fact three IP headers here, with one IP header basically duplicating itself because both GRE encapsulation and IPsec tunnel mode always add a new IP header, even though the addressing is identical (because both tunneling mechanisms are typically performed on a single node). However, the original IP header is protected.

In IPsec transport mode, the order of operations looks as follows:

1. Original header | Payload - this is the packet as sent by a computer inside a DMVPN site

2. Outer header | GRE | Original header | Payload - this is the packet immediately after GRE encapsulation)

3. Outer header | ESP | Encrypt(GRE | Original header | Payload) - this is the IPsec protected packet

Here, the IPsec does not add a new IP header and instead it reuses the outer IP header as added in the second stage. The original IP header is still protected, though.

Please feel welcome to ask further!

Best regards,

Peter

[lephuc007]

Dear Peter,

You've again answered my question promptly and exceeded my expectation.

I like the fact you took time to give a very detailed explanation, which helped me to understand now.

So thank you very much.

So in summary, when transport mode is coupled with GRE in an  DMVPN implementation, then the original header is encrypted. Whereas if transport mode is used with GRE in a native IPSec, then the original header is obfuscated, thus deeply hidden away, but not encrypted.

I understand that the reason why Transport mode is preferred over Tunnel mode in DMVPN is because it reduces overhead, thus saving 20 bytes over Tunnel mode. Is this a understanding correct.

Have a nice weekend

Thank you very much Peter.

Regards

Phuc   

[Peter Paluch · Accepted solution]

Hello Phuc,

So in summary, when transport mode is coupled with GRE in an  DMVPN implementation, then the original header is encrypted.

Yes, that is correct. In DMVPN, the order of operation is always GRE first, IPsec second.

Whereas if transport mode is used with GRE in a native IPSec, then the  original header is obfuscated, thus deeply hidden away, but not  encrypted.

This is not that clear because the order of operations is not clear from this short description.

If speaking about GRE over IPsec IPsec over GRE then the order is IPsec first, GRE second. This order will result in these operations:

1.) Original header | Payload ! before IPsec

2.) Original header | ESP | Encrypt ( Payload ) ! after IPsec in transport mode

3.) Outer header | GRE | Original header | ESP | Encrypt ( Payload ) ! after GRE

Here, the original header is obfuscated but not encrypted.

If speaking about IPsec over GRE GRE over IPsec then the order is GRE first, IPsec second. The order will be:

1.) Original header | Payload ! before GRE

2.) Outer header | GRE | Original header | Payload ! after GRE

3.) Outer header | ESP | Encrypt ( GRE | Original header | Payload ) ! after IPsec transport mode

Here the original header is encrypted.

Best regards,

Peter

EDIT: Thanks to berney! He spotted the wrong order of operations in my original version of this post. Correcting now. See berney's comment at

https://supportforums.cisco.com/message/3865700#3865700

[lephuc007]

Dear Peter,

Thank you very much for your time and efforts in assisting me to understand this topic.

Your contribution is greatly appreciated.

It makes sense logically for each respective scenario

I am from Australia. Were are you based?

Regards

Phuc Le

[Peter Paluch · Accepted solution]

Hello Phuc,

You are very much welcome!

I am from Australia. Were are you based?

On the opposite hemisphere, in Slovakia, Central Europe.

Best regards,

Peter

[lephuc007]

Dear Peter,

I would like to say happy new year.

Regards

Phuc

[fengzhong]

Hi Peter,

Please correct me if I am wrong,

1. but why I feel that in how the packets encrypted, it should be this way:

GRE over IPSec:

1.) Original header | Payload ! before GRE

2.) Outer header | GRE | Original header | Payload ! after GRE

3.) Outer header | ESP | Encrypt ( GRE | Original header | Payload ) ! after IPsec transport mode

IPSec over GRE:

1.) Original header | Payload ! before IPsec

2.) Original header | ESP | Encrypt ( Payload ) ! after IPsec in transport mode

3.) Outer header | GRE | Original header | ESP | Encrypt ( Payload ) ! after GRE

2. Do you mind to share in which senario we should use GRE over IPsec, and which senario we should use IPsec over GRE?

Please advise,

Thanks.

berney

[Peter Paluch]

Hello Berney,

1. but why I feel that in how the packets encrypted, it should be this way:
GRE over IPSec: 
1.) Original header | Payload ! before GRE
2.) Outer header | GRE | Original header | Payload ! after GRE
3.) Outer header | ESP | Encrypt ( GRE | Original header | Payload ) ! after IPsec transport mode
IPSec over GRE:
1.) Original header | Payload ! before IPsec
2.) Original header | ESP | Encrypt ( Payload ) ! after IPsec in transport mode
3.) Outer header | GRE | Original header | ESP | Encrypt ( Payload ) ! after GRE

Yeah, yes, you are correct here. I must have been tired or brain-dead or something when explaining those pesky what-over-what combinations. Good catch! Rated as deserved, and I am correcting my previous post so that no one else will get confused.

2. Do you  mind to share in which senario we should use GRE over IPsec, and which  senario we should use IPsec over GRE?

To be honest, I have never seen IPsec-over-GRE. I do not think that this combination is particularly useful because IPsec by itself is capable of carrying IPv4/IPv6 traffic only, and encapsulating the resulting IPsec datagram into a GRE packet provides no additional functionality, apart from possibly hiding the original IP header beneath a new IP header. When talking about IPsec and GRE cooperation, I always think in terms of GRE-over-IPsec tunnels.

Best regards,

Peter