Pre-fragmentation and Link fragmentation and Interleaving questions

[rose_smile33]

I'm going to study two features on security and network performance,  which are:

1- Pre-fragmentation (look ahead fragmentation)

2- Link fragmentation and Interleaving

I have some questions that need your help to answer the following:

> 1- Which cisco  series supports the two features?

> 2- Does Cisco 7206 IP router support any of these features?

> 3- How links and other devices which are not support pre-fragmentation would deal with the pre-fragmented IPsec  traffic?

> 4- Are there any difference between Cisco 7206 IP router and Cisco 7206 VXR?

> 5- I would going to simulate a network to study the above features. Could you have any support ( Ex:Disscus with you and experts the network model suggestions , features parameters and protocols' configurations, affects on performance and others)!

[Laurent Aubert]

Hi,

> 1- Which cisco  series supports the two features?

You can use the feature navigator to find this kind of information:  http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp

> 2- Does Cisco 7206 IP router support any of these features?

It may depend of the version you're running.

> 3- How links and other devices which are not support pre-fragmentation would deal with the pre-fragmented IPsec  traffic?

The router will decrypt each IP fragment an send them to their destination. Routers in the middle will just route them as usual

> 4- Are there any difference between Cisco 7206 IP router and Cisco 7206 VXR?

No, the only model is 7206VXR

> 5- I would going to simulate a network to study the above features. Could you have any support ( Ex:Disscus with you and experts the network model suggestions , features parameters and protocols' configurations, affects on performance and others)!

Just post your question and the community will try to help you. Also anything related to performance and roadmap should be handled by your acount team.

HTH

Laurent.

[rose_smile33]

Hi Everybody;

For Pre-fragmentation of IPsec VPNs:

If we assume the following case study: If there are two lans (subnets) in different countries each contains a host server (as an end point) connected to a router through which it connect to an Internet cloud to the other subnet, If I want the information between the two end hosts to path within an IPsec VPN tunnel and I want pre-fragmentation to be occurred. I have some questions:

1-     I would configure the IPsec parameters at each router in each subnet; Would this be suffiecient  to establish an IPsec tunnel between the two end hosts and would the end host be capable of reassembly the pre-fragmented packets without configuring IPsec parameters at each end host(Which is a server)?

2-     In each router; there are a lot of interfaces like: Physical interfaces; Aggregate Interfaces ( I don't know what are these) ; Tunnel interfaces and Vlan interfaces .

What are the interfaces that I have to configure for IPsec ,VPN and Pre-fragmentation and what are the parameters that I have to configure for each of them?

3-     Under the IKE Policies; to configure the authentication key ;

I -If I choose the configured option ; Would this mean that it would be established as a pre-shared key (which is not scalable well) or what's that mean?

II - If I choose the option of using CA:

A- Does this mean that I need a 3^rd parity to establish certificates to authorize others?

B- What is the Certificate Authority and what could it be? What are its kinds and parameters that I need to configure and how?

C- In the above case study :  Would I need one certificate authority for each subnet or one for both and where would I put it?

D- Wouldn't I need more devices for that and could I use my subnet devices (Router or host end server ) to be my Certificate authority and provide certificates to authorize others for me?

4-     It's about the packet format of the  pre-fragmented packet :

I don't know what are the encrypted fields; but because the reassembly would occur after decryption , So I think that the fragmentation information are hidden through the encapsulated part ; I don't know if the identification field and the sequence number field are also encapsulated or not?

My questions :

A- Would this cause out of order fragments problems and give a chance for non-initial fragment attacks through some firewalls and other devices in the network?

B- If Yes; How could these problems be solved and/or avoided?

Thanks for your Co-operation.

Rose.

[rose_smile33]

Could any One Answer or help me ;  Even in any of the above questions. Please!

Rose

[Laurent Aubert]

Hi Rose,

You are mixing several different things in your post. The way your IPSec Peers are authenticated during Phase 1 (via CA or pre-shared key) has nothing to do with pre-fragmentation

Regarding IPSec configuration, the following link should help: http://www.cisco.com/en/US/tech/tk583/tk372/tsd_technology_support_protocol_home.html

Basically, authentication based on certificate requires a trusted certification authority or CA which will deliver the certificates during the enrollment process to all the IPSec peers. Once it's done the CA will not be involved during IKE Phase 1.

Your end devices doesn't need any specific configuration to support pre-fragmentation for IPSec. IP fragmentation and reassembly is part of every IP stack.

The goal of pre-fragmentation for IPSec feature is to fragment the clear packets and encrypts each fragment. Once decrypted, each fragment will be send to the destination which will do the reassembly. It's not recommanded to let the router fragmented after encryption as it's very ressources consuming on the other IPSec router receiving those fragments. It will impact the performance.

The following link explains very well all the issues aorund fragmentation: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

HTH

Laurent.

[rose_smile33]

Hi and Happy New Year ; 

Thank u Laurent for interest but i have things that i want to clear;

You said: " The way your IPSec Peers are authenticated during Phase 1 (via CA or pre-shared key) has nothing to do with pre-fragmentation"

I really want to establish a tunnel between the two peers and their routers, I want to make pre -fragmentation in this case to generate an IPSEC pre-fragmented packet then make some change in its format relating to my study experiments.

You said: " Basically, authentication based on certificate requires a trusted certification authority or CA which will deliver the certificates during the enrollment process to all the IPSec peers. Once it's done the CA will not be involved during IKE Phase 1."

My quetion is : Can each peer act as a CA to the other peer and vise versa!

You said: "Your end devices doesn't need any specific configuration to support pre-fragmentation for IPSec. IP fragmentation and reassembly is part of every IP stack."

Yes; but i had read the cisco Document:" Pre-fragmentation for IPSEC VPNs" and found that:

- This feature is not supported except in certain releases and series.

- It depends on the state of the Egress Interface "Crypto ipsec-df-bit" and the "Incoming Packet DF bit "state

-To enable this feature ; You use a command " Crypto ipsec fragmentation before-encryption"

Quetions:

1- What if i hadn't do one of the above settings; because my simulation doesn't introduce the DF bit state to change nor have a Cisco command  interface to enable this feature in a Cisco router? How could i generate pre-fragmentation ? Would the adjustment of the MTU of the tunnel interface be sufficient?

2- What would happen if Out of order fragments had occurred in the traffic of IPSEC pre-fragmented packets ? How would this be solved?

I had studied your specified reference which explains all the issues around fragmentation: http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml

And i would check your references Regarding IPSec configuration, and feed you back : http://www.cisco.com/en/US/tech/tk583/tk372/tsd_technology_support_protocol_home.html

If you (Laurent) or anyone of the community have any feed back about the above question ; it will be nice from you to  help or share opinions.

Sorry for my many quetions and Thanks for interest and kind.

Regards;

  Rose.

[Laurent Aubert]

Hi Rose and all the best for this new decade ;-)

"I really want to establish a tunnel between the two peers and their routers, I want to make pre -fragmentation in this case to generate an IPSEC pre-fragmented packet then make some change in its format relating to my study experiments."

Just to be clear, you want to build the IPSec tunnel between the two routers so you can exchange data between the two peers right ?

This is the order of operation by default when IPSEC pre-fragmention is supported. The default mode is fragmentation before encryption:

1- routeur received a 1500 Bytes original  IP packet from the LAN

2- This packet should be routed through the IPSec tunnel

3- The MTU of the resulting IPSec packet is higher than the egress interface MTU (1500B)

4- Router checks the DF-bit of the original packet.

5- If DF bit is set to 1 then dropp the packet and send an ICMP too big packet to the source. If set to 0 then fragment the original packet (original packet becomes n IP packets) and encrypt each new ip packets (or fragment). All those fragments (after decryption on the other side of the tunnel) will be received and reassembled by the destination

I don't understand what you mean by "I want to make pre -fragmentation in this case to generate an IPSEC pre-fragmented packet then make some change"

"Can each peer act as a CA to the other peer and vise versa!"

You need only one CA. Also you can configure a router to act as a PKI or CA but never tried a configuration where the PKI is also an IPSec peer. It may work.

"1- What if i hadn't do one of the above settings; because my simulation doesn't introduce the DF bit state to change nor have a Cisco command  interface to enable this feature in a Cisco router? How could i generate pre-fragmentation ? Would the adjustment of the MTU of the tunnel interface be sufficient?"

To prevent IPsec from fragmenting GRE packets, you should decrease the MTU on the tunnel interface to take into account the GRE + IPSec headers. This way if the bit df of the original packet is set to 0, you will see fragmentation of the original packet before GRE and IPSec encapsulation.

2- What would happen if Out of order fragments had occurred in the traffic of IPSEC pre-fragmented packets ? How would this be solved?

The destination which is responsible for the reassambly must wait for all fragments to do the reassambly so receiving all the fragments is more important than receiving them in a different order.

HTH

Laurent.

[rose_smile33]

Hi Everybody;

    Thank you Laurent for your answers;

I had read chapter 5 of Cisco VPN Services port adapter configuration guide which is " Configuring IPSec VPN Fragmentation and MTU" and i have some questions:

1- What are the main differences between the two IPSEC VPN modes: " Crypto connect mode" and "VRF mode"?

2- What are the main differences in fragmentation and reassembly if happened by VSPA or RP?

3-Does the term " Tunnel interface IP-MTU " mean that this MTU includes GRE+IP encapsulation"If exists" + IPSEC overhead?

4-You said "To prevent IPsec from fragmenting GRE packets, you should decrease the MTU on the tunnel interface to take into account the GRE + IPSec headers. This way if the bit df of the original packet is set to 0, you will see fragmentation of the original packet before GRE and IPSec encapsulation"

A- What is the default state of the DF bit of the original packet?

B- IF the DF=0 and the IP-MTU on the GRE tunnel interface low enough to take into account the overhead from both GRE+IPSEC

     If i configure The Tunnel MTU to be less than The minimum MTU of the physical egress interface , would i have a pre-fragmentation for IPSEC packets?

5- Does VTI encapsulation add any headers? IF yes; What are its component and where would it be added?

6- If packet reassembly on the IPsec peer had done in process switching mode ; it would reduce the throughput.

What are the different ways of packet fragments and reassembly? And what are the differences between them?

Thank you very much for interest

Best Regards;

               Rose.

[Laurent Aubert]

1- What are the main differences between the two IPSEC VPN modes: " Crypto connect mode" and "VRF mode"?

There is no difference as it's two different features. crypto connect mode means you use crypto map to configure IPSec and VRF mode means you route our clear traffic into a VRF (your IPSec traffic could be in the GRT or in another VRF)

2- What are the main differences in fragmentation and reassembly if happened by VSPA or RP?

With VSPA you will have some hw assistance and on RP it's pure software so you will quickly kill your router. In any case try to avoid fragmentation at all using PMTUD or at least avoid fragmentation after encryption.

3-Does the term " Tunnel interface IP-MTU " mean that this MTU includes GRE+IP encapsulation"If exists" + IPSEC overhead

No it doesn't include any encapsulation header. It represent the maximum size of the original packet that can be send over the tunnel.

4-You said "To prevent IPsec from fragmenting GRE packets, you should decrease the MTU on the tunnel interface to take into account the GRE + IPSec headers. This way if the bit df of the original packet is set to 0, you will see fragmentation of the original packet before GRE and IPSec encapsulation"

A- What is the default state of the DF bit of the original packet?

It depends of the application but I think must of the time they set the DF bit as PMTUD is usually enabled by default on most OS

B- IF the DF=0 and the IP-MTU on the GRE tunnel interface low enough to take into account the overhead from both GRE+IPSEC

     If i configure The Tunnel MTU to be less than The minimum MTU of the physical egress interface , would i have a pre-fragmentation for IPSEC packets?

You will have pre-fragmentation of the original packet if its MTU is higher than the tunnel MTU  (and DF bit = 0) regardless of the egress interface MTU. If the resulting GRE packet has a MTU higher then the egress interface, you will see a pre-fragmentation of the GRE packet (if DF bit = 0) before its encryption.

5- Does VTI encapsulation add any headers? IF yes; What are its component and where would it be added?

VTI is a pure IPSec interface so it adds only the IPSec header

6- If packet reassembly on the IPsec peer had done in process switching mode ; it would reduce the throughput.

Packet reassembly is done by the CPU so it will greatly reduce the thoughput. Don't forget if you do pre-fragmentation, reassembly will happen on the destination host and not the IPSec peer.

HTH

Laurent.

[rose_smile33]

Hi ;

Thanks Laurent

1- "VRF mode means you route our clear traffic into a VRF (your IPSec traffic could be in the GRT or in another VRF)"

What do you mean by GRT , and what are the required configurations for IPSec traffic to be in the GRT or in another VRF? [ i don't understand how could the route be for clear traffic when i deal with IPSEC (encrypted) traffic?]

2- I had attached chapter 5 " Configuring IPSec VPN fragmentation and MTU" , page5-4 includes Figure 5-1 Fragmentation of IPsec packets in All VPN modes. There are some notes and questions:

A- You said "VTI is a pure IPSec interface so it adds only the IPSec header"

If we take the direction that there's no  encapsulation by GRE or VTI, Why we find pure IPsec encapsulation available?

B- If we take the direction that there's encapsulation by GRE or VTI:

- There's no check if pre-fragmentation is enabled or not if needed . Does it mean that this direction of the chart is only work in the IPsec tunnel mode which it's default pre-fragmentation enabled and that the opposite direction (NO GRE or VTI encapsulation) would apply in the transport mode?

C- The chart presents that if the process is taken over VPN SPA ,

I- The VTI encapsulation is presented only by VPN SPA , How could i configure that to ensure that the encapsulation would occur by VPN SPA?

II -There's only a chance of one fragmentation , which would may occur before GRE encapsulation ; what if i want to avoid that and move pre-fragmentation to be only before IPSec encryption.

D- Does the term " Tunnel interface IP-MTU " mean that this MTU includes GRE+IP encapsulation"If exists" + IPSEC overhead

You Said: "No it doesn't include any encapsulation header. It represent the maximum size of the original packet that can be send over the tunnel."

and "You will have pre-fragmentation of the original packet if its MTU is higher than the tunnel MTU  (and DF bit = 0) regardless of the egress interface MTU. If the resulting GRE packet has a MTU higher then the egress interface, you will see a pre-fragmentation of the GRE packet (if DF bit = 0) before its encryption"

I- I mean theTunnel IP MTU ( in the chart is presented by t-MTU) , if the MTU of the physical interface = Y, if i build the tunnel over a real physical interface And If i have a GRE and IPsec overhead ;

Must the t-MTU be configured to be less than Y by [ 24byte(GRE+IP)header + IPsec overhead] To ensure IPSEC pre-fragmentatio?

II- Where would i set the original packet size? (Wouldn't it be the physical egress interface MTU /or it would be here = t-MTU )?

Sorry to include many questions ; it becomes as a default.

Thanks very much

Rose

[Laurent Aubert]

Hi Rose,

1- GRT means Global Routing table and refers to the default routing table you use when no VRF are configured.

2-A I didn't say there is no encapsulation by VTI, I said VTI encapsulation is only the IPSec header. GRE has its own encapsulation because it's already a tunneling techniques so will be added before the IPSec one's.

The right side of the chart refer to crypto-map configuration mocde. See VTI as a another way to do the same thing.

C-1: I don't understand your question. As soon as VTI is configured, packets forwarded to this interface will be processed by the VPN-SPA for encryption

C-2: you don't want that as it could kill your remote IPSec peer. Not sure if you can do it anyway.

D-1: Yes. Pre-fragmentation will occur if the MTU of the original packet is higher then the t-mtu and DF bit set to 0

D-2: It depends of what is your source of trafic. If it's a PC, usually the MTU is 1500B so you can generate ping up to this value. If your t-MTU is less than 1500, you will see pre-fragmentation

Laurent.

[rose_smile33]

Hi Everybody;

How are you Laurent ! Hope to you all the best.

" C-1: I don't understand your question. As soon as VTI is configured, packets forwarded to this interface will be processed by the VPN-SPA for encryption"

I mean that in the chart in my last attachment: If there's a GRE encapsulation the Pre-fragmentation occur only before GRE encapsulation if the packet size is less than t-MTU and there's no chance for pre-fragmentation before IPsec encryption. OK  i don't want that to occur because my case is that: i want only one pre-fragmentation which is before IPSec encapsulation and not prior GRE encapsulation (To avoid double fragmentation) . But this case is not presented by the chart. What shall i do.

If i use 12.4.1 release on 7200 IP router; How to configure the followings from command line to match my case:

- Setting DF=0 in the inner IP header of the IPSEC packet.

- Enable PMTU Discovery.

- Enable / Configure tunnel path MTU.

Thanks for all of your support and kind.

   Rose

[Laurent Aubert]

Hi Rose,

I'm fine thank you !!

Why do you want fragmentation between GRE and IPSec encapsulation ? It's not recommanded at all as it could kill your IPSEc peer as there is usually no hw support for reassembly.

If you really want to do it, configure an IP MTU of 1500 under your tunnel interface so your GRE packets should be fragmented before encryption (assuming the MTU of your egress interface is 1500). By default PMTUD is not enabled for GRE so the DF bit of the GRE header will be 0 regardless of the DF bit of the original packet.

If you want to enable PMTUD for GRE, use the tunnel path-mtu-discovery command. But in this case you will not be able to do pre-fragmentation as the PMTUD will do his job so too big packet will be dropped.

HTH

Laurent.

[rose_smile33]

Hi;

"Why do you want fragmentation between GRE and IPSec encapsulation ? It's not recommanded at all as it could kill your IPSEc peer as there is usually no hw support for reassembly.

If you really want to do it, configure an IP MTU of 1500 under your tunnel interface so your GRE packets should be fragmented before encryption (assuming the MTU of your egress interface is 1500). By default PMTUD is not enabled for GRE so the DF bit of the GRE header will be 0 regardless of the DF bit of the original packet."

First: (My case)I want fragmentation between GRE and IPSEC but only after GRE encapsulation and before IPSEC encryption (i.e. only one pre-fragmentation for IPsec packets which would not kill my IPsec peer); How could i do that?

Second:" If you want to enable PMTUD for GRE, use the tunnel path-mtu-discovery command. But in this case you will not be able to do pre-fragmentation as the PMTUD will do his job so too big packet will be dropped."

IF PMTUD is enabled the DF=1 but you can clear it to allow fragmentation.

Third:If i use 12.4.1 release on 7200 IP router; How to configure the followings from command line to match My case:

- Setting DF=0 in the inner IP header of the IPSEC packet.

- Enable PMTU Discovery.

- Enable / Configure tunnel path MTU

Regards;

Rose

[Laurent Aubert]

Rose,

I'm completely lost with what you want to achieve. It makes no sense to me to want at the same time pre-fragmentation and PMTUD because the goal of PMTUD is to avoid fragmentation and save router ressources !!!

First: (My case)I want fragmentation between GRE and IPSEC but only after GRE encapsulation and before IPSEC encryption (i.e. only one pre-fragmentation for IPsec packets which would not kill my IPsec peer); How could i do that

LA: this is what I explained in my previous post. Configure a IP MTU of 1500 under your GRE tunnel and send an IP packet of 1500B into it. The CPU impact will depends of how many fragments the router is receiving but it can be overloaded very fast !! Do you want to take that risk on a production network !!

Second:" If you want to enable PMTUD for GRE, use the tunnel path-mtu-discovery command. But in this case you will not be able to do pre-fragmentation as the PMTUD will do his job so too big packet will be dropped."

IF PMTUD is enabled the DF=1 but you can clear it to allow fragmentation.

LA: Actually the tunnel PMTUD will copy the DF bit of the inner packet to the GRE header so it may not be always 1.

Third:If i use 12.4.1 release on 7200 IP router; How to configure the followings from command line to match My case:

- Setting DF=0 in the inner IP header of the IPSEC packet.

LA: use a route-map on the ingress interface with set the df-bit to 0

- Enable PMTU Discovery.

LA: for who ?

- Enable / Configure tunnel path MTU

LA: use the command I already gave to you: tunnel path-mtu-discovery

If you set in ingress the DF bit to 0 for all the traffic, then tunnel PMTUD is useless.

Laurent.