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

Re: Retransmits in traffic count?



On Thu, 05 Aug 1999 15:34:35 EDT you wrote
> > 
> > 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 was talking about the MIB! There is nothing about phase 1 KB lifetime in 
the existing DOI of 1 MIB. So, don't add it and then there is no problem.

> 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.

What are you going to do if XAUTH gets another exchange value? Or if IANA 
does not give Config-Mode the exchange value you're using today? You must
have a contingency plan for these possible occurances.

> 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.

If lifetime negotiation is as you say then what's the point of negotiating
them? If your implementation ignores lifetimes in offers (and uses it's own
limits anyway) then it won't matter what the lifetype is then right?
It can be 2 or 87 or something else can become 2 since you're not using it.

I think your problem is solved. As long as you don't change your code to
actually use these attributes and you continue to ignore them you have no
reason to be effected by the removal of KB lifetime from IKE. Since you're
not really negotiating it the "phase 1 KB lifetime" knob you give your
customers is just a no-op knob and it can continue to remain so.

> 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.

And if the attribute is removed then the MIB can remain the way it is 
right now. You don't need to add anything to the MIB because the thing you
want to add is going to be removed from IKE. Life is easier this way.
(BTW, there is no "IKE DOI" so there should not be an "IKE DOI MIB"). 

I'll ask again: who uses phase 1 lifetime of KB? Can anyone think of a
good reason to?

  Dan.




References: