[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
phase 1 lifetime by traffic (was RE: Retransmits in traffic count? )
I said this before: our implementation has the "knob" (as Dan puts it) to
allow the customer to do this. Why? Because it was part of the specs, so it
was done. Do our customers use it? I have no idea.
But it doesn't matter. My entire point is that the number 2 for life type of
traffic must not be changed to mean something else, since there are
implementations out there legitimately using that value. It's not clear to
me that is going to be changed; I just want to make it clear that it
shouldn't be changed.
Just because it is ignored during negotiations is not an excuse to change
it. What if we send a lifetime notification when we have traffic limited
expiration and the peer doesn't? What does the value 2 mean to the peer
versus our implementation if it gets changed?
I don't care if the new IKE says don't do phase 1 expiration using traffic.
I don't have a problem if implementations don't support that capability. But
the value needs to be held for backwards compatibility for lifetime
notification parsing if nothing else.
-----Original Message-----
From: Dan Harkins [mailto:dharkins@network-alchemy.com]
Sent: August 5, 1999 4:11 PM
To: Tim Jenkins
Cc: ipsec@lists.tislabs.com
Subject: Re: Retransmits in traffic count?
I'll ask again: who uses phase 1 lifetime of KB? Can anyone think of a
good reason to?
Dan.
Follow-Ups: