[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPSec Standard - No Flow Control?




Derek:

Excuse my Terminology.  It appears that for each Payload packet sent, there
is a small (Approx 98 Byte ESP) frame sent back, now, these could be the
encrypted Layer-4 acknowledgements.   Here is a sample of the trace:
#     DeltaT              Dest              Src               Size
Summary
1","0.000.000    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"
2","0.001.198    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"
3","0.001.191    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"
4","0.001.243    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"
5","0.003.525    ","[203.163.90.253]  ","[12.13.74.69]     "," 1306
","IP"," ESP SPI=198778318"
6","0.000.136    ","[12.13.74.69]     ","[203.163.90.253]  ","   98
","IP"," ESP SPI=1261713583"
7","0.001.377    ","[12.13.74.69]     ","[203.163.90.253]  ","   98
","IP"," ESP SPI=1261713583"
8","0.001.510    ","[12.13.74.69]     ","[203.163.90.253]  ","   98
","IP"," ESP SPI=1261713583"
9","0.000.418    ","[12.13.74.69]     ","[203.163.90.253]  ","   98
","IP"," ESP SPI=1261713583"
10","0.071.579    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"
11","0.001.145    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"
12","0.001.227    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"
13","0.001.209    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"
14","0.001.247    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"
15","0.000.943    ","[203.163.90.253]  ","[12.13.74.69]     "," 1306
","IP"," ESP SPI=198778318"
16","0.002.576    ","[12.13.74.69]     ","[203.163.90.253]  ","   98
","IP"," ESP SPI=1261713583"
17","0.000.985    ","[12.13.74.69]     ","[203.163.90.253]  ","   98
","IP"," ESP SPI=1261713583"
18","0.001.809    ","[12.13.74.69]     ","[203.163.90.253]  ","   98
","IP"," ESP SPI=1261713583"
19","0.000.404    ","[12.13.74.69]     ","[203.163.90.253]  ","   98
","IP"," ESP SPI=1261713583"
20","0.175.945    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"
21","0.001.298    ","[203.163.90.253]  ","[12.13.74.69]     "," 1490
","IP"," ESP SPI=198778318"

The problem seems to be a long delay between the 4th 98 (See Frame #9 and #
10, #19 and #20 above) Byte ESP frame and the next set of 1490 byte frames.
The delay can be from anywhere around 260 MS to as low as 60 MS, usually
closer to the former.  This delay kills the throughput of the connection.

The implementation is from Newbridge Networks, with their "TimeStep
PermitGate" product line.  The vendor says this behavior is the nature of
the IPSec standard, and their is nothing they can do about it, this also
appears to be the opinion of Netscreen Inc, who believe their products
would suffer the same issue.

Another ipsec list subscriber suggested that I increase the TCP window size
further than it is (64k).  Unfortunately not all platforms support larger
windows, but I will give this a try.

Thanks,

Rett Walters


                                                                                                                   
                    Derek Atkins                                                                                   
                    <warlord@MIT.        To:     Rett_Walters@payless.com                                          
                    EDU>                 cc:     ipsec@lists.tislabs.com                                           
                                         Subject:     Re: IPSec Standard - No Flow Control?                        
                    07/23/2001                                                                                     
                    12:42 PM                                                                                       
                                                                                                                   
                                                                                                                   




There are no ACKs to ESP packets.  The encapsulated TCP should be
handling the ACKs at (encrypted) layer-4.  Could you explain what you
mean by a "trace analysis showing a large percentage of time spent
waiting for CKs to transmitted ESP packets"?  Also, what platform(s)
and IPsec implementation(s) are you using?

-derek

Rett_Walters@payless.com writes:

> I have a question regarding IPsec inner workings.....
>
> Is there a provision for Flow Control in the IPSec Standards?
>
> I understand that IPSec essentially runs at Layer 3 which does not
include
> flow control algorithms (usually left to Layer 4 protocols such as TCP);
> however I have noticed in live implementations of the protocol, long
delay
> networks (250ms round-trip) suffer serious performance issues when
compared
> to non-encrypted TCP communications such as Ftp's, using large (64k) TCP
> Receive Windows.  Trace analysis shows a large percentage of time spent
> waiting for ACKs to transmitted ESP packets.  Is there no way to control
> the amount of data "in flight", ie setting a higher Window?   Using IPSec
> Encapsulation seems to override or Break the TCP Windows set in the
> encrypted packet headers, do to its own method of flow control (or lack
> thereof).....
>
> I am wondering if this was overlooked?
>
> Thanks,
>
> ___________________________________
> Rett D. Walters
> Network Architect
> Payless ShoeSource Inc.
> Phone: 785-295-2049, Fax: 785-295-6666
> Email: rett.walters@payless.com
>
>

--
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available






Follow-Ups: