Subject: interoperability issue with 'lifekbytes'

From: "Arun" <[email-masked]>
Date: Tue, 1 Jul 2003 10:35:31 -0700

Hi,

  We are frequently encountering interoperability problems
  with 'lifekbytes' configuration. Different vendors accept/implement
  different ways. Having consistent method mentioned in the
  standards will help eliminating/reducing the mis-interpretation.
  Any feedback on following interoperability issue from WG
  is appreciated.

   Security Gateway1--------------------Security Gateway2

  Admin at SG1 configured the IPSEC security policy 
  indicating that 'lifekbytes' is not expected. 
  SG2 sends QM SA payload with lifekbytes attribute with some
  value. Should SG1 accept the SA payload OR should it deny
  the SA payload.

  We feel that, since local admin made a choice that lifekbytes
  is not required/expected, it should deny the SA negotiation.
  What is the right thing to do? Also, we feel that by having
  consistent configuration on both ends will eliminate the 
  confusion. 

  Related question:
  What happens when SG1 starts the quick mode?
  Should SG2 deny the negotiation as it expected lifekbytes 
  attribute, but there is no 'lifekbytes' attribute coming from SG1?

  We feel that, for both cases to work, it is better to have
  same configuration on both ends so that it works consistently
  and give choice to the administrators.

Thanks in advance,
Arun

---

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 16 Jul 2003 02:36:48 -0700

> >>>>> "Arun" == Arun Kumar <[email-masked]> 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.