The original IP header of the IPSec protocol in the tunnel mode

Unanswered Question
May 3rd, 2010
User Badges:

Hi;

The structure of the IP header may be a 5 words of 32 bits including the following fields:

-         Version (4bits) , IHL (4bits) , TOS (8 bits), Total length(16 bits)

-         Identification (16 fields), flags(3 bits) , fragment offset ( 13 bits)

-         TTL (8 bits ) , Protocol (8 bits) , Header checksum (16 bits)

-         Source Address (32 bits)

-         Destination Address ( 32 bits)

-         Options + Padding (32 bits)

When IP Security is applied in the tunnel mode, the network packet (including the original IP header) is encapsulated by ESP or AH  headers and a new IP header is inserted as an outer header ; So:

Q1: The inner IP address of the inner (original) IP header  becomes unknown.. By which sense that it becomes unknown? 

Is it encrypted or became hidden (by the meaning that if the traffic is captured ; it wouldn't appear)?

Q2: What are the effects of encapsulating the inner (original) IP header with ESP or AH headers on each field of its structure in the way of encryption or being hidden?

I'm waiting for answers

Best Regards.

Rose

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jon Marshall Mon, 05/03/2010 - 15:02
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

rose_smile33 wrote:


Hi;


Q1: The inner IP address of the inner (original) IP header  becomes unknown.. By which sense that it becomes unknown? 

Is it encrypted or became hidden (by the meaning that if the traffic is captured ; it wouldn't appear)?

Q2: What are the effects of encapsulating the inner (original) IP header with ESP or AH headers on each field of its structure in the way of encryption or being hidden?

I'm waiting for answers

Best Regards.

Rose


Q1 - Its hidden in the sense that all the intermediate devices along the path do not see this IP header so the IPs, options, QOS markings etc. in the original IP header is not visible to the intermediate routers. Yes it is encrypted.


Q2  - Not sure what you mean. It is encrypted along with the data in the original packet.


Jon

rose_smile33 Tue, 05/04/2010 - 13:00
User Badges:

Hi Jon;

 

You answered : "Q2  - Not sure what you mean. It is encrypted along with the data in the original packet."

 

I mean that if i captured the IPsec traffic in tunnel mode by a capture tool ; 

 

1- Could i see any of the inner IP header fields but in an encrypted way?

 

Or  

 

2-- Would The inner IP Hedear be hidden as a hole or some of its fields would be hidden?

 

3- Would the (identification , MF, DF and fragment offset ) fields of the inner IP Header be appeared  in the captured traffic as encrypted and /or hidden)?

 

4- Would any of the ESP header fields appear in the captured traffic?

 

Thanks for interest

 

  Rose

 

rose_smile33 Sun, 05/09/2010 - 08:50
User Badges:

HI;


Can any body answer my above questions , Please !


  It was since 4 May.



    Rose

Federico Coto F... Sun, 05/09/2010 - 09:25
User Badges:
  • Green, 3000 points or more

Rose,


In transport mode:
The data portion of the IP packet and the ESP header is authenticated and only the data portion of the IP packet is encrypted by ESP


In tunnel mode:
The entire IP packet (including the IP header) is encrypted and only the ESP header is authenticated.


So, yo answer your questions:


In transport mode, the IP payload is encrypted and the original headers are left intact. The ESP header is inserted after the IP
header and before the upper-layer protocol header.


When used in tunnel mode, the original IP header is protected because the entire IP packet is encrypted.


In short,
If you capture packets when using ESP in transport mode, only the original IP packet data portion is encrypted.
If you capture packets when using ESP in tunnel mode, you can't see the original IP header because it is encrypted.

Hope to answer your questions.


Federico.

rose_smile33 Sun, 05/16/2010 - 10:57
User Badges:

Hi  Federico;


You said: "In tunnel mode:
The entire IP packet (including the IP header) is encrypted and only the ESP header is authenticated."


; "When used in tunnel mode, the original IP header is protected because the entire IP packet is encrypted."


and "If you capture packets when using ESP in tunnel mode, you can't see the original IP header because it is encrypted"


To clear the misconception :


1- What are the difference between the IPsec VPN pre-fragment and post fragment packets in the following fields of the original IP header (Identification , fragment offset, MF and Df ) in the aspects of being encrypted or being hidden if we captured each of them?


2- Could you send to me the packet format structure for IPSEC VPN Pre-fragment and post fragment packets showing the difference, Please!


3- Do you know any simulation or anlysis tool that could help to implement and study that !


It's very important to my research ; Please.


      Rose

Federico Coto F... Sun, 05/16/2010 - 11:22
User Badges:
  • Green, 3000 points or more

Rose,


Normally if fragmentation is required, you want to do it before encryption.
This is because the receiving VPN endpoint will decrypt the traffic and send it's final destination without need to reassembly.
You want the reassembly work to be done by the computers or end devices.


If you enable fragmentation after encryption, then the receiving VPN endpoint will have to reassemble the packets before decryption,
and that's CPU consuming and demanding (imagine a lot of VPN tunnels)


To answer your questions,
I will suggest to establish a VPN connection with your VPN client and sniff the packets with Wireshark.
With Wireshark, make sure the NPF (WinPcap) is running and filter to check the ISAKMP and ESP packets.
This will give you lots of information on the packets on all levels of the OSI stack.


Federico.

rose_smile33 Sun, 05/23/2010 - 11:43
User Badges:

Hi Federico and Everybody;


1- Does Pre-fragmentation depend on the fragmentation fields of the original IP header while post fragmentation depend on the fragmentation fields of the outer IP header?


2- About your suggestion: " to establish a VPN connection with your VPN client and sniff the packets with Wireshark.
With Wireshark, make sure the NPF (WinPcap) is running and filter to check the ISAKMP and ESP packets.
This will give you lots of information on the packets on all levels of the OSI stack."


A- How could i establish that while i don't have a real router in my lab to apply pre-fragmentation!


B- What is the VPN client ? Could the implementation be between two servers?


C- What is the NPF (WinPcap)?


D- What are the network performance parameters that are affected due to Pre- and Post-fragmentation and How?


* How could i implement and measure that?

 

* Could you guide me to any lab or simulator/tool or steps to do that?


Thanks



  Rose 

Federico Coto F... Sun, 05/23/2010 - 21:33
User Badges:
  • Green, 3000 points or more

Rose,


I'm not 100% sure about your first question, but I will say that you're correct.
Pre-fragmentation depends on the original IP header because that's the only IP header we are dealing with at this point.
Post-fragmentation depends on the outer IP header, because the original IP header is already encrypted and we're relying on the
outer IP header to route the packet to its destination.


2.A. If you cannot create a VPN connection from your machine to an existing router somewhere, you can try using GNS3.
www.gns3.net


2.B. VPN client is the Cisco IPsec VPN software client that you install on your machine to create a VPN.
http://www.cisco.com/en/US/products/sw/secursw/ps2308/index.html


2.C. The NPF is a driver that must be running when capturing packets with Wireshark. It comes with WinPcap which is used by Wireshark.
www.wireshark.org


2.D. If you create an IPsec tunnel between two routers, and you enable post-fragmentation, this means that the traffic will be
encrypted by the router and fragmented afterwards (if needed). This also means that the receiving router will have to reassemble the
packets before being able to decrypt them (this is unneccesary load on the receiving router).
If on the other hand you enable pre-fragmentation on the same scenario, this means that the packets will be fragmented (if needed)
before encryption and the receiving router will never have to reassemble the packets. The receiving router will just decrypt the
packets and will send the traffic to the destination hosts. (this hosts will reassemble the data as needed).


Hope it helps.


Federico.

rose_smile33 Wed, 05/26/2010 - 15:04
User Badges:

Thank you Federico for your help;


I would try to implement it for my research study but i have some questions:


1- What are the network performance parameters that are affected due to IPsec Pre- and Post-fragmentation and How they are affected in each case?


2- Which is better to simulate and measure IPsec Pre- fragmentation effects onthe network performance (Gns3, Opnet modeler ,iperf or others) ?


3-- Could you guide me to any lab tutorials or guide steps to implement and measure that in any simulator?



Thanks a lot.



  Rose

Federico Coto F... Thu, 05/27/2010 - 09:23
User Badges:
  • Green, 3000 points or more

Rose,


You're making me study as well :-)


1. I'm not sure I understand what you need here, please explain.


2. To be honest of those you listed I've only used GNS3. Perhaps somebody else might have some comments on this....


3. I''ll suggest this links:


An Introduction to IP Security (IPSec) Encryption

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_tech_note09186a0080094203.shtml


Cisco IOS Security Configuration Guide: Secure Connectivity, Release 12.4

http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/12_4/sec_secure_connectivity_12_4_book.html


Do a search for configuring IPsec site to site between routers and you'' find plenty examples to set up in GNS3 or another program.


Federico.

Actions

This Discussion