[strongSwan] strongswan/L2TP and NAT-T transport with both NATed
Andreas Steffen
andreas.steffen at strongswan.org
Tue Dec 14 10:54:01 CET 2010
Hello Benoit,
RFC 3947 "Negotiation of NAT-Traversal in the IKE" does not specify
explicitly whether the additional NAT-OA payloads must be part of
the hash:
>----------------------------------------------------------------------
The following example is of Quick Mode using NAT-OA payloads:
Initiator Responder
------------ ------------
HDR*, HASH(1), SA, Ni, [, KE]
[, IDci, IDcr ]
[, NAT-OAi, NAT-OAr] -->
<-- HDR*, HASH(2), SA, Nr, [, KE]
[, IDci, IDcr ]
[, NAT-OAi, NAT-OAr]
HDR*, HASH(3) -->
----------------------------------------------------------------------<
but the IKEv1 RFC 2409 specifies in section 5.5 "Phase 2 - Quick Mode":
>----------------------------------------------------------------------
Quick Mode is defined as follows:
Initiator Responder
----------- -----------
HDR*, HASH(1), SA, Ni
[, KE ] [, IDci, IDcr ] -->
<-- HDR*, HASH(2), SA, Nr
[, KE ] [, IDci, IDcr ]
HDR*, HASH(3) -->
Where:
HASH(1) is the prf over the message id (M-ID) from the ISAKMP header
concatenated with the entire message that follows the hash including
!! ^^^^^^^^^^^^^^^^^
all payload headers, but excluding any padding added for encryption.
HASH(2) is identical to HASH(1) except the initiator's nonce-- Ni,
minus the payload header-- is added after M-ID but before the
complete message. The addition of the nonce to HASH(2) is for a
liveliness proof. HASH(3)-- for liveliness-- is the prf over the
value zero represented as a single octet, followed by a concatenation
of the message id and the two nonces-- the initiator's followed by
the responder's-- minus the payload header. In other words, the
hashes for the above exchange are:
HASH(1) = prf(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | SA | Nr [ | KE ] [ | IDci |
IDcr )
HASH(3) = prf(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)
With the exception of the HASH, SA, and the optional ID payloads,
there are no payload ordering restrictions on Quick Mode. HASH(1) and
HASH(2) may differ from the illustration above if the order of
!! ^^^^^^^^^^
payloads in the message differs from the illustrative example or if
any optional payloads, for example a notify payload, have been
!! ^^^^^^^^^^^^^^^^^^^^^
chained to the message.
----------------------------------------------------------------------<
Thus in my opinion strongSwan is correct in including the optional
NAT-OA payloads in the HASH and racoon is wrong in not doing so.
Best regards
Andreas
On 14.12.2010 10:04, Benoit Foucher wrote:
> Hi Victor,
>
> I found a workaround for this INVALID_HASH_INFORMATION error by
> hacking strongSwan's code but I doubt it's really correct (and I'm
> running into another issue after :(). The problem is that raccoon and
> strongSwan don't compute the HASH on the same data (raccoon doesn't
> includes NAT-OA in the hash computation whereas strongSwan does).
>
> See:
>
> https://lists.strongswan.org/pipermail/users/2010-December/005712.html
>
> It would be good to figure out whether or not this is a strongSwan
> or raccoon issue. If it's the later I'll submit a bug where
> appropriate.
>
> Cheers, Benoit
>
======================================================================
Andreas Steffen andreas.steffen at strongswan.org
strongSwan - the Linux VPN Solution! www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==
More information about the Users
mailing list