#61 INITIAL-CONTACT interop issues with Cisco and Nortel

0.6 branch
closed-fixed
None
5
2009-01-09
2007-04-23
No

Whenever peers that are Cisco and Nortel boxes reboots
or whatever, the sessions initiate like this example:

Apr 23 12:14:26 enigma racoon: INFO: respond new phase 1 negotiation: me.me.me.me[500]<=>they.they.they.they[500]
Apr 23 12:14:26 enigma racoon: INFO: begin Identity Protection mode.
Apr 23 12:14:26 enigma racoon: INFO: received broken Microsoft ID: FRAGMENTATION
Apr 23 12:14:26 enigma racoon: INFO: received Vendor ID: CISCO-UNITY
Apr 23 12:14:26 enigma racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
Apr 23 12:14:26 enigma racoon: INFO: received Vendor ID: DPD
Apr 23 12:14:26 enigma racoon: INFO: ISAKMP-SA established me.me.me.me[500]-they.they.they.they[500] spi:5968e9d943e31169:34974409390288bf
Apr 23 12:14:26 enigma racoon: INFO: respond new phase 2 negotiation: me.me.me.me[500]<=>they.they.they.they[500]
Apr 23 12:14:26 enigma racoon: WARNING: ignore INITIAL-CONTACT notification, because it is only accepted after phase1.
Apr 23 12:14:26 enigma racoon: INFO: IPsec-SA established: ESP/Tunnel they.they.they.they[0]->me.me.me.me[0] spi=229642964(0xdb012d4)
Apr 23 12:14:26 enigma racoon: INFO: IPsec-SA established: ESP/Tunnel me.me.me.me[0]->they.they.they.they[0] spi=2398888562(0x8efc2272)

Racoon ignores the INITIAL-CONTACT that are sent, and I was told on the mailing list that this is done because the message is received so early that it could well be a forgery / DoS attempt.

However, this makes the old SAs remain in place, and outgoing traffic ends up being encrypted with a SA that the peer no longer recognize, at least for some of the SPs (which all have unique SAs). The tunnel remains
defunct until some incoming traffic results in the establishement of a newer SA that are subsequently used, or until lifetime is reached.

Seeing how there's a lot of Ciscos and Nortels out there it's a problem that these notifications are dismissed out of hand. To me it seems much better if early INITIAL-CONTACT notifications is stored in memory, but acted on only after the negotiations has progressed long enough for to verify that is is authentic. I would think that should solve the interop
issues while not opening up a DoS possibility?

Regards
Tore Anderson

Discussion

  • Nobody/Anonymous

    Logged In: NO

    Hi.

    Looks like your INITIAL-CONTACT is sent AFTER the phase1, so there is a proble somewhere, it should be accepted (or there is something very specific in your peer's configuration).

    I just had a quick look at that check, and also saw where the function is called, and I guess your peer sends the INITIAL-CONTACT in a quick mode message.
    I'll have a deeper look at the code to be sure that I can just remove the check in that situation and I'll also have to check that this is RFC compliant (I guess it is).

    Yvan.

     
  • Tore Anderson

    Tore Anderson - 2007-04-23

    debug from ignored initial contact

     
  • Tore Anderson

    Tore Anderson - 2007-04-23

    Logged In: YES
    user_id=637473
    Originator: YES

    Oh, I thought it was simply that it was sent too early for racoon. I'm attaching the debug output from the above exchange up until the point where the INITIAL-CONTACT is recieved, in case that might help you verify your suspicions (it's getting above my understanding of the IPSEC protocols, unfortunately).

    I doubt there's something very special in the configuration, I see this happening with both Nortels and Ciscos installed at separate clients and I doubt they've both done something special, and in my end the configuration is quite simple:

    remote they.they.they.they {
    exchange_mode main;
    proposal {
    encryption_algorithm aes;
    hash_algorithm sha1;
    authentication_method pre_shared_key;
    dh_group modp1024;
    }
    proposal_check obey;
    generate_policy off;
    lifetime time 8 hour;
    }

    sainfo address x.x.x.x/x[any] any address y.y.y.y/y[any] any {
    encryption_algorithm aes;
    authentication_algorithm hmac_sha1;
    compression_algorithm deflate;
    lifetime time 8 hour;
    }

    (repeated for various values of x and y.)

    Kind regards
    Tore Anderson
    File Added: debug.txt

     
  • Timo Teras

    Timo Teras - 2009-01-09

    Thank you for the bug report. A fix has been committed to CVS HEAD branch and we'll be included in next major release of ipsec-tools.

     
  • Timo Teras

    Timo Teras - 2009-01-09
    • assigned_to: nobody --> fabled80
    • status: open --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks