On Fri, Jun 24, 2022 at 08:05:30PM +0800, Wei Han wrote:
> On Thu, Jun 23, 2022 at 09:36:41PM +0200, Pablo Neira Ayuso wrote:
[...]
> > > + } else {
> > > + return false;
> > > + }
> > > + } else if (proto == IPPROTO_ESP) {
> > > + //not NAT-T
> > > + eh = skb_header_pointer(skb, par->thoff, sizeof(_esp), &_esp);
> > > + if (!eh) {
> > > + /* We've been asked to examine this packet, and we
> > > + * can't. Hence, no choice but to drop.
> > > + */
> > > + pr_debug("Dropping evil ESP tinygram.\n");
> > > + par->hotdrop = true;
> > > + return false;
> > > + }
> >
> > This is loose, the user does not have a way to restrict to either
> > ESP over UDP or native ESP. I don't think this is going to look nice
> > from iptables syntax perspective to restrict either one or another
> > mode.
> >
> This match original purpose is check the ESP packet's SPI value, so I
> think the user maybe not need to pay attention that the packet is
> ESP over UDP or native ESP just get SPI and check it, this patch is
> only want to add support for get SPI in ESP over UDP.And the iptables rules like:
> "iptables -A INPUT -m esp --espspi 0x12345678 -j ACCEPT"
This rule would be now allowing UDP traffic to go through, even if the
user does not need it. An explicit policy entry to allow NAT-T would
be preferred.
There is another issue, although I suppose there is a standard UDP
port for this, user might decide to select a different one, in that
case, this would break. And I don't see an easy way to allow user to
select the UDP port in the iptables case.
