On Mon, 5 Feb 2024, Panwei (William) wrote:
Regarding how the responder handles the request containing the new Key Exchange
methods (old name was DH
Group) that it doesn’t understand, I’ve had a discussion with someone, but we
failed to agree with each other
due to different interpretations of RFC 7296. I’d like to hear more opinions
from you experts.
The handling I suggest is as follows:
1) if all KE methods proposed by the initiator are unknown to the
responder, i.e., no KE method is
acceptable, then the responder replies NO_PROPOSAL_CHOSEN, no matter what KE
method is used in the KE payload.
2) if at least one acceptable KE method is included in the initiator’s
proposals, the responder can select
one acceptable KE method, ignore the unknown KE methods, and perform the next
step of KE Payload processing.
2.1) if the KE method used in the KE payload happens to be the same as
this selected KE method, then
the responder normally replies with this selected KE method and the
corresponding KE payload.
2.2) if the KE method used in the KE payload is different from this
selected KE method, then the
responder replies INVALID_KE_PAYLOAD with this selected KE method, regardless
of whether the KE method used in
the KE payload is known or unknown to the responder.
that is correct. Note that the INVALID_KE_PAYLOAD can also contain the
KE method(s) the responder is willing to use.
This paragraph indicates that the responder should ignore the unknown KE
methods in the SA payload because the
new KE methods can be considered as new Transform Attributes.
Yes, it should ignore unknown KEs. This allows newer software/versions
to attempt newer KEs without breaking with older implementations that
do not support the newer KEs.
If the responder selects a
proposal using a different Diffie-Hellman group (other than NONE),
the responder will indicate the correct group in the response and the
initiator SHOULD pick an element of that group for its KE value when
retrying the first message.
I guess that SHOULD is a little odd. It really means "it should pick one
from the responder list, that falls within its own local policy as valid
to use, otherwise it must terminate the connection".
This paragraph indicates that the initiator can suggest a KE method regardless
of whether it is known to the
responder.
IKE assumes both peers do not know each others capabilities before the
negotiation starts.
The latter sentence indicates that the responder can continue the negotiation
when the KE method in
the KE payload is unknown and just needs to reply INVALID_KE_PAYLOAD with the
correct KE method.
No, it cannot "continue". INVALID_KE_PAYLOAD is an errror. If this is
sent in the IKE_SA_INIT reply, the responder isn't even expected to keep
any state. The initiator has to "start from scratch" using a different
KE method. The responder responds "from scratch" to that message.
However, others suggest that the responder should terminate the IKE exchange
without reply, when the KE method
used in the KE payload is unknown to the responder, even if there are other
acceptable KE methods proposed in
the SA payload.
One must NEVER terminate without sending a reply. Doing so only causes
the initiator to retransmit its packet, thinking the packet was dropped.
It will only make things worse. Always reply. But in the case of
INVALID_KE_PAYLOAD, the responder can get away with not keeping (or even
creating) state.
Because they feel the unknown KE method in the KE payload means that the whole
packet is an invalid packet,
and discarding this packet is the thing to do.
That is wrong :)
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
