[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKE transport (was INITIAL-CONTACT issues)
>From: Paul Koning [pkoning@xedia.com]
>Sent: Monday, May 17, 1999 6:57 AM
>To: Sankar@vpnet.com
>Cc: ipsec@lists.tislabs.com
>Subject: RE: IKE transport (was INITIAL-CONTACT issues)
>
>>>>>> "Sankar" == Sankar Ramamoorthi <Sankar@vpnet.com> writes:
>
> Sankar> How about using udp for the first IKE session between 2
> Sankar> endpoints and then using a tcp-over-ipsec as the transport
> Sankar> for the rest of the IKE sessions that could happen between
> Sankar> the end-points?
>
>Yikes. It seems really ugly to changes horses, er., transports in
>midstream. There really is no major functional difference between
>using UDP with reliability/keepalive in the application, and TCP with
>some of that stuff moved into the transport. Given that the decision
>has been made to use UDP, my inclination is to say we should stick
>with it. If there is strong enough reason to switch, then let's
>switch. But I find it hard to imagine a reason strong enough to
>justify switching half the time, yet weak enough to justify not
>switching the rest of the time.
>
> paul
I agree there is no functional difference with using UDP with
reliablity/keepalive in the application and TCP with some of the
stuff moved into the transport. However some of those functions are
yet to be defined/standardized for IKE hence the desire to take
advantage of TCP. Hopefully IPSecond will address many of the issues.
One thing I am concerned with reliablity in the application is
retransmission timers
can gateways/end-stations aggressively retransmit for lost
packets? If so could it have any effect on congestion
(consider a gateway handling thousands of IKE sessions aggressively
retransmitting).
Or should the IKE implementation take into account of
end-to-end characterstics (RTT..), congestion avoidance measures
while retransmitting (similiar to TCP)?
Or is congestion not an issue for IKE traffic?
Thanks,
-- sankar --