RE: interoperability issue with 'lifekbytes'

[Gregory Lebovitz <Gregory@netscreen.com>]

> >>>>> "Arun" == Arun Kumar <arun_mc@intotoinc.com> writes:
>     Arun>  We are frequently encountering interoperability problems
>     Arun>   with 'lifekbytes' configuration. Different 
> vendors accept/implement
>     Arun>   different ways. Having consistent method mentioned in the
>     Arun>   standards will help eliminating/reducing the 
> mis-interpretation.
>     Arun>   Any feedback on following interoperability issue from WG
>     Arun>   is appreciated.
>  
>     Arun>    Security Gateway1--------------------Security Gateway2
>  
>     Arun>   Admin at SG1 configured the IPSEC security policy 
>     Arun>   indicating that 'lifekbytes' is not expected. 
>     Arun>   SG2 sends QM SA payload with lifekbytes attribute 
> with some

Let me ask a question in your example: was lifetime expected, but instead
lifekbytes received? Is this what you mean? Or is it more convoluted than
that?

>     Arun>   value. Should SG1 accept the SA payload OR should it deny
>     Arun>   the SA payload.
> 
>   The general feeling is that lifetime values are advice only.
> 
>   SG2 doesn't like what SG1 proposes (usually, a value too 
> large), then
> it should just rekey the SA more often. The advice only tells 
> SG2 how long
> it ought to keep the keys around, when the channel is otherwise idle.
> 
>     Arun>   We feel that, since local admin made a choice 
> that lifekbytes
>     Arun>   is not required/expected, it should deny the SA 
> negotiation.
> 
>   I do not think that a lifekbytes of zero should be sent, 
> but if received,
> it should be essentially ignored. It is meaningless. It 
> should be ignored,
> since at most, it was advice only.

I would have interpreted it as "I don't care," or "you rekey when you want
to; I won't be initiating a rekey with you". But I would say that we should
explicitly specify IF zero may be sent, and if so, what it means / how
receiver interprets it.

Just as a strawman, I would propose the following text:
   Zero is a valid proposal, and means the sender 
   will not be initiating a rekey, but will instead 
   rely on the receiver to initiate the rekey at their 
   desired interval.

>     Arun>   What is the right thing to do? Also, we feel that 
> by having
>     Arun>   consistent configuration on both ends will eliminate the 
>     Arun>   confusion. 
> 
>   No, you can not assume *identical* configuration.
>   a) this is why we have a protocol that has multiple options.
> 
>   b) this is often hard when multiple products are involved - 
> they may 
>      have compatible options, but not identical, and may not all offer
>      the same knobs - or worse - they do, but name them differently.

 - and worse yet - they do and interpret/handle them differently. This is
why I keep harshing on explicit specification whenever possible, hoping to
avoid the painful interop marathon we are STILL having in v1.

>      Hey, $LANG=en vs $LANG=cn would be enough to confuse the admins
>      enough such that they can't even find the options!
> 
>   c) okay, so you get the configuration identical with great effort.
>      Now you want to change it. 
>      Do you turn off the entire enterprise VPN, fly someone around the
>      world to reconfigure everything and then turn it back on?
>      clearly, not. 
>      So, you must deal with changes to the configuration as you evolve
>      your settings, slowly.
> 
>     Arun>   Related question:
>     Arun>   What happens when SG1 starts the quick mode?
>     Arun>   Should SG2 deny the negotiation as it expected lifekbytes 
>     Arun>   attribute, but there is no 'lifekbytes' attribute 
> coming from SG1?
> 
>   No. 

to clarify, for better interop, if your peer initiates rekey before you
expected it, go with it.

Gregory.