ikev1: Properly handle different proposal numbering schemes
authorTobias Brunner <tobias@strongswan.org>
Fri, 15 Aug 2014 13:57:22 +0000 (15:57 +0200)
committerTobias Brunner <tobias@strongswan.org>
Fri, 12 Sep 2014 11:55:00 +0000 (13:55 +0200)
commit84337ac8d035a5e61bd2d87dd223af14ac8b5988
tree22fff8ad8ab65e6c2b7a27b49516de4519a689a0
parent90e6675a657c4ffdebc39b23f64922bad81bcc03
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.
src/libcharon/encoding/payloads/sa_payload.c