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

This text is related to existing NAPT44 behavior, where a mapping
is kept active so long as there is an inside->outside flow (which
makes sense, and is usually 15-30 seconds) and is kept active longer 
if there is an outside->inside response (which makes sense, too,
and is usually ~3 minutes).  The next characteristic is that the 
NAT shouldn't keep a mapping alive if there is solely and only
an outside->inside flow.  This is discussed (but with a focus on
RTP flows) in draft-ietf-avt-app-rtp-keepalive, and the best
reference is probably REQ-6 of RFC4787.

Would it be helpful to add a citation to "Section 4.3 of [RFC4787]" 
during that document's AUTH48?

(The wording should be tweaked, anyway, from "MAY choose not to
extend" to "MAY choose to not extend".)

-d