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. > As I understand This transform number helps to direct to the correct > 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 > number received at initiator side? Can we drop the exchange if > correct transform number not received? 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 protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
