[strongSwan-dev] Aggressive mode

Tobias Brunner tobias at strongswan.org
Thu Oct 8 13:31:03 CEST 2015

Hi Srini,

> The initiator end point complaining that HASH_R is not right. It is
> saying the protocol and port fields are set to '0' (Zero) when HASH_R
> is calculated. The responder endpoint is using strongSwan. When
> strongSwan send its response, the initiator is complaining that
> protocol and port fields are set to ZERO in HASH_R calculation.

That's perfectly fine.  RFC 2407 explicitly states:

  "During Phase I negotiations, the ID port and protocol fields MUST be
   set to zero or to UDP port 500."

So setting these to zero is definitely correct.  To me setting a
protocol and port only makes sense when using ID payloads to negotiate
traffic selectors during Quick Mode.  IKEv2 also removed these fields
from the ID payload and, of course, introduced a separate payload to
negotiate traffic selectors.

However, it doesn't really matter what is in these fields as the HASH
calculation includes the raw binary encoding of the ID payload, as
defined in RFC 2409:

  "The entire ID payload (including ID type, port, and protocol but
   excluding the generic header) is hashed into both HASH_I and HASH_R."

So even if they don't expect the fields to be zero the calculated HASH
should be the same on both peers.  Any assertion that requires the port
and protocol fields to be 500 and 17, respectively, and not allowing
them to be zero is simply wrong.


More information about the Dev mailing list