[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Retransmits in traffic count?
On Thu, 05 Aug 1999 16:06:58 EDT you wrote
> Ahh, the wonderous diversity of a technical mailing list. On one hand,
> you've got people complaining that a simple protocol like IKE-Config is too
> risky simply because it adds complexity to your state machine (even though
> there are no real plausible attacks). And now you've got people arguing that
> Kb expiry of an IKE SA is useless simply because the attacks (which are easy
> to envision) are too esoteric.
I don't know what technical mailing list you've been reading but welcome
to IPSec. No one was arguing about anything called IKE-Config (perhaps you
mean ISAKMP-Config) it was XAUTH that's the risky protocol. And I never said
an attack against SKEYID_d was too esoteric.
> We're in the security business. We're supposed to be (at least a little bit)
> paranoid. If people didn't care about identity protection then why would
> they be using main mode?
Because Main Mode has much richer negotiation capabilities (that is, if
you actually parse the attributes and use the values in negotiation).
> Organizations like the military collect and analyze
> statistical data such as who is talking to who.
The data to collect is the IPSec protected data since that will tell a
whole lot more than just knowing the ID payloads used in IKE. And removing
the KB lifetype value from the protocol will not make the life of the
military (or any other bogyman you can think of) easier.
> Deprecating features (especially a locally enforced feature like this one),
> simply because a few parties can't see any use for thm, isn't what a
> standards-determining organization is supposed to be about. Our customers
> expect us to be forward-thinking; if we don't plan for an attack, simply
> because we can't think of how to exploit it off the top of our heads, then
> how can we be forward-thinking?
Had I not added KB lifetime to IKE in the first place I seriously doubt
you would be demanding it today. And this topic was brought up 2 months
ago by a well-respected member of this WG and no one said anything.
If KB lifetime is a locally enforced feature (as you say) which is not
negotiated (and if the attribute appears in an offer it's ignored in favor
of the locally configured value) then it is not part of the protocol. If
the protocol removes the KB lifetime attribute and/or re-uses the lifetype
value for a lifetype that actually makes sense it will not have any effect
on implementations which happen to have this locally enforced value. You
could have other locally enforced rules (like an idle timer which auto-
matically deletes SAs if they have not been used in X seconds/minutes/hours)
which you may want to have knobs to give your customers but that too is not
part of the protocol.
The only people arguing for KB lifetype in phase 1 are the ones that,
admittedly, don't use the value in negotiation. That's pretty funny.
Dan.
References: