[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec and TCP
In the case where you are the clear-text machine behind a firewall, and the
firewall is waiting for keys, you will still have this problem.
On the other hand, I think there is already a mechanism for this. I think
the ICMP SOURCE QUENCH message is exactly intended for the "please stop
sending a moment, I am busy" case.
So, since the problem you describe can happen in both cases (tcp and ipsec
colocated, and tcp and ipsec in different nodes) I think it would be worth
researching the meaning and implementation of Source Quench for this case.
I believe Source Quench is in the Host Requirements RFC, and therefore it
is reasonable to use this mechanism, assuming it's appropriate.
OK, someone who has memorized all the ICMP RFC's and the Host Req RFC,
please correct me ...
At 05:04 PM 12/20/96 -0500, you wrote:
>This is regarding the behavior of TCP when a packet is queued at the IPsec
>layer for want of keys. When TCP sends a packet down to the IPsec layer it
>starts it times for retransmission. IPsec then queues the packet and starts
>negotiating keys. If the TCP times out on the packet then it will modify its
>congestion window parameters assuming that the network is congested.
>
>Does it make sense for the IPsec layer to inform the TCP about the packet
>being queued locally so that when TCP retransmits the packet, it does not
>modify its congestion window? The advantage of doing this is that the
>performance does not suffer.
>
>However, what if the network is really congested by the time the keys are
>obtained. Should the connection start with slow start always.
>
>There are merits for both the cases and I would like to hear other people's
>views on this.
>
>
>--Naganand
>----------------------------------------------------------------
>naganand@ftp.com
>Tel #: (508)684-6743 (O)
>
>
>
--------
Rodney Thayer <rodney@sabletech.com>
PGP Fingerprint: BB 1B 64 28 40 91 29 AC 07 6B 9D E1 4C 25 0D D8