On Wed, 2009-03-11 at 13:24 +0100, [email protected] wrote: > Hmm... it seems Tero is right; since the SPI is in the notification > data (not the "SPI" field of the Notify payload), the "Protocol ID" > field would be zero, and the recipient doesn't know whether the SPI > was for ESP or AH. > > I think Tero's proposal about just noting this fact (i.e. not > changing how this work) would be OK and sufficient.
I could be missing something, but RFC4301, section 4.1 allows implementations to use the SPI in conjunction with the IPsec protocol for SA identification. So, if someone is in that latter case, wouldn't they have a problem? > > > -----Original Message----- > > From: Yaron Sheffer > > Sent: 03 March, 2009 20:18 > > To: [email protected] > > Subject: [IPsec] Issue #35: INVALID_SPI: does the SPI determine the > > protocol (ESP/AH)? > > > > 1.5. Informational Messages outside of an IKE_SA > > > > ... > > > > {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE > > INFORMATIONAL exchange when a node receives an ESP or AH packet with > > an invalid SPI. The Notification Data contains the SPI of the > > invalid packet. This usually indicates a node has rebooted and > > forgotten an SA. If this Informational Message is sent outside the > > context of an IKE_SA, it should only be used by the recipient as a > > 'hint' that something might be wrong (because it could easily be > > forged). > > > > Tero: > > > > If the notification data is used for the SPI of the invalid packet, > > how can the recipient of such notify know whether that SPI was for > > ESP or AH? As far as I can see, it cannot, but I think it does not > > matter as SPIs are now supposed to be unique (i.e. protocol is no > > loger include as key). Perhaps we should just note this fact here? > > > > Paul: Not done. This is interesting, but should be discussed on the list. > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
