From: SourceForge.net <no...@so...> - 2007-04-23 12:06:48
|
Bugs item #1705814, was opened at 2007-04-23 14:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1705814&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 0.6 branch Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tore Anderson (toreanderson) Assigned to: Nobody/Anonymous (nobody) Summary: INITIAL-CONTACT interop issues with Cisco and Nortel Initial Comment: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1705814&group_id=74601 |
From: SourceForge.net <no...@so...> - 2007-04-23 12:30:19
|
Bugs item #1705814, was opened at 2007-04-23 05:03 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1705814&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 0.6 branch Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tore Anderson (toreanderson) Assigned to: Nobody/Anonymous (nobody) Summary: INITIAL-CONTACT interop issues with Cisco and Nortel Initial Comment: 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-04-23 05:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1705814&group_id=74601 |
From: SourceForge.net <no...@so...> - 2007-04-23 13:05:36
|
Bugs item #1705814, was opened at 2007-04-23 14:03 Message generated for change (Comment added) made by toreanderson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1705814&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 0.6 branch Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tore Anderson (toreanderson) Assigned to: Nobody/Anonymous (nobody) Summary: INITIAL-CONTACT interop issues with Cisco and Nortel Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Tore Anderson (toreanderson) Date: 2007-04-23 15:05 Message: 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-04-23 14:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1705814&group_id=74601 |
From: SourceForge.net <no...@so...> - 2009-01-09 06:22:49
|
Bugs item #1705814, was opened at 2007-04-23 15:03 Message generated for change (Settings changed) made by fabled80 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1705814&group_id=74601 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 0.6 branch >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tore Anderson (toreanderson) >Assigned to: Timo Teräs (fabled80) Summary: INITIAL-CONTACT interop issues with Cisco and Nortel Initial Comment: 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 ---------------------------------------------------------------------- Comment By: Timo Teräs (fabled80) Date: 2009-01-09 08:22 Message: 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. ---------------------------------------------------------------------- Comment By: Tore Anderson (toreanderson) Date: 2007-04-23 16:05 Message: 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 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-04-23 15:30 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=541482&aid=1705814&group_id=74601 |