Sorry for typos. Please find re-phrased sentance below: In your example, there is error in construction of SA2, TSi or TSr payloads in IKE_AUTH response. Which also means either the implementation is not RFC compliant or system in bad state at responder. As explained below, in this case mandatory payload check for IKE_AUTH will pass, but individual payload verification check will fail. So IKE SA should *NOT* be processed and INVALID_SYNTAX notify should be send. The responder which is not RFC compliant will DELETE its IKE SA, after it's lifetimes expiry or liveness check.
Thanks & Regards, Raj On Sun, Sep 6, 2009 at 6:39 AM, Raj Singh <rsjen...@gmail.com> wrote: > Hi Keith, > > It has been already discussed on the list that each exchange has some > mandatory payload types. > Firstly, the exchange packet should be checked that it contains all > mandatory payload for that exchnage > then it should check each payload before actually processing the packet. > > In your example of is because of SA2, TSi or TSr, then IKE SA should be > processed and INVALID_SYNTAX notify should be send. > > Thanks & Regards, > Raj > > On Sat, Sep 5, 2009 at 12:54 AM, Keith Welter <welt...@us.ibm.com> wrote: > >> >> > Re: [IPsec] Fw: Issue #26: Missing treatment of error cases >> > >> > Then I should have explained better. >> > >> > If an initiator sees an error in the response, the exchange is already >> over, so the >> > only way it can notify the responder of the error, is to create a new >> INFORMATIONAL >> > exchange with an error notification. >> > >> > All the text here discusses the one INFORMATIONAL exchange that >> immediately follows >> > the IKE_AUTH exchange. If that contains an INVALID_SYNTAX, it relates to >> the >> > response to the IKE_AUTH exchange, and it means that the creation of the >> IKE SA failed. >> In this case, the INVALID_SYNTAX could relate to the SA, TSi or TSr >> payload in the >> IKE_AUTH response which would would mean that creation of the CHILD SA >> failed, >> not the IKE SA. I think INVALID_SYNTAX is ambiguous here without an >> explicit delete >> payload for either the IKE SA or the CHILD SA. >> >> > >> > In any other place, such as a CCSA or an INFORMATIONAL, or in an >> INFORMATIONAL >> > that follows one of those exchanges, an INVALID_SYNTAX just means that >> the previous >> > message was ignored. >> > >> > On Sep 4, 2009, at 7:26 PM, Keith Welter wrote: >> > >> > >> > > >>> In an IKE_AUTH >> > > >>> exchange, or in the subsequent INFORMATIONAL exchnage, only the >> >> > > >>> following notifications cause the IKE SA to be deleted or not >> > > >>> created, without a DELETE payload: >> > > >>> o UNSUPPORTED_CRITICAL_PAYLOAD >> > > >>> o INVALID_SYNTAX >> > > >>> o AUTHENTICATION_FAILED >> > > >>> >> > > >>> Extension documents may define new error notifications with >> these >> > > >>> semantics, but MUST NOT use them unless the peer is known to >> > > >>> understand them. >> > > >> >> > > >> In subsequent INFORMATIONAL exchanges the >> UNSUPPORTED_CRITICAL_PAYLOAD >> > > >> should not be fatal. It only means that the responder ignored the >> > > >> whole message and replied with UNSUPPORTED_CRITICAL_PAYLOAD. That >> does >> > > >> not delete IKE SA. >> > > >> >> > > >> For the IKE_AUTH the UNSUPPORTED_CRITICAL_PAYLOAD can delete the >> IKE >> > > >> SA as IKE SA is not yet ready. >> > > > >> > > >That's what I meant. I will clarify this. >> > > I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted >> either. >> > Actually, my last statement was overly simplistic. I should have said >> that >> > there is at least one case when I would not expect INVALID_SYNTAX to >> cause >> > the IKE SA to be deleted; specifically, when it is included in a >> > CREATE_CHILD_SA exchange. However, I wonder if it is sufficient for an >> > INVALID_SYNTAX in an INFORMATIONAL exchange to cause an IKE SA to be >> deleted >> > without including a delete payload for the IKE SA. It seems potentially >> >> > ambiguous what an implementation should do if an INFORMATIONAL message >> > contains only INVALID_SYNTAX whereas the addition of a delete payload >> for >> > the IKE SA makes the situation clear. >> > >> > Keith Welter >> > IBM z/OS Communications Server Developer >> > 1-415-545-2694 (T/L: 473-2694) >> > >> > >> > Scanned by Check Point Total Security Gateway. >> > >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
