Subject: interoperability issue with 'lifekbytes'

From: Arun Kumar <[email-masked]>
Date: Tue, 1 Jul 2003 12:08:14 -0700 (PDT)

Hi,

 Sorry, my previous message format was bad. I'm resending it with proper 
format.

 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: Ravi <[email-masked]>
Date: Wed, 02 Jul 2003 14:35:29 +0530

Hi Arun,

If 'lifekbytes' is expected and if this attribute does not come from the 
peer,I feel, the SA coming from peer should be rejected.
If 'lifekbytes' attribute comes in, but it is not expected, then it 
seems OK to accept 'lifekbytes' as it is more secure. But, at any time,
we don't know which node initiates the quick mode negotiation. If one 
side negotiates, it succeeds and if other negotiates it does not
succeed. So, it is better to have same configuration on both ends and 
deny the negotiation if it does not match the local configuration.
Thereby, there is no confusion.  Note that this configuration is
supposed to be agreed upon by both administrators of the SGs and along
with other parameters, this also can be agreed upon and configure same
thing on both ends. I feel, there is no problem in expecting the 
configuration to be same on both ends.
Regards
Ravi

-- 

The views presented in this mail are completely mine. The company is not
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page <http://www.roc.co.in>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jul 2003 10:45:08 +0200

-----BEGIN PGP SIGNED MESSAGE-----

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

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

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

]                   At IETF57 in Wien, Austria                  |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[