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
