Paul Hoffman writes: > 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:
That is not a new rule, that is standard rule for the Notification payloads. If you do not have existing SPI then you put Protocol ID to zero and do not fill in the SPI field. I.e. section 7.8 of the RFC4718. I originally thought that we do not need to put anything there as I expected everybody to understand that as we do not have valid SA then we do not fill in the SPI field, but as people might interpret this differently I think we need some text. > 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. I think it is better to mandate actions of the one who creates the Notication payload, not the one who receives it. So I would leave the last sentence away and only keep the first one, but as someone commented that actually responder do know about the SPI, as the SPI was sent to him in the REKEY_SA notification, so he could copy it from there to this error. Because if this I think it is better to be more explicit: Because the CHILD_SA_NOT_FOUND error refers to an SPI that the responder does not recognize, it does not fill in SPI in the CHILD_SA_NOT_FOUND error notification. I do not think we need anything to express how initiator can know which of his requests failed when he gets error response back to one of them... It should be clear for everybody that if your request gets error response back, it was that request that failed. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
