[Swan-dev] sanitizer and ephemeral ports .. Re: [Swan-commit]

Andrew Cagney andrew.cagney at gmail.com
Sun Jan 26 02:41:39 UTC 2020


On Sat, 25 Jan 2020 at 15:29, Antony Antony <antony at phenome.org> wrote:
>
> First, I noticed sanitizers have improved a lot. Thanks.
>
> I know iptable change was discused a while ago[1].
>
> Now we are sanitizing sport and dport when it is not default, however, for
> some tests like mobike it is not a good idea.

No.

The old sanitizers did that - they sanitized any port with 4 or more
digits.  Mostly.  Maybe.  I suspect this was because any port >1024
was once considered ephemeral.

Now,  like the comment says:

# ephemeral ports
# - according to IANA: 49152-65535
# - according to Linux: 32768-61000
# the below matches 30000-.. which is good enough

we're sanitizing anything >=32k (ok, technically, 30k :-) because it
_is_ ephemeral.

> I am still thinking how to change the tests to preserve the ports when we
> want them to, and sanitize when we should not care. I guess using different
> NAT port ranges would help. I red the comments in ephemeral-ports.sed.
>
> Andrew,www
> I have a feeling the following commit along with other ephemeral-ports.sed
> changes have gone a bit too far some tests.
>
> We should keep ports of ip xfrm state in mobike and few other tests, crypto
> values are not important in mobike. That is why it is not an "ipsec look".
> Also ip xfrm state is called several times in those tests, "ipsec look"
> output would be too long and we are likely to overlook changes/regression.
>
> https://testing.libreswan.org/v3.28-1508-gca5c702fb3-master/ikev2-mobike-06/OUTPUT/east.console.diff
>
> eg these are not important in mobike
> +       replay-window 32 flag af-unspec
> +       auth-trunc hmac(sha256) 0xHASHKEY 128

otoh they do no harm and bring things into line with other tests.
like the comment points out:

# Paul: this is _crazy_, nothing is ephemeral here so it completely breaks
#       everything that tries to use this. It seems like it tried to fixup
#       older kernel vs newer kernel ip xfrm output or something ????

and a grep shows we're down to two tests (and they don't appear in
TESTLIST anyway):

testing/pluto/ikev2-68-sa-clones-auto-route/testparams.sh:REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS
ip-xfrm.sed"
testing/pluto/ikev2-68-sa-clones-null-iperf/testparams.sh:REF_CONSOLE_FIXUPS="$REF_CONSOLE_FIXUPS
ip-xfrm.sed"

> this line should be there.
> +       encap type espinudp sport 4500 dport EPHEMERAL addr 0.0.0.0

> I have a feeling that dport EPHEMERAL is important in this test and
> shouldn't be sanitized. I will take a closer look when working on the
> sanitizer.

The port comes from:

   iptables -t nat -L -n | grep 192.1.33.222 || iptables -t nat -A
POSTROUTING -s 192.1.33.222/32 -p udp -j SNAT --to-source
191.1.2.250:33000-34000 && iptables -t nat -A POSTROUTING -s
192.1.33.222/32 -j SNAT --to-source 192.1.2.250

which is ephemeral - i.e., above 32k and random.

> I will try to fix them, however, do not want to fight with your changes.
>
> I think, some how the ephemeral ports should kept in mobike tests. Which
> possibly means on nic specify NAT sports to be bellow 30K?
> if nic has narrow range, with 2 or 3 ports then mobike tests should get
> predicable port.  Atleast that is the theory we will see.
>
> May be revert this commit for mobikes tests?

Now I'm confused.  If ip-xfrm.sed is re-instated, the above line will
be deleted.  So is that above line important or not?


> On Fri, Jan 24, 2020 at 03:56:45PM +0000, Andrew Cagney wrote:
> > New commits:
> > commit 66e89c481c051c30a2ef0fe2d905702fa4344523
> > Author: Andrew Cagney <cagney at gnu.org>
> > Date:   Fri Jan 24 10:43:25 2020 -0500
> >
> >     testing: avoid optional ip-xfrm.sed sanitizer
> >
> >     Let sanitizers such as guest-ip-xfrm-state.sed deal with command
> >     specific sanitization.
> >
> >     Follow-up e03853f86d6deb1078a59515329ed7cbf136cfad.
>
> PS:
> [1] has iptables SNAT started assigning random ports?
> https://www.mail-archive.com/swan-dev@lists.libreswan.org/msg03376.html
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev


More information about the Swan-dev mailing list