Re: [BEHAVE] Very late query on stateful NAT64

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Brian E Carpenter
> Sent: Thursday, October 21, 2010 6:26 PM
> To: Dave Thaler
> Cc: Se-young Yu; [e-mail]
> Subject: Re: [BEHAVE] Very late query on stateful NAT64
> 
> On 2010-10-22 13:38, Dave Thaler wrote:
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> Behalf
> >> Of Brian E Carpenter
> >> Sent: Thursday, October 21, 2010 3:48 PM
> >> To: [e-mail]
> >> Cc: Se-young Yu
> >> Subject: [BEHAVE] Very late query on stateful NAT64
> >>
> >> Hi,
> >>
> >> The security considerations of the RFC-to-be draft-ietf-behave-v6v4-
> xlate-
> >> stateful-12
> >> include this:
> >>
> >>>    Another consideration related to NAT64 resource depletion refers
> to
> >>>    the preservation of binding state.  Attackers may try to keep a
> >>>    binding state alive forever by sending periodic packets that
> refresh
> >>>    the state.  In order to allow the NAT64 to defend against such
> >>>    attacks, the NAT64 MAY choose not to extend the session entry
> >>>    lifetime for a specific entry upon the reception of packets for
> that
> >>>    entry through the external interface.
> >> How does the NAT64 distinguish between malicious keep-alives and
> genuine
> >> packets of a one-way UDP flow of some kind? We don't see how this
> can be
> >> implemented.
> >
> > My understanding is that this is no different from stateful NAT44...
> > Many NAT44s require packets in the outbound direction in order to
> keep
> > the mapping alive.  So you can have a one-way UDP flow in the
> outbound
> > direction just fine.  But if you want a one-way UDP flow in the
> inbound direction,
> > this will time out and break unless you periodically send something
> in the
> > outbound direction.   Not all NATs do this, but some do.   Hence the
> MAY.
> 
> Hmmph. MAY implies that this is reasonable behaviour. I'd have
> preferred to
> see this phrased as a warning about possible misbehaviour by NATs,
> rather
> than as a permitted "security" mechanism. Well, it isn't worth calling
> the document back from the RFC Editor for this, but I would have
> argued the point if I'd been aware of it earlier.
> 
> This is yet another reason why people are misusing HTTP to carry real
> time
> streaming data, I suppose: NATs might arbitrarily interrupt legitimate
> UDP streams.

HTTP (over TCP) has these very convenient TCP ACKs which indicate
the (internal) host enjoyed consuming the data.

If for a UDP flow the internal host doesn't burp a UDP packet 
occasionally, the NAT has no indication the internal host is alive, 
cared, wanted, or enjoyed the data.  The NAT has to destroy the UDP 
state at some point, or else its state table is full of incoming
UDP flows for movies or whatever content was being UDP streamed
long after the receiving system crashed or was disconnected from
the network.

-d