Hi Paul,
Thank you very much for your feedback. I'm happy to see my thoughts are in line
with you experts.
> > 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.
Yes, you're right. I misused the word, "continue" isn't the right expression. I
just want to say "the responder should reply INVALID_KE_PAYLOAD and shouldn't
terminate without reply".
Regards & Thanks！
Wei PAN (潘伟)
> -----Original Message-----
> From: Paul Wouters <[email protected]>
> Sent: Tuesday, February 6, 2024 3:01 AM
> To: Panwei (William) <[email protected]>
> Cc: [email protected]
> Subject: Re: [IPsec] What's the most reasonable way for the responder to
> handle the request containing unknown Key Exchange methods
>
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
