[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on draft-ietf-ipsec-ike-01.txt (long)
Some comments triggered by what Tim said:
In a sense the discussion about how to handle "stronger" proposals is
innocuous since it contains the word "SHOULD". On the other hand, it
still implies that something is recommended and encouraged when it
isn't necessarily a good thing for some implementations. Shawn Mamros
raised the good point of performance: if local policy is to use group
1 and group 5 is proposed, should it be accepted? Or 3DES in place of
DES? Extra security is not free. Saying an implementation MAY do
this is fine, but saying SHOULD may not be.
It isn't clear from the text that it is only talking about parameters
of a single system. For example, while it's clear that group 2 is
stronger than group 1, it isn't clear whether how groups 2 and 3
compare. (Safest decision would be that they do not, so if I want 2
and 3 is proposed, I'll reject.)
By the way, in his comments Tim referred to "2DES" (meaning "two key
triple DES"). Currently that's not allowed for; it would be useful to
have that option given that some countries give special treatment to
below-128 bit ciphers but not to 168 bit ciphers. (Yes, I know from a
practical point of view the difference in strength is not particularly
interesting, but it's easier to add an option to a protocol spec than
to change a government regulation.)
On the subject of lifetime negotiation, I agree with Tim. That case
is clearly different from the others in that each side can enforce a
lifetime on its own. If I need a 1 hour lifetime, I should obviously
propose that if initiating, but there is nothing that prevents me from
deleting SAs after 1 hour even if 2 hours were negotiated. Since you
can get the desired effect (lifetime limit) unilaterally, I see no
reason to refuse such a proposal. It's fine to allow it to be
rejected, but the draft *requires* it to be rejected and that's going
too far.
paul
Follow-Ups:
References: