[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