Re: [BEHAVE] Very late query on stateful NAT64

[Reinaldo Penno <[e-mail]>]

On 10/21/10 8:05 PM, "Brian E Carpenter" <[e-mail]>
wrote:

> On 2010-10-22 15:55, Reinaldo Penno wrote:
>> Hello ,
>> 
>> Comments inline.
>> 
>> 
>> On 10/21/10 6:25 PM, "Brian E Carpenter" <[e-mail]>
>> wrote:
>> 
>>> 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,
>> 
>> How can an unidirectional inbound flow go through a NAPT?
> 
> I would assume there were one or two outbound packets to start
> the session.
> 
>> 
>>>> 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.
> 
> Well, it all started because HTTP gets through NATs and firewalls.

Even if we assume this point, RTSP data sessions were problematic through
NATs not because inbound flows were timed out, but because they could not
get through at all.

RTSP ALGs solve these issues, but bring its own.

> The things you mentioned came afterwards.

I think this is a good discussion for another time.

> 
>    Brian