Paul Hoffman writes: > At 2:07 PM +0200 2/8/10, Tero Kivinen wrote: > >Paul Hoffman writes: > >> In the first case, if the receiving node has an active IKE SA to the > >> IP address from whence the packet came, it MAY send an INVALID_SPI > >> notification of the wayward packet over that IKE SA in an > >> Informational exchange. The Notification Data contains the SPI of > >> the invalid packet. The recipient of this notification cannot tell > >> whether the SPI is for AH or ESP, but this is not important because > >> the SPIs are supposed to be different for the two. If no suitable > >> IKE SA exists, the node MAY send an informational message without > >> cryptographic protection to the source IP address, using the source > >> UDP port as the destination port if the packet was UDP (IKE or UDP- > > ^^^^^^^ > >> encapsulated ESP or AH). > > > >Remove the "IKE or" part, as we are still talking about ESP/AH packet > >which has unknow SPI. It cannot be IKE packet. > > Got it; fixed. However: > > >Perhaps better to > >change the whole sentence to: > > > > If no suitable IKE SA exists, the node MAY send an informational > > message without cryptographic protection to the source IP address. > > If the incoming ESP or AH packet was UDP-encapsulated, then node > > needs to use NAT-T IKE format and IP addresses and UDP ports from > > the headers are reversed and used for return informational > > message. > > This is another significant technical change. If you think it is > important, please open a new issue for it.
I do not consider it as techincal change, it just changes the wording a bit to make it easier to understand. The current text already specifies same thing, I just copied text bit more from section 3.1 to say that IP addresses and UDP protss are reversed. This is the only way to get the informational exchange back, so I do not think anybody will make mistake there, so if you feel that it is techinal change then feel free to leave it as it is. Implementors will implement things the same way regardless. > > > > > > >> In this case, it should only be used by the > >> recipient as a hint that something might be wrong (because it could > >> easily be forged). This message is not part of an Informational > >> exchange, and the receiving node MUST NOT respond to it because doing > >> so could cause a message loop. The message is constructed as > >> follows: There are no IKE SPI values that would be meaningful to the > >> recipient of such a notification; using zero values or random values > >> are both acceptable, this being the exception to the rule in > >> Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator > >> flag is set, the Response bit is set to 0, and the version flags are > >> set in the normal fashion. > > > >I think we should explictly mention that Exchange Type of that messge > >is set to "INFORMATIONAL". > > Please see my previous message on this topic. I do not understand > how we can say both "this message is not part of an INFORMATIONAL > Exchange" *and* "mark the Exchange Type as INFORMATIONAL". I am not > saying it is inherently wrong, just that it is confusing. For > example, I could see choosing IKE_SA_INIT just as easily, given that > this message is not part of an INFORMATIONAL Exchange. No, we cannot select IKE_SA_INIT, as that has very specific payloads which can be in it, and the Notify payload is not one of them. On the other hand in the packet having exchange type of INFORMATIONAL can have notifications inside. I do expect that everybody will only process those notifications if they are inside packet having exchange type of INFORMATIONAL. In a sense they look like INFORMATIONAL exchange, but they are not INFORMATIONAL exchange, as only one half of the actual exchange is included, i.e the first request packet and there is no reply. INFORMATIONAL exchange consist of two packets having exchange type of INFORMATIONAL in their header (i.e. two INFORMATIONAL messages one request and one reply). The header of this section is "Informational Messages outside of the IKE SA". -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
