netdev - Re: [devel-ipsec] [PATCH net 1/1] xfrm: fix source address in icmp error generation from IPsec gateway

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <26127.60594.628257.929728@fireball.acr.fi>
Date: Fri, 5 Apr 2024 15:21:06 +0300
From: Tero Kivinen <kivinen@....fi>
To: Michael Richardson <mcr@...delman.ca>
Cc: Antony Antony <antony@...nome.org>,
    Herbert Xu <herbert@...dor.apana.org.au>,
    netdev@...r.kernel.org,
    David Ahern <dsahern@...nel.org>,
    devel@...ux-ipsec.org,
    Eric Dumazet <edumazet@...gle.com>,
    Jakub Kicinski <kuba@...nel.org>,
    Paolo Abeni <pabeni@...hat.com>,
    "David S. Miller" <davem@...emloft.net>
Subject: Re: [devel-ipsec] [PATCH net 1/1] xfrm: fix source address in icmp
 error generation from IPsec gateway

Michael Richardson via Devel writes:
> 
> Antony Antony <antony@...nome.org> wrote:
>     > Indeed, 10.1.3.2 does not match the policy. However, notice the "flag
>     > icmp" in the above line. That means the policy lookup will use the
>     > inner payload for policy lookup as specified in RFC 4301, Section 6,
>     > which will match. The inner payload 10.1.4.1 <=> 10.1.4.3 will match
>     > the policy.
> 
> How is "flag icmp" communicated via IKEv2?
> Won't the other gateway just drop this packet?

It is not specified in IKE, it is mandated by the RFC4301 section 6.2: 
----------------------------------------------------------------------
6.2.  Processing Protected, Transit ICMP Error Messages
...
   If no SA exists that would carry the outbound ICMP message in
   question, and if no SPD entry would allow carriage of this outbound
   ICMP error message, then an IPsec implementation MUST map the message
   to the SA that would carry the return traffic associated with the
   packet that triggered the ICMP error message.  This requires an IPsec
   implementation to detect outbound ICMP error messages that map to no
   extant SA or SPD entry, and treat them specially with regard to SA
   creation and lookup.  The implementation extracts the header for the
   packet that triggered the error (from the ICMP message payload),
   reverses the source and destination IP address fields, extracts the
   protocol field, and reverses the port fields (if accessible).  It
   then uses this extracted information to locate an appropriate, active
   outbound SA, and transmits the error message via this SA.  If no such
   SA exists, no SA will be created, and this is an auditable event.

   If an IPsec implementation receives an inbound ICMP error message on
   an SA, and the IP and ICMP headers of the message do not match the
   traffic selectors for the SA, the receiver MUST process the received
   message in a special fashion.  Specifically, the receiver must
   extract the header of the triggering packet from the ICMP payload,
   and reverse fields as described above to determine if the packet is
   consistent with the selectors for the SA via which the ICMP error
   message was received.  If the packet fails this check, the IPsec
   implementation MUST NOT forwarded the ICMP message to the
   destination.  This is an auditable event.
-- 
kivinen@....fi