[Spud] Types of flow pattern and NAT impact?

[Phillip Hallam-Baker <[e-mail]>]

Different applications have different flow patterns and the
differences make a difference when it comes to a middlebox deciding
when to tear down a NAT association or the endpoints are striving to
keep it open.

I think it is useful to enumerate the various flow patterns and to
take into account that these are typically directed. In the home
network we have 1-150 IP addresses on one side and one IP address on
the other. In the enterprise or 'carrier grade NAT' setting we have a
larger pool of IP addresses that are being mapped to, but the choice
of address within a pool is typically random.


While it is possible to use multiple layers of NAT and even NAT that
does not involve Internet addresses at all, I find it easiest to get
my head round a problem thinking in terms of a 'local' network and the
'remote' and to focus on the NAT box on the local side. For many
interesting cases (peer to peer voip, audio, etc) we will have NAT
boxen on both sides of course.


There are two basic cases:

1) The communication session is initiated by the local party
2) The communication session is initiated by the remote party

The second case requires some form of Port Control (e.g. RFC6887)
which is an explicit interaction with the local NAT (or else how does
the first packet know where to go?). But this does not mean that there
is no SPUD implication as SPUD traffic might well be an implicit keep
alive on the port control.


For message types, I see an important distinction between idempotent
and statefull sessions. There are some protocols where UDP is used to
effect a stateless interaction with one server from a pool, which
server is chosen does not matter.

The main use for an idempotent UDP interaction is of course DNS. But
fast idempotent protocol is useful in many other circumstances: OCSP
lookup, Peer-to-peer discovery, content routing, certificate
directories, key servers etc. etc.

The DNS protocol limits transactions to a single request and a single
response. Fitting a request into one UDP packet is much easier than
fitting a response into one packet. So an idempotent UDP transaction
might consist of one request packet followed by 0-16 (say) response
packets.

There is obviously a limit to the number of packets that can be
returned without some sort of mechanism to detect and retransmit
dropped packets which will require state. And obviously in the modern
internet, any stateless service that requires any significant effort
and does not authenticate requests is going to result in wailing and
gnashing of teeth as it gets DoSed or used as an attack proxy.


For stateful flows we can have one tube or many. But is that something
the NAT box needs to know about? If not, I want the data in my
encrypted payload.