What are the Encrypted fields of the inner IP header of the IPSec VPN pre-fragmented packets

[rose_smile33]

Hi;

First: In the ESP tunnel mode of the IPSEC :

1.       Is the IP ID field of the inner IP header encrypted?

2.       Is the IP ID field of the outer IP header different of that of the IP header?

3.       Is the sequence number field of the TCP header encrypted?

Second: Regarding the IPSec VPN pre-fragmentation:

1.       Is the Fragment offset of the inner IP header encrypted?

2.       In the following Cisco document: “ Pre-fragmentation for IPSec VPNs”; it was mentioned as one of IPSEC advantages that :

IPSec pre-fragmentation provides uniform fragmentation packets which are fragmented into equally sized units.

How does this the meaning of the resulted equally sized fragments differ in IPS pre-fragmentation from other normal fragmentations behavior!(i.e. The normal behavior of the followed Fragment offsets of the same packets is to have the same difference which is the MTU and fragments except the last fragment of a packet have equally size =MTU) ?

Thanks

[wzhang]

Hi,

For tunnel mode IPSec:

1. Yes

2. Yes

3. Yes

For more details, you can check:

http://tools.ietf.org/html/rfc4301#section-5.1.2

For IPSec pre-frag behavior:

1. Yes

2. I'm not sure if I understood your question. But our IPSec implementation chooses to fragment packets in more-or-less equal size fragments as opposed to, say one large fragment just below the ip mtu boundary, and whatever leftover in a smaller fragment. Is that what you are asking?

Thanks,

Wen

[rose_smile33]

Hi Wzhang;

To clear my last question:

In any fragmentation process; all fragments of a packet except the last fragment have the same size which reflects an equally fragments (a uniform fragmentation packets).

Why the mentioned reference gives this as a special advantage for IPSec pre-fragmentation.

I have also another questions:

- The sequence number field in the TCP header helps in arranging the received packets by their transmitted sequence. Do all transport protocols have a sequence number field in their headers? If not; how packets would be ordered?

- Why the sequence number field doesn't suffice the need for IP ID field in fragments reassembly of a packet?

Rose.

Thanks

[wzhang]

Hi,

Let's assume a fragmentation boundary of 1400 bytes. With a 1500 byte packet, you could fragment it into one 1400 and one 120 byte packets; or you could fragment it into one 752 and one 768 byte packets. With the first method, you may potentially need to fragment the larger fragment again (say further down the ip path with a DSL link that has an ip mtu of 1492). The second approach helps avoid this kind of condition. That's an advantage over

traditional large/small fragment approach.

Only TCP has the sequence number in the TCP header. UDP does not know/care about transport layer ordering. Fragmentation is a L3 (ip) property, so it has nothing to do with sequence numbers in TCP, which is L4. At layer 4, fragmentation is out of the picture since the datagram is already reassembled by IP, segmentation can happen at this layer, but that's something completely different.

Thanks,

Wen

[rose_smile33]

Hi;

"Let's assume a fragmentation boundary of 1400 bytes. With a 1500 byte packet, you could fragment it into one 1400 and one 120 byte packets; or you could fragment it into one 752 and one 768 byte"

I- The example didn't show equally sized fragments. To reach that the two fragments should be 760 each.

In which sense or equation the two fragments could be one 752 and one 768 byte packets?

"Only TCP has the sequence number in the TCP header. UDP does not know/care about transport layer ordering. "

II- The sequence number field helps in arranging the packets at the receiver by their transmitted sequence.

A- Must the sequence number of packets has a non missed value; i.e. If the transmitter send 3 packets must they have sequence 1 2 and 3 respectively or might they be for example 2 5 9? If it could be; how the receiver would expect for 3 4 6 7 8 packets? Would it wait for them?

B- What if for some propose; it was designed two packets with the same sequence number. How would the receiver and intermediate routers dial with them?

C- In UDP and other transport layer protocol which haven't the sequence number field; how are the received packets re-ordered to give the logical transmitted information?

Thanks And Regards,

                 Rose

[wzhang]

Hi,

I- The example didn't show equally sized fragments. To reach that the two fragments should be 760 each.

In which sense or equation the two fragments could be one 752 and one 768 byte packets?

Per RFC791, the first fragment must be a multiple of 8 octets (which is the unit used in the Fragmentation Offset field), the last fragment will not have this restriction. So they are equal in the sense that the first fragment is of the size closest to the half of the original datagram size and is also divisible by 8. Whatever remains will be the size of the last fragment with the 20 bytes of new header.

II- The sequence number field helps in arranging the packets at the receiver by their transmitted sequence.

A- Must the sequence number of packets has a non missed value; i.e. If the transmitter send 3 packets must they have sequence 1 2 and 3 respectively or might they be for example 2 5 9? If it could be; how the receiver would expect for 3 4 6 7 8 packets? Would it wait for them?

It depends on the TCP implementation. Most modern TCP stacks will support TCP selective ACK (rfc2018), in which case the sender can selectively retransmit the missing tcp segments upon receiving the SACK TCP options from the receiver.

B- What if for some propose; it was designed two packets with the same sequence number. How would the receiver and intermediate routers dial with them?

The second packet with the same sequence number will be treated as a retransmitted TCP segment regardless of the content.

C- In UDP and other transport layer protocol which haven't the sequence number field; how are the received packets re-ordered to give the logical transmitted information?

For applications that use UDP as transport, it's the applications responsibility to ensure packet sequencing.

Thanks,

Wen

[rose_smile33]

Hi;

Thanks Wen

I would read the RFC 2018 and give a feedback to you. Till that I have questions:

In RFC 4301; it was mentioned in IPv6: Header Construction for Tunnel Mode that for extension header (as the fragmentation header) the outer at encapsulator header never copied.

-         Is this mean that the IP ID field and the fragment offset would have different values than those of the inner header?

-         How the Pre-fragmentation is applied in the IPV6?

-         Do pre-fragmentation in IPV6 has any different than that of IPv4?

Best Wishes

Rose

[wzhang]

Hi, Rose:

The first thing you'd notice in an ipv6 header is that, there are no IP ID or Fragmentation Offset fields as in ipv4. Also, with ipv6, there is no hop-by-hop ip fragmentation (it's only performed by the source node), so the concept for pre-fragmentation, or fragmentation in general on an IPSec tunnel endpoint, really doesn't apply to ipv6.

Thanks,

Wen

[rose_smile33]

Hi Wen;

You said:

" The first thing you'd notice in an ipv6 header is that, there are no IP ID or Fragmentation Offset fields as in ipv4."

But there's an extension fragmentation header for IPV6 and this header contains IP ID and Fragmentation Offset fields. I attached to you the IPv6 Fragment header extension file to see the structure of that header.

"there is no hop-by-hop ip fragmentation (it's only performed by the source node), so the concept for pre-fragmentation, or fragmentation in general on an IPSec tunnel endpoint, really doesn't apply to ipv6."

If fragmentation is only performed by the source node, there would no need for the outer fragmentation extension header while an inner and outer fragmentation extension header may be existed as the RFC 4301 mentioned that in IPv6: Header Construction for Tunnel Mode that for extension header the outer at encapsulator header never copied.

Also If fragmentation is only performed by the source node as you said: It means that if it is occoured in the tunnel mode ; It would be occured befoure source gateway encryption which means pre-fragmentation.

Could you give me a feed back for this post and the one before it; please?

Thanks

Rose

[wzhang]

Hi Rose,

For ipv6, the fragmentation extension header is not copied from the inner packet to the outer encapsulating header during tunnel encapsulation. The term pre- or post-fragmentation on an ipsec tunnel endpoint is only meaningful in the context of tunnel encapsulation, ie., pre- means pre-encapsulation/encryption fragmentation, and post- means post encapsulation/encryption fragmentation by the encapsulating router. With IPv4, an ipsec tunnel endpoint can encrypt an ip fragment coming a source host, but we don't call that pre-fragmentation since fragmentation is not performed by the router. The same goes for IPv6. I hope this clarifies.

Thanks,

Wen

[rose_smile33]

Hi Everybody;

First of all; I hope all the best to you Wen and all people of the world in the New Year.

I'm really missed your point: "With IPv4, an ipsec tunnel endpoint can encrypt an ip fragment coming a source host, but we don't call that pre-fragmentation since fragmentation is not performed by the router. The same goes for IPv6. I hope this clarifies."

Pre-fragmentation in IPSEC VPNs means that the fragmentation occurred by the source end before router encryption.

So why not could it happen in IPV6 using the inner fragmentation extension header?

Do you have any convinced reasons? It would be nice from you to support your reasons with references because this point is very very important to my research.

Thanks a lot.

  Rose

[rose_smile33]

Hi Wen;

I had said before that the structure of  IPV6 has IP identification field and fragment offset but these field are included in the extension fragmentation header. While the fragmentation is done by the source node, so in IPv6 if fragmentation is happened in IPsec VPN, it would be done by the source before router encryption. This the main mean of IPSec VPN pre-fragmentation and that's what I understand.

So please because i'm not sure from my thought is right or not and you didn't give me any prove about your claim. So i need this point to be consulted from an authorized paper if you have any or from cisco team to reach a verified authorized answer to built on it in my research; Please.

Thanks.

  Rose