Re: [BEHAVE] Very late query on stateful NAT64

Hello ,

Comments inline.

On 10/21/10 6:25 PM, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
wrote:

> On 2010-10-22 13:38, Dave Thaler wrote:
>>> -----Original Message-----
>>> From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] On Behalf
>>> Of Brian E Carpenter
>>> Sent: Thursday, October 21, 2010 3:48 PM
>>> To: behave@ietf.org
>>> 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,

How can an unidirectional inbound flow go through a NAPT?

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

Such discussion is present in RFC4787 as well - REQ-6.

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

I disagree. It is because of RTSP ALGs, ubiquity of HTTP clients and APIs in
every device, from iPhone to large desktop, availability of HTTP streaming
servers, authentication, etc.

> 
>    Brian
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave