Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Tore Anderson <tore-cDshPT+Y4Rxhl2p70BpVqQ <at> public.gmane.org>
Subject: Nortel interop troubles, an analysis
Newsgroups: gmane.network.ipsec.tools.devel
Date: Thursday 31st May 2007 10:07:54 UTC (over 10 years ago)
Hi.  For some time now, I've struggled with making tunnels to a Nortel
 CES work correctly.  Here's an analysis...

  First off I've had troubles with the ISAKMP phase1 lifetime.  It seems 
 that the Nortel by default has this set to 0:00:00 (a setting that's
 for some reason called "Forced Logoff").  My racoon has this set to 8
 hours. When I initiate the ISAKMP phase1 negotiation, it works fine.
 Nothing worth noting in the log.  After 8 hours racoon expires this SA,
 as expected (all phase2 SAs negotiated from this ISAKMP SA remains).
 However, at some later stage the Nortel wants to start the quick mode,
 using the phase1 SA that was expired a long time ago (and connectivity
 is interrupted).  So it seems the Nortel is operating with a longer
 lifetime than me for the ISAKMP phase1 lifetime - I don't know how
 long (infinite?).  This is an example from the logs (R.R.R.R = racoon,
 N.N.N.N = Nortel - apologies for corporate paranoia):

  May 28 09:22:29 vpn racoon: INFO: ISAKMP-SA established
R.R.R.R[500]-N.N.N.N[500] spi:de7afb9f3c8915a8:7cf340f719c52ded
  May 28 17:22:29 vpn racoon: INFO: ISAKMP-SA expired
R.R.R.R[500]-N.N.N.N[500] spi:de7afb9f3c8915a8:7cf340f719c52ded
  May 28 17:22:30 vpn racoon: INFO: ISAKMP-SA deleted
R.R.R.R[500]-N.N.N.N[500] spi:de7afb9f3c8915a8:7cf340f719c52ded
  May 28 17:51:23 vpn racoon: DEBUG: 436 bytes message received from
N.N.N.N[500] to R.R.R.R[500]
  May 28 17:51:23 vpn racoon: DEBUG: 436 bytes message received from
N.N.N.N[500] to R.R.R.R[500]
  May 28 17:51:23 vpn racoon: ERROR: can't start the quick mode, there is
no ISAKMP-SA, de7afb9f3c8915a8:7cf340f719c52ded:00006a4a
  [repeated several times]
  May 28 17:52:27 vpn racoon: DEBUG: 68 bytes message received from
N.N.N.N[500] to R.R.R.R[500]
  May 28 17:52:27 vpn racoon: ERROR: unknown Informational exchange
received.
  [repeated several times]

  I believe this is misbehaviour from the Nortel, if it doesn't agree
 with my proposed lifetime, it should either fail the negotiation, or
 send a RESPONDER-LIFETIME with the true lifetime, correct?

  In any case, after discovering this I made sure the Nortel and racoon
 both have the phase1 lifetime explicitly set to the same.  This seems
 to work fine, at exactly the same time as I expire the ISAKMP SA, the
 Nortel initiates a new phase1 negotiation.  Splendid...  or so I
 thought.  I am now faced with a new problem - the Nortel wants the
 phase2 lifetime to not exceed the lifetime of the phase1 SA it was
 built from.  In other words:  if there's five minutes left of the
 phase1 SA lifetime, it will propose a lifetime of 300 seconds when
 acting as a initiator, and if acting as a responder, it sends a
 RESPONDER-LIFETIME notification back instead, because racoon just
 proposes my configured 8 hours for phase2 SA lifetime even though
 the phase1 SA expires in just a few seconds.  I guess there's nothing
 wrong with this, the protocols do not require the phase1 SA to be
 present for the phase2 SA to be valid?  And at the same time the Nortel
 has every right to want a shorter lifetime than the one we're
 proposing, right?

  In any case - when the phase1 SA expires, the Nortel removes all
 phase2 SAs based on it too, and since racoon simply ignores the
 RESPONDER-LIFETIME notifications:

  May 31 11:05:14 vpn racoon: INFO: initiate new phase 2 negotiation:
R.R.R.R[0]<=>N.N.N.N[0]
  May 31 11:05:14 vpn racoon: WARNING: ignore RESPONDER-LIFETIME
notification.
  May 31 11:05:14 vpn racoon: INFO: IPsec-SA established: ESP/Tunnel
N.N.N.N[0]->R.R.R.R[0] spi=155216951(0x9406c37)
  May 31 11:05:14 vpn racoon: INFO: IPsec-SA established: ESP/Tunnel
R.R.R.R[0]->N.N.N.N[0] spi=761733962(0x2d67234a)

 ...the SAs ends up having a too long lifetime, and after the phase1 SA
 expires the phase2 SA ends up being a black hole until it expires or is
 manually deleted, or traffic from the other side  causes the Nortel to
 initiate the negotiation of a new phase2 SA pair.  Not good!

  Another shortcoming of racoon is that when a new phase1 is negotiated,
 racoon dismisses the INITIAL-CONTACT notification sent by the Nortel:

  May 31 11:04:11 vpn racoon: INFO: respond new phase 1 negotiation:
R.R.R.R[500]<=>N.N.N.N[500]
  May 31 11:04:11 vpn racoon: INFO: begin Identity Protection mode.
  May 31 11:04:11 vpn racoon: INFO: received Vendor ID: DPD
  May 31 11:04:11 vpn racoon: INFO: IPsec-SA expired: ESP/Tunnel
N.N.N.N[0]->R.R.R.R[0] spi=11535084(0xb002ec)
  May 31 11:04:11 vpn racoon: INFO: IPsec-SA expired: ESP/Tunnel
N.N.N.N[0]->R.R.R.R[0] spi=135903178(0x819b7ca)
  May 31 11:04:11 vpn racoon: WARNING: ignore INITIAL-CONTACT notification,
because it is only accepted after phase1.
  May 31 11:04:11 vpn racoon: INFO: ISAKMP-SA established
R.R.R.R[500]-N.N.N.N[500] spi:25005afb4728be1e:d20526fd3898f2b2

  I am not sure if the INITIAL-CONTACT is sent too early for racoon to
 verify its authenticity of not, however, as I've stated in bug
 #1705814, it should anyway be able to store it and act on it
 immediately after the phase1 SA is completely established.  I assume
 that should be sufficient protection against DoS issues?

  To summarise, I belive there are two shortcomings of racoon that
 cause these problems:

  1) Lack of support for RESPONDER-LIFETIME - if racoon adjusted the
     lifetime of phase2 SAs according to the Nortel's wishes, they would
     expire at the same time the phase1 SA did, and therefore new SAs
     would be negotiated using a new phase1 SA at the expected time.  No
     loss of connectivity would occur.

  2) Lack of support or inadequate handling of INITIAL-CONTACT - if
     racoon had deleted all SAs related to the initiator upon receipt of
     such notifications, the too-long-lived blackhole SAs would be
     removed, and a new pair would be negotiated.  Again, no loss of
     connectivity would occur.

  I believe implementing either of these would solve the problems - if
 you have a continous stream of traffic originating at the Nortel side.
 If not, it will probably not initiate a new phase1 negotiation and
 there will be no INITIAL-CONTACT to kill off the too-long-lived SAs.
 RESPONDER-LIFETIME is therefore priority #1 to fix - however
 INITIAL-CONTACT is also good to handle correctly in the case where the
 peer is restarted or similar before phase1 has expired, or where the
 RESPONDER-LIFETIME notification is lost
 (draft-ietf-ipsec-ike-lifetime-00.txt warns of this possibility).

  Comments on whether my analysis is correct or not is greatly
 appreciated.

  I am offering a bounty of USD $500 for a patch implementing these
 features (granted that the code quality is good enough for inclusion in
 an upcoming ipsec-tools release - preferably the next 0.7 beta).

  An alternative approach would be to implement a feature where racoon
 acts just like the Nortel;  proposing phase2 SA lifetimes that's either
 the configured one or one that lasts until the phase1 SA expires,
 whichever is shorter.  That would just be nice to have, though.

Regards
-- 
Tore Anderson

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
 
CD: 15ms