[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Retransmits in traffic count?
<much chopped>
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
> Sent: August 5, 1999 3:07 PM
> To: Tim Jenkins
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Retransmits in traffic count?
>
>
> On Thu, 05 Aug 1999 14:23:20 EDT you wrote
>> 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.
>
What do you mean "it's not there"? All I see in RFC2409 is a section saying
there are life types that can define "a type of lifetime to which the ISAKMP
Security Association applies." This says to me that I can use the traffic
limit life type in phase 1. <draft-ietf-ipsec-ike-01.txt> has the same
thing.
> > 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.
Who was suggesting the MIB dictate what the protocol did? I mean backwards
compatibility with implementations that can use traffic based lifetimes for
phase 1.
Our implementation currently allows the user to specify and negotiate phase
1 SA lifetime based on traffic. (I don't know our customers use it.) If it
becomes removed from the 'standards', where does that put us? Do we need to
use a vendor ID payload to see if we can negotiate it? I hope not.
Maybe it's moot, since the existing Life Type attribute number will still
exist, and SA lifetime negotiation seems to be to use your own limits
anyway.
But back to the MIB, it needs to be able to reflect usage. So if anyone
continues to use phase 1 durations limited by traffic, the MIB needs to be
able to reflect that. And as far as I can tell, the IKE DOI allows it to be
used in phase 1, so the IKE DOI MIB should probably put it in.
Follow-Ups: