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