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

Re: Comments on draft-ietf-ipsec-ike-01.txt (long)

  That's why it's a SHOULD not a MUST.

  People can continue to refuse offers of encryption algorithms with a
longer key length if they wish. They could even panic their box upon receipt
of such an offer and they would still be RFC-compliant! I just want to
expressly state that it's OK to accept things that can be perceived as
being more secure for attributes whose values can be a range since some
people thought that that was not allowed.

  I'm not legislating any behavior. 

  Dan.

On Wed, 02 Jun 1999 11:40:34 EDT you wrote
> >I'm attempting to codify the behavior of certain implementations. Some
> >people will not accept group 1 if they have group 2 configured but will
> >happily accept group 5. That seems to be correct behavior. Similarly for
> >variable length ciphers. If you're configured for 128 bit blowfish and
> >someone asks you if you want to do 448 bit blowfish do you refuse? If so
> >why? If not then where in the RFCs does it say that you can do this? 
> 
> In addition to the concerns about this that Tim Jenkins stated, I'll
> add one more:
> 
> A site admin running a box intending to support many IPSec and IKE
> SAs (where "many" could number in the hundreds or thousands) might
> be concerned about the performance of said box when running stronger
> ciphers, or when running larger D-H groups.  In particular, if one
> is handling lots of rekeying operations and is using PFS, then D-H
> performance could become a concern.  I could see where an admin might
> be concerned that D-H will "take too long" if an implementation
> automatically accepts group 5 when group 2 is configured, with no
> means provided to change that behavior, just because "the standard
> says so".
> 
> Performance tradeoffs may be just as important, and perhaps even more
> so, than security tradeoffs to some people.  I feel uncomfortable
> legislating behavior that might fly in the face of what end-users
> and end-administrators want to do.
> 
> -Shawn Mamros
> E-mail to: smamros@nortelnetworks.com
>
References: