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

[Paul Wouters]

On Tue, 28 Jan 2020, Antony Antony wrote:

>> # 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.

Yes that is the idea. I've tweaked nic's config in all the tests to
ensure it does what is expected, as I found the behaiour changed between
different kernel and fedora versions.

>>> 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'm not too sure when we would want that. I guess you are worried that
nic would re-use a portmapping ? I wrote tests that give road a
different IP to run as "second client", to ensure nic would map the
port differently from the "first client". That seems to work, so based
on that I did not think we needed to know the specific ephemeral port?

I would hope the mobike tests would use actual traffic from actual
different outer IPs for testing, so any ephemeral port mixup would
become clear without needing to look at whether two ephemeral ports had
matched or not ?

>>> 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.

I agree "ipsec look" is often not the best tool to use. Using ipsec
trafficstatus or ip xfrm directly is often better. In fact, I would be
happy to kill "ipsec look" when KLIPS is killed.

>>> 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

You say that, but we did have a bug in xfrm migrate that only affected
AES_GCM, so had we had two tests and found this during testing, it would
have mattered?

But I don't fully understand the argument. Sure some test case output is
huge, but one only needs to be careul creating that reference output.
>From then on, diffs will clearly point to problems (or false positives).
I'm not sure optimizing on using many different sanitizers is less prone
to missing errors or reducing false positives. I guess it is a matter of
taste.

> yes. I am wondering for mobike with NAT tests we should use range bellow 30K
> then it won't be sanitized, because < 30 are not ephemeral.

That will surely cause false positives because kernel implementations
change and you dont always get the same "first port available". So
if you do this you would have to tune nic to NAT to specific dport for
specific source IP/port, but at what point are we no longer testing
"regular NAT" and only testing "our specific NAT hack" ?

Paul