At 9:48 AM +0300 2/4/10, Valery Smyslov wrote: >These two paragraphs are left from previous version and >should be removed (now all they are talking about is explained >in more details below).
There were bits in those two paragraphs that were still new, but on further looking, I see that those bits appear (sometimes many times) in the rest of the document. I'll remove them. > > There are some cases in which a node receives a packet that it cannot >> process, but it may want to notify the sender about this situation. >> >> o If an ESP or AH request or response packet arrives with an > >There are no "requests" and "responses" in ESP and AH. >Just remove these words. Whoops, good call. > > unrecognized SPI. This might be due to the receiving node having >> recently crashed and lost state, or because of some other system >> malfunction or attack. >> >> o If an encrypted IKE request packet arrives on port 500 or 4500 >> with an unrecognized IKE SPI. This might be due to the receiving >> node having recently crashed and lost state, or because of some >> other system malfunction or attack. >> >> o If an IKE request packet arrives with a higher major version >> number than the implementation supports. >> >> 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 > >s/Informational/INFORMATIONAL Also good call. (I hate the way we still use all caps for this for no good reason, and I guess that colors my writing...) > >> 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 > >Probably s/informational/Informational ? I'm not sure because the >term "Informational Message" is never formally introduced in the document >apart from this section... Actually, it is introduced in 1.4: "Note that some informational messages, not exchanges, can be sent outside the context of an IKE SA." > > 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). 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 > >s/Informational/INFORMATIONAL Yes > > > > 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 > >Shouldn't the first letter in "There" be lower case 't'? Yes > > > 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. > >In is not said which Exchange Type should be set in Informational Message >(one may of course guess that it is INFORMATIONAL, but I think it is better >to spell out this explicitly). I would think *not* INFORMATIONAL because we just said "this is not part of an INFORMATIONAL exchange". Having said that, I have no idea what to use instead. What do others think? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
