Re: [BEHAVE] Very late query on stateful NAT64

[Brian E Carpenter <[e-mail]>]

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.
The things you mentioned came afterwards.

   Brian