[Swan-dev] symmetry vs Robustness Principle

[D. Hugh Redelmeier]

The Robustness Principle from RFC 1122:
                "Be liberal in what you accept, and
                 conservative in what you send"

Here's a tricky case.

Apparently, when the ipsec.conf specifies "aes", for example, we take
it to mean:
	propose AES 128 (bug: 256 for ESP)
but
	accept AES 128, 192, or 256

That sure looks as if it is an application of the robustness
principle.  I'll try to show that it isn't.

Consider a case where the other side can only do AES 128 (probably due
to configuration).  They can successfully initiate with our side.  But
then when, for some reason (perhaps rekeying), we wish to initiate, we
will fail.

It would be better to fail to interoperate the first time because that
will be less mysterious.  It would be better to fail reliably because
that will be easier to debug.

So: I think that, by default, all policies should be symmetric.  In
particular, a notation for cyphers suites should cause libreswan to
propose and accept the same set of cyphers.

There are two ways to fix the "aes" case.

1. change libreswan so that "aes" means "aes at all supported
keylengths" in both proposal and acceptance.

2. change libreswan so that "aes" means "aes at the single default
keylength" in both proposal and acceptance.

ipsec.conf(5) says:
	"Any left out option will be filled in with all allowed
	default options."
This seems to be unclear and ambiguous.  I'm used to there only being
one default, but the word "all" suggests that there is more than one.
So: does it mean "all allowed" or "default"; both at once don't make
any sense.

The argument against 1 is that it would cause the IKEv2 proposal
payload to explode in size.  I don't know how bad this is (worth
figuring it out).

The argument against 2 is that it would cause a change in meaning for
existing ipsec.conf files (on the responder side).  I think that this
is mostly theoretical (it would have no effect on libreswan to
libreswan connections unless only one side specified a non-default
keysize).  Furthermore, any breakage would occur when an upgrade
happened, the time when a sysadmin would most likely be attentive.

If silent change is unacceptable, then we should implement:

2b. change libreswan so that "aes" is no longer accepted.  The key
size must be specified, and will not be defaulted.  This way admins
are forced to upgrade ipsec.conf and there is no silent change.

I think that leaving the status quo is unreasonable.