Hi Matt/Youv, Thanks for your reply. I will conclude as IKE_AUTH exchange MUST have TSi and TSr payload. We MUST NOT process IKE_AUTH packet without TSi and TSr and we should reply with INVALID_SYNTAX notification without IDr, AUTH, TSi and TSr payloads.
Regards, Raj On Wed, Apr 22, 2009 at 1:11 PM, Yoav Nir <y...@checkpoint.com> wrote: > Hi Raj > > Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, and > then wait for traffic to establish the child SAs. > > While we do establish an IKE SA if the piggy-backed child SA failed for > whatever reason (bad selectors, no proposal chosen), we don't allow for an > IKE_AUTH exchange that is missing the child payloads. > > An IKE_AUTH request without the TSi and TSr payloads is > considered malformed, and so MUST NOT be processed. Instead, you should > reply with INVALID_SYNTAX > > As to question 2, the text refers to a child SA creation that failed, not > to one that was never attempted. > > Of course it is possible to generate that effect - propose non-existant > cryptographic algorithms, or IPv7 addresses in the selectors, but that IMO > is a misuse of the protocol. > > Yoav > > Raj Singh wrote: > > Hi Matt, > > Let me re-phrase my questions: > 1. If there is no TSi and TSr payload in IKE_AUTH exchange, whether we go > ahead and process IKE_AUTH payloads or not ? > 2. Appendix C: IKE_AUTH: Error in CHILD SA creation. It will come into > picture if we process the packet. > If we go ahead and process the packet, according to appendix C, we > SHOULD/MUST establish the IKE SA ? > Looks like, if we go ahead to process the IKE_AUTH packet with no TSi > and TSr, we can establish the IKEv2 SA. > > I request more experts to comment. > > Thanks for your reply. > > Regards, > Raj > > On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo <mci...@gmail.com>wrote: > >> Hello Raj, >> >> According to Appendix C, for IKE_AUTH: >> >> error in Child SA <-- IDr, [CERT+], >> creation AUTH, >> N(error), >> [V+] >> >> So sending an authenticated and encrypted INVALID_SYNTAX notification over >> the IKE_SA that has just been authenticated seems to be correct. >> >> Regards, >> Matt >> >> >>> >>> 2009/4/22 raj singh <rsjen...@gmail.com> >>> >>>> Hi Matt, >>>> >>>> There is possibility of just IKEv2 SA gets established during IKE_AUTH >>>> and IPsec SA getting established via CREATE_CHILD_SA. >>>> The question is what behavior RFC mandate ? What you think ? >>>> >>>> Thanks for your reply. >>>> >>>> Regards, >>>> Raj >>>> >>>> >>>> On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo <mci...@gmail.com >>>> > wrote: >>>> >>>>> In IKE_AUTH TSi and TSr are mandatory, so it is not possible to omit >>>>> them from an authentication exchange message, as there would be no way for >>>>> the SA to know what traffic should be forwarded through the SA. >>>>> >>>>> It seems that the correct error message would be INVALID_SYNTAX. This >>>>> would require the message ID and the checksum to be valid. Note that this >>>>> has (may only) be sent in an encrypted response. >>>>> >>>>> Please correct me if I am wrong. >>>>> >>>>> Regards, >>>>> Matt >>>>> >>>>> >>>>>> 2009/4/22 raj singh <rsjen...@gmail.com> >>>>>> >>>>>>> Hi Group, >>>>>>> >>>>>>> What is the expected behavior if as a responder we do not receive TSi >>>>>>> and TSr in IKE_AUTH exchange ? >>>>>>> Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out >>>>>>> TSi and TSr ? >>>>>>> Or we should reject the packet ? >>>>>>> If we reject the packet during packet validation with doing ID and >>>>>>> AUTH payload processing, what ERROR should be send ? >>>>>>> >>>>>>> Thanks, >>>>>>> Raj >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> IPsec mailing list >>>>>>> IPsec@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ipsec >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > > Email secured by Check Point > >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
