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

[Joe Touch <[e-mail]>]

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



Eric Rescorla wrote:
...
|> | Because the side doing the passive open doesn't know which client
|> | is connecting and it may have multiple instances of the same key-id?
|> | I don't understand the purpose of the time. Just do trial verifications
|> | with each key.
|>
|> That's a reason we have a keyID, which, together with the socket pair,
|> should exactly specify what key to use and avoids this sort of trial. If
|> we can live with trials, we can remove the keyID and things align much
|> better.
|
| Yes, but this only works if you either (1) know the address of
| peers in advance or (2) never assign the same key-id to two
| different peers.

<indiv hat on>

If we require the socket pair, then the keyID need be unique only within
a connection, and we should never need to test different keys -- even
with key rollover, the key used should be deterministic.

Supporting NATs can be done in two different ways:

1. require the KMS to determine the socket pair as received, and
calculate the hash based on the as-received values

	this does not require testing different keys, but puts
	additional burden on the KMS

2. require a mode where the socket pair is not included in the MAC

	this will require testing different keys,
	it also requires the KMS install keys in certain ways
	(i.e., wildcarded on source port and dest IP addr, at least)

I have not yet seen a reason to support secure transport connections for
NAT'd devices made on this list. If there isn't, perhaps it'd be
preferable to leave the protocol simpler and just not support NAT mode.

Alternately, perhaps we could note that there could be modes where
certain header fields are excluded, but that this would be described in
a separeate extension - i.e., not in this doc.

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

iEYEARECAAYFAkibQHoACgkQE5f5cImnZrsetwCeNaexL5o20oxq5ay5wT+oi1i2
D80AoKRr37bq5NPnsz+iKEBuD6OzFow6
=9ACi
-----END PGP SIGNATURE-----
_______________________________________________
tcpm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcpm