Subject: [BEHAVE] [Fwd: I-D Action:draft-ietf-behave-v6v4-xlate-stateful-01.txt]

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 11 Jul 2009 10:52:06 +0200

Hi,

We have posted a new version of the NAT64 draft.

As discussed lately in the ml, we are using the FINs and the SYNs to 
close and establish the TCP session state in the NAT.

The document still needs quite some work, but if people can take a quick 
look and let us know if the overall direction is ok, it would be great.

Thanks, marcelo

-------- Mensaje original --------
Asunto: 	[BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-stateful-01.txt
Fecha: 	Sat, 11 Jul 2009 01:45:01 -0700 (PDT)
De: 	[email-masked]
Para: 	[email-masked]
CC: 	[email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
	Author(s)       : M. Bagnulo, et al.
	Filename        : draft-ietf-behave-v6v4-xlate-stateful-01.txt
	Pages           : 35
	Date            : 2009-07-11

NAT64 is a mechanism for translating IPv6 packets to IPv4 packets and
vice-versa.  DNS64 is a mechanism for synthesizing AAAA records from
A records.  These two mechanisms together enable client-server
communication between an IPv6-only client and an IPv4-only server,
without requiring any changes to either the IPv6 or the IPv4 node,
for the class of applications that work through NATs.  They also
enable peer-to-peer communication between an IPv4 and an IPv6 node,
where the communication can be initiated by either end using
existing, NAT-traversing, peer-to-peer communication techniques.
This document specifies NAT64, and gives suggestions on how they
should be deployed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-stateful-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 14 Jul 2009 11:38:45 -0400

Hello,

we should include how to handle TCP RSTs as well. Host implementations and
NATs might remove the tcpb (or binding) as soon as a RST is received (as
long as seq number checking passes).

Here, I think checking seq numbers is important for security sake, specially
in the case of TCP RSTs.

As far as ICMP response to unsolicited SYNs which we discussed before I
suggest the following amendment to your text

From

"      If the destination transport address contained in the incoming V4
      SYN is not in use in the TCP BIB, then the packet is discarded and
      an ICMP Port Unreachable error (Type 3, Code 3) is sent back to
      the source of the v4 SYN.  The state remains unchanged in CLOSED"

To

"      If the destination transport address contained in the incoming V4
      SYN is not in use in the TCP BIB, then the packet is discarded and
      an ICMP Port Unreachable error (Type 3, Code 3) is sent back to
      the source of the v4 SYN unless REQ-4a of RFC5382 applies.  The state
      remains unchanged in CLOSED"

Thanks,

Reinaldo

On 7/11/09 1:52 AM, "marcelo bagnulo braun" <[email-masked]> wrote:

> Asunto:         [BEHAVE] I-D
> Action:draft-ietf-behave-v6v4-xlate-stateful-01.txt

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 14 Jul 2009 18:30:51 +0200

> long as seq number checking passes).

but that would imply to keep track of all the seq # for all the data 
packets for each of the flows....
I don't think i would like to go there.

In order to handle the RST packets, actually, i had thought of that and 
i included in the state machines, but it seems i forgot to include in 
the text...

I think a RST coming from the Internet part should be ignored, cause as 
you say may be an attack, but i think that if the rst packet comes from 
the network side (the network that runs the nat64) then it should be 
honnoured.

what do you think?
>       remains unchanged in CLOSED"
right

thanks, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Jul 2009 20:39:37 +0200

On 14 jul 2009, at 18:30, marcelo bagnulo braun wrote:

> I think a RST coming from the Internet part should be ignored, cause  
> as you say may be an attack,

In that case you end up with a 2-hour timeout, not so great.

I would treat RSTs the same as FINs, except that the 4-minute timeout  
after a RST must go back to 2 hours again if there is a non-RST packet.

This would still allow an attacker to reset a session after 4 minutes  
if the session is idle without guessing the sequence number, though.

This could be solved by ignoring all RSTs if there wasn't a packet in  
the other direction first in the last, say, 10 seconds.

Then the attack can only happen within 10 seconds of a session going  
idle.

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 14 Jul 2009 16:03:02 -0400

> the network side (the network that runs the nat64) then it should be

After the connection is established, and the v4 side sends a RST to end the
connection and we do not honor it we will have hanging TCP bindings. This is
exactly what we were trying to avoid by being diligent on following
FINs/ACKs and having timeouts.

A TCP connection ended by RST is reused pretty quickly and the issue I see
if we do not honor valid TCP RST it is that we can end up reusing a old
binding and all kinds of problems can exist.

On the other hand, spoofed TCP packets can end the connection and there are
specific seq checks needed (different from connecting state from established
state).

>>> This draft is a work item of the Behavior Engineering for Hindrance
>>> Avoidance
>>> Working Group of the IETF.
>>> 
>>> 
>>>         Title           : NAT64: Network Address and Protocol Translation
>>> from
>>> IPv6 Clients to IPv4 Servers
>>> http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-stateful-01
>>> .t
>>> xt
>>>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 14 Jul 2009 22:42:46 +0200

> binding and all kinds of problems can exist.

Wouldn't you create a new binding when you see a new SYN that  
partially matches and old binding?

> specific seq checks needed (different from connecting state from  

Marcelo didn't like the idea of having to track seqnums between FIN  
and FIN/ACK, which I don't think is too big a deal. But to match RSTs  
with seqnums you'd have to track seqnums for ALL TCP packets, which is  
much, much worse...

How worried should we be about RST spoofing? I know it's considered a  
somewhat big deal with BGP, but I doubt that very many people will be  
running BGP through a NAT64 and I can't think of any other protocols  
that leave TCP sessions open so long that attacking them by spoofing  
RSTs through random guessing is a useful attack vector.

Note that a fairly large number of TCP sessions end with a reset. At  
least, this is what I observed when doing a lot of tcpdumping years  
ago. Perhaps this has gotten better, but I wouldn't assume that an RST  
is a very unusual occurrence.

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 14 Jul 2009 19:33:06 -0400

Hello Iljitsch/Marcelo,

> partially matches and old binding?

Without seeing 4/3-way close or RSTs first?

The statefulness or lack or it can be argued both ways. Should we move a
connection to established state if we see a SYN but not a SYN-ACK and then
just data packets? 

What if we see retransmitted SYNs? If we do not check seq numbers, do we
create a new 'partial' binding and destroy the old one?

I guess we need to agreed on some ground rules first on how lax or not our
processing is. Maybe work some not so well-behaved TCP connection use cases.

> and FIN/ACK, which I don't think is too big a deal.

Agreed. I think the trouble of tracking seq number during connection
establishment and close seems overblown. As I/we said, after connection is
established, you do not need to track them any further...unless ALGs are
involved. 

But to match RSTs 
> with seqnums you'd have to track seqnums for ALL TCP packets, which is

I know, maybe this is more related to security. A suggestion would be to use
the wording of the 5382/4787 RFCs whenever security is an issue. Something
like: "The NAT device MAY drop TCP packets which do not conform to sequence
number checking if it violates its security policy"

> RSTs through random guessing is a useful attack vector.

I agree BGP is an extreme but some P2P and IM applications can be up for an
extended period of time (days).

> is a very unusual occurrence.

I agree with this, specially servers that are very busy that want to reuse
the socket immediately or whenever you hit 'stop/cancel' on your browser.

Thanks,

Reinaldo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Jul 2009 09:31:11 +0200

> FINs/ACKs and having timeouts.
right, i guess the question is how often this happens.
I like Iljitshc suggestion of reducing the lifetime of the binding when 
a RST is seen, what do you think about that?

> binding and all kinds of problems can exist.

I fail to see any problem here. I mean, if the new connection uses the 
same 5 tuple, then the state can be reused wihtout problem and if it 
doesn't, then a new binding will be created, what is the problem that 
you see?
> specific seq checks needed (different from connecting state from established

right, this is my concern

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Jul 2009 09:31:52 +0200

> number checking if it violates its security policy"

i agree with adding this

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 15 Jul 2009 09:28:42 +0200

> after a RST must go back to 2 hours again if there is a non-RST packet.

that seems a reasonable tradeoff to me... what other people think?

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 15 Jul 2009 08:20:56 -0700 (PDT)

> >> I think a RST coming from the Internet part should
> be ignored, cause as you say may be an attack,
> > 
> > I would treat RSTs the same as FINs, except that the
> 4-minute timeout after a RST must go back to 2 hours again
> if there is a non-RST packet.
> 

Agreed, I believe this is a smarter method than tracking sequence numbers.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 15 Jul 2009 12:34:33 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Wednesday, July 15, 2009 12:31 AM
> To: Reinaldo Penno
> Cc: Behave WG
> Subject: Re: [BEHAVE] Comments 
> todraft-ietf-behave-v6v4-xlate-stateful-01.txt
> 
> Reinaldo Penno escribió:
> >

Martin Arlitt, Carey Williamson, "An Analysis of TCP Reset Behaviour on the
Internet", October, 2004,
http://pages.cpsc.ucalgary.ca/~carey/papers/2005/TCP-Resets.pdf

-d

> >>>> A New Internet-Draft is available from the on-line 
> Internet-Drafts
> >>>> directories.
> >>>>         Filename        : 
> draft-ietf-behave-v6v4-xlate-stateful-01.txt
> >>>>         Pages           : 35
> >>>>         Date            : 2009-07-11
> >>>>