[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re[4]: ISAKMP performance
- To: pcalhoun@usr.com
- Subject: Re: Re[4]: ISAKMP performance
- From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
- Date: Fri, 18 Jul 1997 12:43:33 -0400
- Address: 1 Amherst St., Cambridge, MA 02139
- Cc: "Theodore Y. Ts'o" <tytso@MIT.EDU>, David Jablon<dpj@world.std.com>, Robert Moskowitz <rgm3@chrysler.com>, Daniel Harkins<dharkins@cisco.com>, andrade@netcom.com, norm@tor.securecomputing.com, ipsec@tis.com
- In-Reply-To: pcalhoun@usr.com's message of Fri, 18 Jul 1997 07:52:25 -0500,<3CF77EA0.3000@usr.com>
- Phone: (617) 253-8091
- Sender: owner-ipsec@ex.tis.com
Date: Fri, 18 Jul 1997 07:52:25 -0500
From: pcalhoun@usr.com
Thanks for the input. However, I am faced with a bit of a problem.
You see most WG blindly point to IPSEC for all security needs, not
necessarily understanding whether it fits or not. I think that I have
brought up a scenario where IPSEC (or rather DH exchange) does not
scale very well.
I would like the IPSEC WG to inform other WGs currently looking at
using it about this possible scaleability problem. Otherwise, we will
end up with protocols that really do not work very well in large
networks.
The IPSEC working group (like other working groups :-) doesn't have a
publicity arm which can use to do as you ask. It would be fair to ask
some ISAKMP/Oakley implementors to post some benchmark numbers for their
various implementations, though.
It has always been the position of the Security Area Director and
Security Area Directorate that it is not approrpiate for working groups
to "blindly pointing to IPSEC for all their security needs". Like
everything else, thought is required --- real analysis about how the
application protocol will get used, by whom, etc., etc.
Unfortunately, some combination of laziness and lack of security people
in certain working groups has caused a number of working groups to adopt
this attitude. Basically, they erect a "Sombody Else's Problem" field
and then become surprised when they get fooed upon either at IETF Last
Call or by the IESG.
This is not a new problem, and I wish I had better answers for you. If
anyone has any suggestions, feel free to send mail to secdir@mit.edu or
saag@tis.com....
- Ted
References: