Subject: [IPsec] IKEv1 Interop issue: Transform number mismatch

From: dharmanandana pothulam <[email-masked]>
Date: Tue, 9 Sep 2014 16:23:44 +0000

Hi All,

We are facing one IKEv1 interop issue. The issue is that Responder (checkpoint SeGW) not retaining the

transform numbers received from the initiator (huawei base station), SeGW replies with its own transform number.

IKEv1 First & second packets:

Initiator                                                     Responder
-------------                                                -------------
VID, SA         ------------------------------>                            (1)

            <-----------------------------             VID, SA             (2)

In our scenario, Huawei base station(Initiator) sending transform number as 0 and Checkpoint security gateway(Responder)

is replying with 1, And Initiator trying to match transform number received from the responder with one of the numbers sent

initially and negotiation failing due to mismatch.

We did Interop test with Cisco and Juniper, Cisco and Juniper is retaining the transform numbers sent by the Huawei base station,

and negotiation successful.

Huawei base station compares received transform number with one of the transform numbers sent initially along with other attributes,

this is inline with the RFC 2408 section 4.2 statement (The initiator MUST verify that the Security Association payload received from

the responder matches one of the proposals sent initially).

One more point rfc says “The responder SHOULD retain the Proposal # field in the Proposal payload and the

Transform # field in each Transform payload of the selected Proposal".

As I understand This transform number helps to direct to the correct SA attributes in initiator side.

why some vendors not retaining the transform number sent by initiator? if not followed, Do we see usefulness of the transform

number received at initiator side? Can we drop the exchange if correct transform number not received?

Regards,

Dharma.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 10 Sep 2014 08:56:12 +0000

Hi, Dharma.

This mailing list is intended for discussion of standards, not the conformance (or lack thereof) of particular implementations.

I will contact you off-list

Yoav

From: IPsec [mailto:[email-masked]] On Behalf Of dharmanandana pothulam
Sent: Tuesday, September 09, 2014 7:24 PM
To: [email-masked]
Cc: Sameer varshney; Liangjicheng
Subject: [IPsec] IKEv1 Interop issue: Transform number mismatch

Hi All,

Initiator                                                     Responder

One more point rfc says "The responder SHOULD retain the Proposal # field in the Proposal payload and the

Regards,

Dharma.

Email secured by Check Point.

Email secured by Check Point

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Sep 2014 13:52:09 +0300

dharmanandana pothulam writes:
> We are facing one IKEv1 interop issue. The issue is that Responder
> (checkpoint SeGW) not retaining the transform numbers received from
> the initiator (huawei base station), SeGW replies with its own
> transform number.

IKEv1 was obsoleted by IKEv2 in 2005, you should try to work on
supporting current IPsec, not something that was obsoleted almost ten
years ago...

> Huawei base station compares received transform number with one of
> the transform numbers sent initially along with other attributes,
> this is inline with the RFC 2408 section 4.2 statement (The
> initiator MUST verify that the Security Association payload received
> from the responder matches one of the proposals sent initially).

That check is really only meant to check the actual proposal
information, i.e. the cipher selected is one of the proposed one,
transform # or proposal # are not part of that check. The idea of the
check is to make sure that the selected proposal is something that is
acceptable by the initiator policy.

> One more point rfc says “The responder SHOULD retain the Proposal #
> field in the Proposal payload and the Transform # field in each
> Transform payload of the selected Proposal".

Which clearly says that they can also be different. So initiator can
use those numbers to quickly see which of the hundred proposal was
selected, but if they do not match, you still need to do full check
and find if any of the proposals you sent matches the incoming
proposal.

> SA attributes in initiator side.

Yes, it can be used as optimization, but as other end is not mandated
to return same number, you can only use it as optimization and if that
optimization fails, you need to do full search. 

> why some vendors not retaining the transform number sent by
> initiator? if not followed, Do we see usefulness of the transform

That I cannot answer. Most likely because of the old code structure or
similar, and as we are talking about the protocol obsoleted almost ten
years ago, I do not expect vendors to be very interested in changing
their products now. So if interoperability with obsoleted protocol
with all vendors is requirement for you, then you need to do full
search when check with the transform number fails. 

Note, also that another funny thing about IKEv1 is that it says that
those numbers need to be "monotonically increasing numbers". That
means that they do not need to be incremented by one, valid numbers
can also be 1, 4, 66, 213... There are implementations out there that
do also that, and also the first number can be 0, 1 or any other
value...

In IKEv2 this was fixed so that first proposal number must be 1, and
they must increment by one, and responder must return same proposal
number back. In IKEv2 there is no transform numbers as transform
substructure is quite different.
-- 
[email-masked]