Subject: [BEHAVE] Very late query on stateful NAT64

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Oct 2010 11:47:53 +1300

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.

Regards
   Brian Carpenter + Se-young Yu

---

From: Dave Thaler <[email-masked]>
Date: Fri, 22 Oct 2010 00:38:26 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Thursday, October 21, 2010 3:48 PM
> To: [email-masked]
> Cc: Se-young Yu
> Subject: [BEHAVE] Very late query on stateful NAT64
> 
> Hi,
> 
> 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.

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Oct 2010 14:25:33 +1300

> 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

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 21 Oct 2010 22:55:32 -0400

Hello ,

Comments inline.

>> direction just fine.  But if you want a one-way UDP flow in the inbound

How can an unidirectional inbound flow go through a NAPT?

> argued the point if I'd been aware of it earlier.

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

> streaming data, I suppose: NATs might arbitrarily interrupt legitimate

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Oct 2010 16:05:08 +1300

> How can an unidirectional inbound flow go through a NAPT?

I would assume there were one or two outbound packets to start
the session.

> servers, authentication, etc.

Well, it all started because HTTP gets through NATs and firewalls.
The things you mentioned came afterwards.

   Brian

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 21 Oct 2010 23:41:22 -0400

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

---

From: Dave Thaler <[email-masked]>
Date: Fri, 22 Oct 2010 15:31:21 +0000

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, October 21, 2010 6:26 PM
> To: Dave Thaler
> Cc: [email-masked]; Se-young Yu
> Subject: Re: [BEHAVE] Very late query on stateful NAT64
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Brian E Carpenter
> >> The security considerations of the RFC-to-be
> >> draft-ietf-behave-v6v4-xlate-
> >> stateful-12
> >> include this:
> >>
> >> 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.
> >
> > 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
> 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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 08:55:52 -0700

> see how this can be implemented.

This text is related to existing NAPT44 behavior, where a mapping
is kept active so long as there is an inside->outside flow (which
makes sense, and is usually 15-30 seconds) and is kept active longer 
if there is an outside->inside response (which makes sense, too,
and is usually ~3 minutes).  The next characteristic is that the 
NAT shouldn't keep a mapping alive if there is solely and only
an outside->inside flow.  This is discussed (but with a focus on
RTP flows) in draft-ietf-avt-app-rtp-keepalive, and the best
reference is probably REQ-6 of RFC4787.

Would it be helpful to add a citation to "Section 4.3 of [RFC4787]" 
during that document's AUTH48?

(The wording should be tweaked, anyway, from "MAY choose not to
extend" to "MAY choose to not extend".)

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 22 Oct 2010 09:51:21 -0700

> Cc: Se-young Yu; [email-masked]
> >> The security considerations of the RFC-to-be draft-ietf-behave-v6v4-
> xlate-
> >> stateful-12
> >> include this:
> >>
> genuine
> inbound direction,

HTTP (over TCP) has these very convenient TCP ACKs which indicate
the (internal) host enjoyed consuming the data.

If for a UDP flow the internal host doesn't burp a UDP packet 
occasionally, the NAT has no indication the internal host is alive, 
cared, wanted, or enjoyed the data.  The NAT has to destroy the UDP 
state at some point, or else its state table is full of incoming
UDP flows for movies or whatever content was being UDP streamed
long after the receiving system crashed or was disconnected from
the network.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 22 Oct 2010 19:24:10 +0200

> reference is probably REQ-6 of RFC4787.
Right, as several have stated already, this is the same as REQ 6 in 
RFC4787 and as a guideline we have in general tried to honour the behave 
requirements (while trnaslating them to the v6 v4 translation)

> extend" to "MAY choose to not extend".)
let me know what you want to do and i can drop a note to the RFC editor. 
I am fine with Dan's proposed changes.

Regards, marcelo

---

From: Dave Thaler <[email-masked]>
Date: Fri, 22 Oct 2010 17:27:13 +0000

[...]
> > extend" to "MAY choose to not extend".)

I agree with the above.

-Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Oct 2010 08:55:56 +1300

>>> extend" to "MAY choose to not extend".)

I would certainly not object, but only if this can really be done,
with AD consent, during the 48 hours of AUTH48. I don't want to
hold up this RFC for a second ;-)

   Brian