Hello Raj, You still need the IDr and AUTH payloads in the reply. This is needed as INVALID_SYNTAX is authenticated and encrypted.
Regards, Matt 2009/4/22 raj singh <rsjen...@gmail.com> > 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
