Subject: [tcpm] possible NAT support for TCP-AO

From: Joe Touch <[email-masked]>
Date: Mon, 13 Jul 2009 13:58:19 -0700

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

---

From: Ron Bonica <[email-masked]>
Date: Mon, 13 Jul 2009 18:59:42 -0400

Joe,

If TCP-AO were for the exclusive use of BGP, I wouldn't worry so much
about NAT. Nobody (to the best of my knowlege) runs BGP across a NAT
boundary.

If TCP-AO is being designed for non-BGP applications also, the tweaks
that Joe describes make perfect sense. They appear to be simple enough
and shouldn't take too long to document.

                                   Ron

> discuss it on the list if possible in advance.
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm
.

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Sat, 25 Jul 2009 12:25:28 -0700

inline...

At 01:58 PM 7/13/2009, Joe Touch wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi, all,
>
>revisit thinking about NATs in the context of the current AO,

I'm not against the idea. I see some issues (see more below). But I 
think it could work. My one big concern is that the BGP community has 
been waiting a VERY long time for this update, and I'd hate to drag 
out a last call, or RFC, for this issue which they don't care much 
about. But I think solving it in the long run is important. As a 
compromise between these two competing needs, might we consider this:
  - proceed to WG LC & RFC without the NAT solution.
  - in parallel, work on text for the NAT solution
  - do a rather quick rev of the first RFC to include the NAT 
solution (and the few bugs I'm sure we'll find as we move to implementations)
??

>which uses

This will be tough, as you won't always know. We could solve this 
later in a KMP system that provides NAT detection, and hands the 
answer down to the TCP stack config (I'm thinking of the way that 
NAT-T for IKE works wrt IPsec/ESP). But it could work.

>                 both on outgoing and incoming MAC calculation

If both directions are behind NATs (a very probably case for 
non-routing protocol usage), then the uniqueness data defining the 
connection is reduced greatly, i.e. only the ISNs remain as unique. 
This affects the entropy of the KDF, where the connection data is 
used as the input to the function, in order to derive the traffic 
keys. If I'm not mistaken, it means that, in the unlikely event that 
the same ISN's are chosen for a different connection 5-tuple, then a 
replay attack could be accomplished.

I can live with that risk trade-off, personally. But I'd want to make 
sure we call it out explicitly the NAT-T section where the mechanism 
is described, and then go into it more completely in the security 
considerations. section.

>         since their input could be limited to the ISN pair in the

I think what I described above fits under this point, if I understood 
Joe's point correctly.

That's my .02, after a very quick read and response,
Gregory.

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 27 Jul 2009 08:55:57 -0700

At Mon, 13 Jul 2009 13:58:19 -0700,
> isn't a particular reason it needs to be prohibited.

So I'm going to jump in right here: it's not in general practical
to know whether you are behind a NAT. That's why the BEHAVE 
NAT discovery document is going to Experimental.

-Ekr

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Jul 2009 09:16:49 -0700

Eric Rescorla wrote:
...
> NAT discovery document is going to Experimental.

You're talking about NAT discovery; this mod doesn't talk about how you
figure that out, just how to support it if you do know it.

You can trivially know it in a key distro protocol if you send your
adr/port in the payload, so that the endpoint can see if it matches what
is on the outside. Granted that won't work in a backward-compatible way
(e.g., for BEHAVE), but key distro protocols don't have that limitation.

Joe