Re: [BEHAVE] Very late query on stateful NAT64

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 22 October 2010 01:23 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=GgWTqwdcnyLjtz9nQgIxcOhllQ3Urdbz7U190FJPndZQ4xfxAuwOUjmta6ieEuV8xL v0YlgQLp+CUvy/vIYzf6OTM37D9eAUiUY954P3s8aZ/PA5VB1rh5xBmsb4fyOzO6O0kI UGAlnaq33tRiXWXNv6AWMYan9Qxqeqf2SCpGY=
Message-ID: <4CC0E80D.8060800@gmail.com>
Date: Fri, 22 Oct 2010 14:25:33 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Dave Thaler <dthaler@microsoft.com>
References: <4CC0C319.1040400@gmail.com> <9B57C850BB53634CACEC56EF4853FF6534328FB8@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <9B57C850BB53634CACEC56EF4853FF6534328FB8@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Se-young Yu <syu051@aucklanduni.ac.nz>, "behave@ietf.org" <behave@ietf.org>
Subject: Re: [BEHAVE] Very late query on stateful NAT64
Precedence: list

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

   Brian

[BEHAVE] Very late query on stateful NAT64 Brian E Carpenter
Re: [BEHAVE] Very late query on stateful NAT64 Dave Thaler
Re: [BEHAVE] Very late query on stateful NAT64 Brian E Carpenter
Re: [BEHAVE] Very late query on stateful NAT64 Reinaldo Penno
Re: [BEHAVE] Very late query on stateful NAT64 Brian E Carpenter
Re: [BEHAVE] Very late query on stateful NAT64 Reinaldo Penno
Re: [BEHAVE] Very late query on stateful NAT64 Dave Thaler
Re: [BEHAVE] Very late query on stateful NAT64 Dan Wing
Re: [BEHAVE] Very late query on stateful NAT64 Dan Wing
Re: [BEHAVE] Very late query on stateful NAT64 marcelo bagnulo braun
Re: [BEHAVE] Very late query on stateful NAT64 Dave Thaler
Re: [BEHAVE] Very late query on stateful NAT64 Brian E Carpenter