At 11:54 AM +0200 12/16/09, Tero Kivinen wrote: >Paul Hoffman writes: >> At 2:26 PM +0100 12/14/09, Matthew Cini Sarreo wrote: >> >Hello all, >> > >> >A minor technical note about Issue #22. Section 2.25, last paragraph reads: >> > >> >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer >> >receives a request to rekey a Child SA that does not exist. A peer >> >that receives a CHILD_SA_NOT_FOUND notification SHOULD silently >> >delete the Child SA and send a request to create a new Child SA >> >from scratch. >> > >> >The original text does not mention what the SPI should be (it is >> >practially implied what it should be set to, but is still not >> >mentioned in the text). Presumably one would set the this to be the >> >SPI of the Child SA that caused the error (i.e the data for >> >CHILD_SA_NOT_FOUND is the same as the SPI found inside the REKEY_SA >> >notification). This way, the Initiator knows which rekeying attempt >> >resulted in this error. > >For initiator it is clear already because this error notification is >always used as reply to the CREATE_CHILD_SA request, i.e. initiator >already matches this with the corresponding request by the message id >fields. > >Because of this the SPI field is not necessarily needed. > >> >I would propose to change this text to: >> >A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer >> >receives a request to rekey a Child SA that does not exist. The SA >> >that the initiator attempted to rekey is indicated by the SPI field >> >in the Notify Payload, which is copied from the SPI field in the >> >REYEY_SA notification. A peer that receives a CHILD_SA_NOT_FOUND >> >notification SHOULD silently delete the Child SA and send a request >> >to create a new Child SA from scratch. >> >> It is always good to make this kind of thing explicit. I will add >> this to the next draft. > >This would be ok, but would not be enough. We also have text in the >section 3.10 saying that only INVALID_SELECTORS and REKEY_SA has SPI >field, so this new CHILD_SA_NOT_FOUND needs to be added to there too. > >We have decided the SPI is filled to the SPI field when it refers to >EXISTING SPI. For example the INVALID_SPI notification does not fill >the SPI field, as the SPI field refers to the SPI that is not known by >the responder. See text in section 3.10 under Protocol ID. > >This is similar case, i.e. the responder of who gets the REKEY_SA >notification with unknown SPI does not have Child SA with that SPI, >thus SPI is unknown for him, and because of that I think it is better >for NOT to fill in the SPI field of the CHILD_SA_NOT_FOUND error. As >the exchange where this error refers to is clear from the context (it >is reply to the rekey request), there is no need to include SPI >anywhere.
This all seems like a compelling argument. However: >Because of that I suggest we do not add that text but instead add >sentense saying: > > As CHILD_SA_NOT_FOUND error refers to unknown SPI from the > responders point of view, it does not fill in the SPI field of the > CHILD_SA_NOT_FOUND error notification. Instead it sets the protocol > ID to zero and leaves SPI field empty. If the sender of the CREATE_CHILD_SA is going to match the response by the Message ID, then I do not see why we should make the new rule about the values for the protocol ID and SPI. I would have thought that you were going to suggest something like: Because the CHILD_SA_NOT_FOUND error refers to an SPI that the responder does not recognize, it does not know what to fill in for the SPI field of the error. Therefore, the initiator SHOULD ignore the SPI field in the response and instead base its actions on the Message ID. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
