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. > >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. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
