diff options
| author | Tobias Brunner <tobias@strongswan.org> | 2014-08-15 15:57:22 +0200 |
|---|---|---|
| committer | Tobias Brunner <tobias@strongswan.org> | 2014-09-12 13:55:00 +0200 |
| commit | 84337ac8d035a5e61bd2d87dd223af14ac8b5988 (patch) | |
| tree | 22fff8ad8ab65e6c2b7a27b49516de4519a689a0 /src/libcharon/plugins/eap_dynamic/eap_dynamic_plugin.c | |
| parent | 90e6675a657c4ffdebc39b23f64922bad81bcc03 (diff) | |
| download | strongswan-84337ac8d035a5e61bd2d87dd223af14ac8b5988.tar.bz2 strongswan-84337ac8d035a5e61bd2d87dd223af14ac8b5988.tar.xz | |
ikev1: Properly handle different proposal numbering schemes
While the examples in RFC 2408 show proposal numbers starting at 1 and
increasing by one for each subsequent proposal this is not mandatory.
Actually, IKEv1 proposals may start at any number, the only requirement
is that the proposal numbers increase monotonically they don't have to
do so consecutively.
Most implementations follow the examples and start numbering at 1 (charon,
racoon, Shrew, Cisco, Windows XP, FRITZ!Box) but pluto was one of the
implementations that started with 0 and there might be others out there.
The previous assumption that implementations always start numbering proposals
at 0 caused problems with clients that start numbering with 1 and whose first
proposal consists of multiple protocols (e.g. ESP+IPComp).
Fixes #661.
Diffstat (limited to 'src/libcharon/plugins/eap_dynamic/eap_dynamic_plugin.c')
0 files changed, 0 insertions, 0 deletions