[tcpm] possible NAT support for TCP-AO

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, all,

Based on a discussion on a different list with Dan Wing, I'd like to
revisit thinking about NATs in the context of the current AO, which uses
traffic keys derived from the socket pair and ISN pair. We might be able
to now support NATs as follows, e.g.:

	add the following flags to the MKT:

		localNAT flag - indicates whether the local IP/port are
			zeroed before MAC calculation

		remoteNAT flag - indicates whether the remote IP/port
			are zeroed before MAC calculation

	add steps to the incoming/outgoing processing:
		zero the corresponding IP/port when the flag indicates,
		both on outgoing and incoming MAC calculation

That's basically it. A client behind a NAT would have a MKT with
localNAT true, and a server for that client would need to have a MKT
with remoteNAT true. This does require careful MKT configuration.
Although I wouldn't expect both localNAT and remoteNAT to be true, there
isn't a particular reason it needs to be prohibited.

Here's the security impact:

	- no impact to other connections (AFAICT)

	- SYN/SYN-ACKs limited only as much as the MKT TCP connection
	ID is, i.e., as a small range or single value rather than
	wildcard for either address or port

	- connections are reasonably well-protected once established,
	much like BTNS (due to use of both ISNs in the traffic keys)

	- reduced entropy for the traffic keys from a given MKT,
	since their input could be limited to the ISN pair in the
	worst case

I did NOT include this in TCP-AO-05, but it's simple enough to add if
useful. I'd like to ask that we think about this before Stockholm, and
discuss it on the list if possible in advance.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpbn+sACgkQE5f5cImnZru8uwCeLaty+1z8+Qnrzg8L3G82SFO0
4WEAoJ00Ww9omlO9ggb58lW064tDMqxl
=3Z2o
-----END PGP SIGNATURE-----