[Swan-dev] sanitizer and ephemeral ports .. Re: [Swan-commit]
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.
> Now we are sanitizing sport and dport when it is not default, however, for
> some tests like mobike it is not a good idea.
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
> 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.
> 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.
> 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
> 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
The port comes from:
iptables -t nat -L -n | grep 22.214.171.124 || iptables -t nat -A
POSTROUTING -s 126.96.36.199/32 -p udp -j SNAT --to-source
188.8.131.52:33000-34000 && iptables -t nat -A POSTROUTING -s
184.108.40.206/32 -j SNAT --to-source 220.127.116.11
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.
>  has iptables SNAT started assigning random ports?
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
More information about the Swan-dev