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

From: Joe Touch <[email-masked]>
Date: Wed, 30 Jul 2008 16:09:50 -0700

Adam Langley raised the issue of support for NATs.

The TSAD is indexed by the socket pair of the incoming/outgoing packet
(addr/port pair). There is no provision for a separate key identifier
that would be unique across all connections.

As a result, the KMS must populate the TSAD with the appropriate
connection information - it must know the source/dest used at both
endpoints, even if they differ.

<individual contributor hat on>
(I should have indicated this in some parts of other posts, FWIW)

Suppose they do differ; the KMS could then put both sides' views of the
src/dst info on each side's TSAD:
	src/dst addr/port as sent
	src/dst addr/port as rec'd

The TSAD would be indexed by the "as sent" info, but the MAC would be
calculated using the "as rec'd" info.

<hat off>

Should the document:

a) require the socket pair info always be included in the MAC, i.e., be
protected

b) allow a TSAD entry to indicate that the socket pair is excluded from
the MAC?

Finally, does (b) help, given the current keying requirements?

Comments?
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Adam Langley" <[email-masked]>
Date: Wed, 30 Jul 2008 16:22:47 -0700

> Finally, does (b) help, given the current keying requirements?

My assumption was that the TSAD could return the same keyset for all
addresses and source ports going to a given destination/port pair. As
an example, a listening socket could be configured such that one could
only connect to it if one knew a key. (Standard proviso's here: the AO
key itself should be a time rotating, secure derived key from the
master secret). If one didn't have the key, not even a SYNACK would be
sent in reply. Once a connection has been established, then the keys
for that connection's 4-tuple can change independent of the wildcard
keys.

If that's a use case that the spec wishes to support, then having an
option to exclude the pseudo-header and TCP port numbers from MAC
protection would allow these connections to traverse NATs.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Jul 2008 16:40:24 -0700

Adam Langley wrote:
| On Wed, Jul 30, 2008 at 4:09 PM, Joe Touch <[email-masked]> wrote:
|> Should the document:
|>
|> a) require the socket pair info always be included in the MAC, i.e., be
|> protected
|>
|> b) allow a TSAD entry to indicate that the socket pair is excluded from
|> the MAC?
|>
|> Finally, does (b) help, given the current keying requirements?
|
| My assumption was that the TSAD could return the same keyset for all
| addresses and source ports going to a given destination/port pair. As
| an example, a listening socket could be configured such that one could
| only connect to it if one knew a key. (Standard proviso's here: the AO
| key itself should be a time rotating, secure derived key from the
| master secret). If one didn't have the key, not even a SYNACK would be
| sent in reply. Once a connection has been established, then the keys
| for that connection's 4-tuple can change independent of the wildcard
| keys.
|
| If that's a use case that the spec wishes to support, then having an
| option to exclude the pseudo-header and TCP port numbers from MAC
| protection would allow these connections to traverse NATs.

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.

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?

---

From: "Adam Langley" <[email-masked]>
Date: Thu, 31 Jul 2008 17:00:09 -0700

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

> intended, or can you clarify? If that is what is intended, how can the

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

AGL