- /*
- * Here, we do not do "siz1 == siz". This is because the way
- * RFC240[34] section 2 is written. They do not require truncation
- * to 96 bits.
- * For example, Microsoft IPsec stack attaches 160 bits of
- * authentication data for both hmac-md5 and hmac-sha1. For hmac-sha1,
- * 32 bits of padding is attached.
- *
- * There are two downsides to this specification.
- * They have no real harm, however, they leave us fuzzy feeling.
- * - if we attach more than 96 bits of authentication data onto AH,
- * we will never notice about possible modification by rogue
- * intermediate nodes.
- * Since extra bits in AH checksum is never used, this constitutes
- * no real issue, however, it is wacky.
- * - even if the peer attaches big authentication data, we will never
- * notice the difference, since longer authentication data will just
- * work.
- *
- * We may need some clarification in the spec.
- */
- if (siz1 < siz) {
- ipseclog((LOG_NOTICE, "sum length too short in IPv4 AH input "
- "(%lu, should be at least %lu): %s\n",
- (u_int32_t)siz1, (u_int32_t)siz,
- ipsec4_logpacketstr(ip, spi)));
- IPSEC_STAT_INCREMENT(ipsecstat.in_inval);
- goto fail;
- }
- if ((ah->ah_len << 2) - sizoff != siz1) {
- ipseclog((LOG_NOTICE, "sum length mismatch in IPv4 AH input "
- "(%d should be %lu): %s\n",
- (ah->ah_len << 2) - sizoff, (u_int32_t)siz1,
- ipsec4_logpacketstr(ip, spi)));
- IPSEC_STAT_INCREMENT(ipsecstat.in_inval);
- goto fail;
- }