Thanks Yoav. If responder chooses to decline it, then does it force the fallback on tunnel mode? I am asking this because sometime back I had a doubt regarding the following lines in RFC 5996.
" If responder declines the request, the Child SA will be established in tunnel mode. If this is unacceptable to the initiator, the initiator MUST delete the SA." It seemed to me that this was implementation's choice to establish the SA in tunnel mode or send "NO_PROPOSAL_CHOSEN" in this case. -- Regards, Hema From: Yoav Nir <[email protected]<mailto:[email protected]>> Date: Thursday, 12 November 2015 12:47 pm To: Hema Tripathi <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [IPsec] Clarification regarding USE_TRANSPORT_MODE notification Hi, Hema USE_TRANSPORT_MODE is a notification, so it is outside the structures in the SA payload. As a consequence, the protocol does not allow you to propose AES-GCM in transport mode or ChaCha20/Poly1305 in tunnel mode. Note also that USE_TRANSPORT_MODE does not force transport mode. It only shows support. The responder can then choose to include it (agreeing to use transport mode) or not (forcing you back to tunnel). And yes, notifications were not supposed to be used for negotiations. HTH, Yoav On 12 Nov 2015, at 8:59 AM, Hema Tripathi (hetripat) <[email protected]<mailto:[email protected]>> wrote: Hi, I have a doubt regarding USE_TRANSPORT_MODE in IKEv2. Does this apply to complete SA offer(s) or to each proposal in the SA? In case of multiple proposals, should they be negotiated on the basis of the mode configured for that proposal? Or should all SA offers adhere to same mode? - Regards, Hema _______________________________________________ IPsec mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
