Re: [BEHAVE] Very late query on stateful NAT64

[Dave Thaler <[e-mail]>]

> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]]
> Sent: Thursday, October 21, 2010 6:26 PM
> To: Dave Thaler
> Cc: [e-mail]; Se-young Yu
> 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.

I think you're probably right.

Some related data (not quite the same thing) is at
http://www.ietf.org/proceedings/78/slides/behave-8.pdf
slide 8.  This shows the timeout that the NATs surveyed use in approximately
the scenario you mention.  The fact that the test used increasing delay implies
that they might all indeed refresh the state (i.e. not misbehave as you put it), but
since that wasn't tested directly it's hard to say. 

Maybe we can get the Nokia Research Center guys to run this test with the NATs
they have?

-Dave