Andrew Cagney writes: > > Also the section 3.10 of RFC7296 says: > > > > o Protocol ID (1 octet) - If this notification concerns an existing > > SA whose SPI is given in the SPI field, this field indicates the > > type of that SA. For notifications concerning Child SAs, this > > field MUST contain either (2) to indicate AH or (3) to indicate > > ESP. Of the notifications defined in this document, the SPI is > > included only with INVALID_SELECTORS, REKEY_SA, and > > CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be > > sent as zero and MUST be ignored on receipt. > > I assume we're not discussing 0 or 1(IKE). Which should be dismissed with > INVALID_SYNTAX 7 > Indicates the IKE message that was received was invalid because > some type, length, or value was out of range or because the > request was rejected for policy reasons.
REKEY_SA is only used when rekeying Child SAs, i.e., it is NOT used when rekeying IKE SA. > I like the principal. As things go forward and exchanges for new > protocols are defined they each get to spell out the details of things > like the proposal sub payload > and how to extract the Child's identifying material from the REKEY_SA. > > Several things trouble me: > > The first is that the RFC only defines how to extract the child's > identifier for ESP and AH vis: > > o SPI Size (1 octet) - Length in octets of the SPI as defined by the > IPsec protocol ID or zero if no SPI is applicable. For a > notification concerning the IKE SA, the SPI Size MUST be zero and > the field must be empty. > > which means that for a completely unknown protocol I'm left assuming > the notify body is ESP/AH like (is SPI length = 8 reasonable? Is SPI > length = 0 with a 32k blob reasonable?). > (I understand one implementation sends back an empty child-not-found > notify, which at least avoids the need to parse the body). If someone proposed to rekey protocol id that the receiving end does not support, it means the other end is broken and is not following the RFC. There is no way there could be and unknown protocol id already negotiated between the peers if this peer does not recognize the protocol id. So either option is correct, either return CHILD_SA_NOT_FOUND and copy protocol id, spi size, and spi from the REKEY_SA, or return INVALID_SYNTAX and tear down the IKE SA. Receiving unknown protocol id in rekey sa is clearly a bug in the other ends implementation so it does not really matter what you are doing, the other end should fix their code... > The second is that the peer is trying to rekey a Child SA that can > never exist. Any attempt to establish this new unknown protocol > should have failed as the proposal sub-payload containing the unknown > protocol would be ignored. I view that as pretty broken, or worse. Yes. > Hence, when the protocol is completely unknown I se invalid-syntax as > being an equally valid response. In some implementations I know the policy of what protocol ids were known and what kind of SPIs they are using was passed to the policy module, i.e., the IKE module would never return that protocol id would not be valid, as it did not know which protocol ids are valid and which are not. The policy module was doing that checking. In such cases it would be logical to the policy module to return CHILD_SA_NOT_FOUND error. Note, that the policy module could be dynamically loaded, and there could have been support for such protocol id earlier (for example before reboot and updating the system). If the policy module and IKE is tightly integrated, meaning that IKE will immediately known that this protocol id cannot exists, thus it can return INVALID_SYNTAX if it feels like it. We usually do not mandate specific error codes to be used, as different implementations can have different ways of checking things. I.e. one implementation might do lookup based on protocol id + spi without checking protocol id at all, and if no such match is found it will return CHILD_SA_NOT_FOUND. Only after passing that it would start looking actual value of the protocol id... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
