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

Re: Retransmits in traffic count?



On Thu, 05 Aug 1999 14:23:20 EDT you wrote
> The particular MIB in question refers to the ISAKMP DOI-independent MIB. All
> of its objects are supposed to be based on RFC 2408. As it turns out, there
> are no SA lifetime attributes defined in RFC2408, suggesting that SA
> lifetime objects and the like should be removed from that MIB, and placed
> only in the DOI-dependent MIBs.

There are no SA attributes defined in RFC2408 at all. Problem solved!

> However, that raises another issue. If I understand the document advancement
> process correctly, no document can go to RFC status if it refers to "works
> in progress". If John and I move the SA lifetime objects to the DOI of 1
> MIB, we can only refer to RFC 2409, which defines SA lifetimes as time and
> traffic, not negotiations.

Actually you could only refer to RFC2407 if you want to be a stickler for
these things since that defines the DOI of 1. And if you want to refer to
RFC2409 just don't include KB lifetime in IKE. It's not there now so just
don't add it. 

> Further, I'm not sure that removing traffic lifetime limitations is a good
> idea, for backwards compatibility if nothing else. I also don't understand
> why it's a bad thing. Did we also decide that traffic based expiration of
> phase 2 SAs was a bad thing? Don't they exist to allow users to limit the
> exposure of encrypted material, potentially based on the strength of the
> algorithm?

Whoa! Nobody said anything about phase 2 SA lifetimes. That makes a whole
lotta sense. The KB lifetime (defined in RFC2407 by the way) is there for
the purpose you mention. But that purpose doesn't really make sense for IKE.
Limiting exposure of IPSec traffic makes sense because cracking a key used
with an IPSec SA gives the attacker all that traffic. But cracking a key used
with an IKE SA gives you what? IKE traffic. Cracking SKEYID_e will not give
the attacker any insight into SKEYID_d. 

> The only difficulty that I can see with phase 1 SA traffic lifetimes is what
> to do if it expires in the middle of an exchange.

Yes, that's a problem. The whole concept is a problem. A way to solve this
problem is to do away with it. It just doesn't make sense to limit the
life of an IKE SA by traffic. It's low volume, (relatively) uninteresting 
traffic. An attacker would learn the identities of the parties involved in
the IPSec communication and learn the attributes (but not the key!) of the 
IPSec SA. It would not provide any insight into what was being protected
by IPSec, which is the real target of any attack. Attacking IKE in this
manner would be a waste of time. I don't see it happening.

> I don't object to adding negotiation limits for lifetime, only object to
> removing the existing traffic expiration.

I don't think a MIB should dictate what a protocol does. It's the other
way around. But since the MIB in question shouldn't have these attributes
(as you pointed out) and the other MIB doesn't have this attribute already
then there would be no problem, MIB-wise, in doing away with it.

Getting rid of this attribute will get rid of a few headaches and cause none
of its own. Maybe you could say why would you use KB expiry for an IKE SA?

  Dan.



References: