Re: [tcpm] tcp-auth-opt issue: support for NATs

[Joe Touch <[e-mail]>]

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



Adam Langley wrote:
| On Wed, Jul 30, 2008 at 4:40 PM, Joe Touch <[e-mail]> wrote:
|> The current TSAD supports only a wildcard source port, which is
|> instantiated for the first connection received that matches. It expects
|> that the KMS installs additional keys as needed.
|
| I was assuming that the TSAD would support wildcards for source IPs
| and ports. I would also suggest that it's not a bad idea, although if
| it didn't happen, that's no problem.

My impression is that the overall system should support what TCP
supports, i.e., LISTEN on ANY in the same places TCP does. However, once
a connection is established, the connection key is fixed. Note that this
means the TSAD might allow wildcards in places the current draft doesn't
describe.

There are two possible solutions to work over NATs then:

1) install keys that are sufficiently wildcarded AND configure those
keys to ignore the addresses and ports

2) require the KMS to determine the appropriate keys to install on the
two ends, and compute the MAC based on the received socket pair

(I had thus far been assuming #2, FWIW)

<IHO>
#1 appears to have a few potential challenges:
	- once we omit the addresses and ports from the MAC,
	we can't assume that each connection's derived key
	is unique (it would depend only on the ISN pair) within
	a host

	- if keys are shared across a number of hosts,
	derived connection keys aren't unique across
	those hosts either. after an area reboot,
	non-randomized ISN generation might be leveraged
	to enable a replay attack

	- support for NATs assumes keys are installed in
	ways that support NATs
		i.e., the wildcards matter just as much
		as the 'ignore socket pair in MAC' setting

	- support for NATs appears to prohibit keys that
	depend on client addr or source ports, i.e., there
	would be no way to have different keys for different
	groups of clients

|> The above appears to require that the KMS deploy the same key for all
|> potentially overlapping NAT'd connections. This adds a requirement to
|> the KMS, but suggests that the pseudoheader is included or excluded for
|> all connections to a host from a given IP address. Is that what is
|> intended, or can you clarify? If that is what is intended, how can the
|> KMS enforce this?
|
| Indeed, something would have to arrange for the pseudoheader to be
| excluded from the MAC input when a packet matches a wildcard source IP
| rule. Also, the same key would indeed be used by many connections.
| Thus the key should rotate based on the time (once a minute would be
| reasonable.)

Key rotations (presumably you're talking about the master key) may
require some synchronization, which seems unlikely in the case of NATs
as well.

There are a few questions that may be useful to address to move forward:

	- is the use of wildcards/ingore addrs/ports compatible with
	the desire for unique per-connection keys?

	- is it OK to require that all NAT'd clients use the same
	key

	- is it OK to require that support for NATs means
	using wildcard'd keys?

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

iEYEARECAAYFAkiTX/0ACgkQE5f5cImnZrvanQCgmWWXXC76EzaTziol3sQUHavR
aNQAoOZ0qyS0NddQn4qMg5IAj85dFe41
=decj
-----END PGP SIGNATURE-----

_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm