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

RE: IKE transport (was INITIAL-CONTACT issues)





>From: Scott G. Kelly [skelly@redcreek.com]
>Sent: Thursday, May 13, 1999 9:15 AM
>To: Burden, James
>Cc: 'Scott G. Kelly'; 'Stephen Kent'; Alex Alten;
>ipsec@lists.tislabs.com
>Subject: Re: IKE transport (was INITIAL-CONTACT issues)
>
>Hi Jim,
>
>Thanks for your detailed reply, and sorry I did not get back to you
>sooner. After reading and re-reading your reply, it seems to me that
>there were implicit assumptions behind my questions which should perhaps
>be made explicit to clear this up. 
>
>This discussion began with a suggestion that ISAKMP/IKE should be run
>over tcp instead of udp, and that this requirement be listed as "SHOULD"
>in the RFC. 

minor correction - My request was that ISAKMP/IKE SHOULD be supported
on tcp transport in addition to udp transport.

>I followed up that post with some speculation as to why UDP
>might have been chosen instead of TCP to begin with, and cited
>additional overhead as one possible concern. I guess I don't really need
>to go back through the thread in its entirety here, but I also suggested
>that one of the original design requirements was transport independence,
>and also that a DoS attack might be easier to mount if the transport was
>TCP, meaning that there would be more (useless) work per packet for TCP. 

I am not very clear on the DoS attack issues. It is my understanding
many web servers run into this problem and have addressed the DoS
attack problem for TCP at a system level.

>
>I have the feeling from your reply that you are discussing the more
>general case of allowing TCP vs UDP through a firewall for any
>application. I view ISAKMP/IKE as a different and special case, since
>ISAKMP/IKE provides for endpoint authentication as part of the protocol.
>In my view, the issue prompting this discussion is that the current
>ISAKMP/IKE specification seems to not provide enough in the way of
>connection-oriented service, and the question we have to answer is this:
>should we chuck the transport independence requirement and consider TCP,
>or should we instead add necessary and sufficient functionality to IKE?

Agree about the question to be answered.

I would like to know more about the rationale for the transport independence
requirement. If the two parties communicating have a common 
reliable transport(tcp) installed then why not use that for IKE traffic?
If one of them does not have the common reliable transport installed,
then the parties can always fall back to udp.

  Thanks,
-- sankar --



Follow-Ups: